[Kde-graphics-devel] Quasar

[Matthias Kretz]

On Monday 09 June 2008, Zack Rusin wrote:
> 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.

Well, for the users of Quasar GL should probably be hidden. But for node 
implementors there won't be a way around GL anyway. So perhaps it helps to 
keep in mind that there are two Quasar APIs.

The main problem with using the API I have at the moment is that the 
application, if it wants to use the RenderOutputNode, needs to create a 
QGLWidget and is solely responsible for redraws.
suggestions:
- add a Quasar::Composition::graphChanged() signal. Then 
Node::setPropertyValue would trigger that signal as could a node 
implementation by itself (PhononInputNode would need to trigger that signal 
with every new frame).
- add a Quasar::RenderWidget which redraws and resizes/sets the size hint 
automatically and which hides OpenGL for the ignorant user.

Regarding FilterNode implementations:
a) FilterNode is a very handy class and I'd like to use it where possible, but 
sometimes it would make sense to not hide the Mesh to the FilterNode impl but 
let it render the vertices itself. I was thinking of e.g. a rotation filter 
where you probably don't want to calculate the rotation of every vertex in 
the shader but calculate it once when the rotation angle is set and then 
every reevaluation of the filter is as fast as it can get. Also, an impl 
might want to use different texture coordinates (flip the image, 
stretch, ...) or pass other vertex parameters (i.e. not uniforms).

b) did you fix the viewport and projection matrix for fbos? I.e. per default 
every fbo should use a viewport of the dimensions of its attached texture and 
a glOrtho projection of the same dimensions. Alternatively the projection 
could also be glOrtho(0, 1, 0, 1, -1, 1). Depending on the node this might 
make sense, so it would be good if the node can override the projection 
matrix easily.

Ok, that's what I came up with for now, hope it's useful. :-)

Hmm, thinking about UI overlays on videos (like most flash players do these 
days). Would it be in scope of Quasar to add event handling to the nodes? 
Like let the RenderWidget pass mouse and key events to the composition which 
would somehow handle it/let the right nodes handle it? Would it then make 
sense to create UI elements as Quasar nodes?

-- 
________________________________________________________
Matthias Kretz (Germany)                            <><
http://Vir.homelinux.org/
MatthiasKretz at gmx.net, kretz at kde.org,
Matthias.Kretz at urz.uni-heidelberg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-graphics-devel/attachments/20080609/15cfa5fa/attachment.pgp