[Kde-graphics-devel] Quasar

Zack Rusin zack at kde.org
Mon Jun 9 00:49:17 CEST 2008


Hey,

as some of you might have noticed it's a beautiful day (where I'm at right 
now, I don't care about you). Something else you might have noticed is that 
Matthias and I have been working on Quasar a bit lately and I feel we're 
slowly moving towards a "kinda working" stage which is good (not "sexy" but 
I'm sexy and bad, so clearly one doesn't have to imply the other).

Simply put Quasar is a presentation layer. What that means is that is handles 
display and intermediate manipulation of the rendered data - be it effects 
(like blur, saturation...) or transformations (e.g. scaling, rotation, 
waving...). Because of a huge interest in animation and a number of code that 
tries to handle it (neat things in Plasma and the new code Qt) Quasar doesn't 
handle animations itself. The framework to do them can be built either on top 
of it or alongside it. So again, Quasar is a presentation layer - how it 
should present it is something that things on top of it should decide.

Quasar is a purely OpenGL creation. I thought about software filters for a 
while, then I decided that I was dumb for even entertaining the thought of 
using software filters. There is no software fallbacks in Quasar - absolutely 
everything goes through OpenGL.

Filters in Quasar are simply GL shaders.

The way Quasar works internally is that everything is a Node that has an 
execute method. Nodes can be connected much in a similar way to the way 
QObject's signals/slots can be connected. A graph of those connections is 
created and upon execution Quasar goes over the graph, allocates surfaces 
(framebuffer objects) necessary to perform actions and executes the nodes. 
The output of the graph can be automatically displayed (by adding 
Quasar::RenderOutputNode to the graph) or saved to a QImage (by adding 
Quasar::ImageOutputNode to the graph).


There's a lot of things missing right now in Quasar, in particular:

- API is utter crap - I was mostly adding GL code and because I know GL code 
in and out I'm a rather bad person to design it. My knowledge of graphics 
hardware from the bottom up means that whatever graphics API I'll design will 
likely unnecessarily expose the internals. 

- Graph scheduling/iteration algorithm are non-existant - currently Quasar 
will assert if the graph is not linear

- No cleanups - tons of stuff isn't being deleted right now

- No application to show off Quasar - it'd be awesome if we had an application 
that simply allowed loading of an image, displayed a list of filters in one 
of the corners and a very simple property editor to manipulate properties of 
the filters and allowed people to play with those.

- Very few filters - I just wrote things that I needed for testing

- Some GL code still missing, in particular texture transfers aren't using 
pixel buffer objects, which especially for video is a bottleneck. I'll 
address that next.

- Lack of ability to load a Quasar::Texture from a QPixmap. We need code that 
uses GLX_EXT_texture_from_pixmap to create a gl texture from a x pixmap for 
that.

If you have any questions, comments or requests it'd be best to send them to 
kde-graphics-devel at kde.org. 
Also if you'll have any patches (which would be wicked awesome) I'd appreciate 
if I could get a chance to review them before they go in.

z


More information about the Kde-graphics-devel mailing list