[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