[Kde-graphics-devel] Quasar

[Matthias Kretz]

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

It occured to me that one is an API and the other an NPI (Node Programmer 
Interface) ;-)

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

Ah, then Composition::setOutput(QWidget *) would check for 
qobject_cast<QGLWidget *> and render the textures directly, or if it's not a 
GL widget convert the texture to a pixmap and draw that, right?

Things to consider:
- a composition should allow more than one output
- split processing and drawing between Composition::execute() and 
Composition::paint(QWidget / QImage / QPixmap / QGLWidget / QPainter). Then 
the app could call execute once and paint the result as often as it wants to.

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

Sidenote: One could try to make the vertex shader use less instructions. I 
assume the performance gain will be negligible, so feel free to ignore this. 
If one were to use an identity matrix for both projection and modelview - the 
latter is normal for most filters, the former is the same as using 
glOrtho(-1, 1, -1, 1, 1, -1) - one would be able to do "gl_Position = 
gl_Vertex;".

Anyway. Here's what I had in mind for rotation:
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glTranslatef(-width * 0.5, -height * 0.5, 0);
glRotatef(angle, 0, 0, 1);
glTranslatef(width * 0.5, height * 0.5, 0);
mesh->render();
glPopMatrix();

And that's what's currently not easily possible with a FilterNode subclass.

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

I didn't mean the input texture, but the resulting texture. I.e. the one that 
is written into when rendered onto the fbo. The problem was visible with 
recent Quasar when you had an image that was greater than the QGLWidget. Then 
only the lower left part of that image got processed, the rest of the texture 
was a dark grey.

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

I know your plans wrt this, which is why I'm keeping some of my hacks for 
myself. :-)

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

Say you want to do a translation in the vertex shader. If the projection 
matrix is glOrtho(0, width, 0, height, ...) then the vertex shader doesn't 
know how far it has to move the vertex to do e.g. a 50% translation to the 
left. The shader would need to know the image dimensions - those could be 
passed as uniforms. But if the vertices are "normalized" to the 1x1 rectangle 
the uniforms become unnecessary.

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

Probably QGraphicsView would be the best framework to integrate with?

-- 
________________________________________________________
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/20080610/fa4d9bac/attachment.pgp