[Kde-graphics-devel] Quasar

[Zack Rusin]

On Monday 09 June 2008 08:04:38 am Matthias Kretz wrote:
> 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.

Yea, that's a good point.

> 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).

Yea, definitely. The graphChanged signal should definitely be there. 

> - add a Quasar::RenderWidget which redraws and resizes/sets the size hint
> automatically and which hides OpenGL for the ignorant user.

Ideally I'd like to see Quasar widget independent. So I'd much rather have
SomeWidget::SomeWidget(QWidget *parent)
{
  composition.setOutput(this);
}
void SomeWidget::paintEvent(QPainteEvent *e)
{
   composition.execute();
}
and setOutput basically would do:
connect(composition, SIGNAL(graphChanged()),
	widget, SLOT(update()));

To completely avoid any custom widget's. And allow rendering to both QWidget's 
and QGraphicsItem's (the latter would be trivial if QGLWidget would be the 
viewport for the QGraphicsView on which a given QGraphicsItem resides. For 
the latter we'll need some magic in RenderOutputNode);

> 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.

I wanted to do geometrical transformations as a vertex shader. Currently for 
all filters we're always using a vertex shader with:
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
for any other transformation we'd either use:
gl_Position = userPassedMatrix * gl_Vertex;
or 
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex * someTransformation;
GPU will execute the vertex shader anyway, it makes sense to use that.

> Also, an impl might want to use different texture coordinates (flip the
> image, stretch, ...) 

Realistically speaking that's also something that should be done in the vertex 
shader. Currently we do:
gl_TexCoord[0] = gl_MultiTexCoord0;
which is passing default texture coords. We can do anything we want with them 
there.

> or pass other vertex parameters (i.e. not uniforms). 

Yea, definitely. I wanted to add a nicer api for custom parameters. But aside 
of uniforms probably only varying would make sense for us.


> 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. 

Ah, no! The fbos shouldn't have dimensions of the master texture, they should 
have dimensions of the domainOfDefinition and such coordinates. 
For example:
ImageInputNode reads image 600x400
GaussianBlurNode filters that image

For gaussian-blur to be correct the dimensions of the produced texture need to 
be 600+filter radius / 400 + filter radius. So the master texture will be 
600x400 but it will be rendered in the middle of 600+filter radius/400 + 
filter radius fbo.
I probably should write some documentation about the point of domain of 
definition and region of interest. It was described in detail in this paper:
http://portal.acm.org/citation.cfm?id=192191
(currently it's not really implemented too well, or at all, in Quasar but this 
is where we want to get)

> 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.

Any particular reason for it? 

> 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?

I think ideally we'd do this on top of Quasar. Basically to keep it as simple 
as possible. 
But yea, it would be great to have nodes that do some kind of event handling. 
It's just that personally I didn't have a good idea on how to do that yet =)

z