Quote Originally Posted by elanthis View Post
There is far more to modern graphics than compositing. And even then, yes, it is more difficult. Not only is it two codepaths to write, test, and maintain; there's also a matter of enabling and disabling entire swathes of features based on the compositing backend, as naive software compositing is barely capable of handling straight up transparent "cutout", much less shadows, de-focus blur, transforms (including simple accessibility ones like maginification), and so on. So then there's another set of code that has to be written, tested, and maintained. If you want really fast compositing in software, you need to get a really fancy software graphics engine... like LLVMpipe. (Or WARP** for Windows/Direct3D... I'd like to see some benchmarks between WARP and LLVMpipe some time!)

All to support a tiny minority of users who haven't upgraded their machines in many years, or who are running oddball setups that aren't standard fair for a desktop stack anyway.

** On the note of WARP, it's a very interesting design. It provides a very high performance fully D3D11-compliant software rasterizer. It was designed to mimic the performance of real hardware in such a way that you can test your app's performance characteristics on WARP and have it translate well to how it'll scale on real hardware (that is, find the bottlenecks of your app; obviously you'd expect the app to run faster overall on real hardware, but you shouldn't expect that a call that took 2% of the render time on WARP will suddenly take 10% of the render time on hardware). It's also being extended/reused in the upcoming enhanced PIX tools from Microsoft, giving you a way to step through and inspect shader code in your unmodified app, without needing specialized hardware setups (like NVIDIA's tools or the tools for the XBox360 ATI graphics chip) to do it. That's the kind of developer-oriented tools that the FOSS graphics stack should be focusing on ASAP; Linux's biggest draw on the desktop is as a developer machine, but yet it seems its developer tools are lagging further and further behind. Vim and GDB aren't exactly the cutting edge of developer tools anymore.



That is not at all true. OpenGL has a lot of problems, but there's no reason it can't do standard 2D rendering faster than software. 2D rendering on the CPU is just (in simplified terms) a big loop over a 2D grid doing a lot of SIMD operations. That's _exactly_ what the GPU is designed to excel at, and OpenGL is just an API that exposes that hardware to software.

That most of the FOSS drivers have major problems and that precious few FOSS desktop developers have the first clue how to actually use OpenGL properly to do fast 2D, that is possibly quite true. The vast majority of GUI toolkits and higher level 2D rendering APIs are written like it's still the 1990's and don't actually have a render backend that's capable of working the way a GPU needs them to work. It's entirely 100% possible to make one, though, and the speed benefits can be _massive_, not to mention the battery life benefits for mobile devices (letting your GPU do a quick burst of work is more efficient than having your CPU chug through it for a longer period of time).

The primary problem is a complete lack of batching (that is, many GUI toolkits do one or more draw calls per widget/control, where as it is possible to do a handful or even just one for the entire window) and a lack of understanding on how to use shaders to maximum effect. Even a lot of game-oriented GUI frameworks (for editor and such, or even ones designed for in-game HUDs and menus systems like ScaleForm) get this terribly wrong.

You have to design your render backend for a 2D system around how modern hardware actually works. You can't just slap an OpenGL backend into a toolkit that assumes it's using a software renderer.
From what I've read OpenGL actually isn't a good fit for efficient 2d rendering that isn't a polygon. Apparently Mac developed a QuartzExtreme2d backend (now called QuartzGL) awhile ago but never got it working well enough to make default. So, they use the cpu like everyone else who isn't windows, or happens to have a blitter.
http://www.cocoawithlove.com/2011/03...-graphics.html
So, unless you want to extend your complaints of FOSS cluelessness about graphics hardware to Apple, you might want to say, rather, that Windows created an accelerated api that seems to be uniquely able to handle 2d.