The ecosystem is fragmented for historical reasons. Wikipedia pages of each API explain the historical context of each. The main reasons there has not been a b

The ecosystem is fragmented for historical reasons. Wikipedia pages of each API explain the historical context of each. The main reasons there has not been a big push to create only one graphics API are: 1. it's hard after the genie of many API:s is out of the bottle (why should i port my code) 2. Surprisingly, the benefits would not be that huge (IMO) - compared to the enormous amount of energy this would take. The graphics data the different API:s consume is more or less the same. Since it's eventually fed to the same hardware. So for an engine a large part of the non-trivial code is actually graphics backend agnostic. All of the API:s basically 1. select whether to draw to onscreen or texture 2. load triangles 3. load shader program which a) modifies vertices of triangles (projection etc) b) computes pixel color for each sample in triangle 4. load variables and textures that are used as input to the shader program 5. draw. The shader code has different languages but all of them are more or less isomorphic. The above is a ELY 5 trivialization, but the gist of it is more or less so. The difficult part actually is managing the state of any complex graphics program, not getting the graphics to the screen. So, first you need to learn a graphics API and think that's hard. Not so! What's actually hard is then figuring out how to make any coherent application around that.