Hi guys, come suse hackweek, I finally managed to land $subject in master (thanks to Cloph, Caolan and Stephan for cleaning up after me btw). I would not call it production-ready yet (therefore it's listed far down in the config xml factory list of canvas implementations), but it showcases some interesting features. First of all, it does not use any of the tricks the older hw-accelerated canvas implementations use [1], to get the pixels to the screen - every drawing operation that touches pixel is native opengl, with a fair amount of pixel shaders e.g. for gradient fills. As such, most of the bottlenecks of cairo or gdi+ should be gone. Of course, input data that is already a bitmap (e.g. a png) stays that, but it simply gets loaded into a texture w/o pixel processing. It does that by recording display lists of rendering operations [2], that client code calls at the XCanvas interface (conceptually not too dissimilar from the venerable metafile approach) Every re-paint of the screen, e.g. because something moved in slideshow, is then a plain re-display of a slightly modified list of already-existing display primitives, pretty much exactly what a game does for every frame. [1] both cairocanvas and directx canvas are software renderers at the bottom, just using the hardware to composite already-rendered content on the screen. hardly an efficient use of today's gpu capabilities. [2] there is an obvious duality here between drawinglayer primitives aka scene graph, and the procedural XCanvas interface, that makes converting from primitives to canvas to opengl scene graph a bit of a waste. I'm aware of that, might be another interesting future project. Cheers, -- Thorsten
Attachment:
signature.asc
Description: Digital signature