Drawing standard widgets using a custom paint engine

[Waywocket]

Hi, I'm new to the forum so apologies if this is in the wrong section or I've made any other etiquette blunders :p.
I'm interested in whether it's possible to have widgets of existing classes drawn using a custom paint engine. From reading the documentation, all I can find is about creating a new type of widget which can then specify the paint engine it uses, so I imagine what I want isn't directly possible.

One (deeply unpleasant) approach which occurred to me would be to modify Qt itself - alter the QWidget::paintEngine() method in qwidget_x11.cpp and friends to point to a new paint engine.

Short of that, are there any other approaches that might work?

BTW, the closest I've seen to what I want is described at "Using QGLWidget paint engine to draw regular widgtes?" (http://www.qtcentre.org/forum/f-qt-programming-2/t-using-qglwidget-paint-engine-to-draw-regular-widgtes-3805.html), but that ended without any real resolution and I didn't want to resurrect an old thread...

Thanks for your time - and especially if you can point out some simple solution I've missed :D.

[high_flyer]

Actually, I posted the thread you refered to just before DevDays 2006.
During DevDays I had a chance to ask the chiff Graphics View Framework developer at TT this question (regarding redering the Qt Widgets with OpenGL).
And in fact it is possible, and he even could show me on site where the code should come in (more or less - since an OpenGL is already implemented in Qt), but I can't remember any more... :o
At any rate, yes, Qt4 allows this (using a custom paint engine to draw the existing widgets) through sub classing QPaintEngine.
But is no stroll in the park...

[wysota]

Actually, I posted the thread you refered to just before DevDays 2006.

A lot of brainstorming... pitty we didn't come to an acceptable solution.


During DevDays I had a chance to ask the chiff Graphics View Framework developer at TT this question (regarding redering the Qt Widgets with OpenGL).

God, I missed that chat :crying:



At any rate, yes, Qt4 allows this (using a custom paint engine to draw the existing widgets) through sub classing QPaintEngine.
But is no stroll in the park...

You might want to read these as Andreas (vel Bitto) has made significant progress in that topic:

http://labs.trolltech.com/blogs/2007/04/02/graphics-view-with-layouts-and-widgets/
http://labs.trolltech.com/blogs/2007/03/09/qgraphicsview-widgets-on-the-canvas/

http://labs.trolltech.com/page/Projects/Graphics_View/Graphics_Items

[high_flyer]

A lot of brainstorming... pitty we didn't come to an acceptable solution.
This is one of the great things about QtCenter :-)
Regarding an "acceptable" solution - it depends what you define as acceptable.
I was looking for a responsive gui objects, drawn with OpenGL.
I did manage to have a QPushButton to draw its self in an OpenGL context, but is was just a "shadow" of a button, it did not react to input (obviously).
But as I said, this should be possible acourding to the talk from DevDays.

God, I missed that chat
Yes, the problem with this, is that you wait with 10 other guys after the presentation, and the guy is really stressed out, so he answerd REAL quick both because he is stressed out, and, because he knows it like the back of his hand, so its really hard to keep up, since you are both trying to understand AND remember...
Unfortunately, I didn't deal with this issue after DevDays so I forgot exactly what he told me.
But, at least we know it is definetly possible.

[wysota]

Unfortunately, I didn't deal with this issue after DevDays so I forgot exactly what he told me.

You can ask again this year :)

[high_flyer]

Good point! :-)
Will you (and Jacek) come this year too?

[wysota]

Will you (and Jacek) come this year too?
Probably yes, unless there happens to be a problem with a need of being in two places at the same time.

[high_flyer]

Ahh... that is no problem at all, just start a new (execution) thread! ;)

[wysota]

Ahh... that is no problem at all, just start a new (execution) thread! ;)

There is a single processing unit, so one still can't do two things (separated by a distance of few hundred kilometres) at the same time. Context switching in this case is really expensive in both terms of time and money.

But let's not hijack the thread :) If you want to talk about it, start answering emails ;)

[Waywocket]

Well, thank you both for your input. It looks like I'd be best to look into the graphics view framework I suppose.
Actually, the new version of qtdemo using QGraphicsView looks interesting, so maybe I'll have a good look at the code for that...

[Waywocket]

Since this follows on from this thread, I decided not to start a new one, unless nobody looks at this one :D.

I've started playing with QGraphicsView (& friends) today, and now I'm a little stuck.
I have a custom widget which embeds OGRE, currently just drawing a fixed background colour so I can see it's working.

When used as a standard widget, it works fine, but as soon as I try "gView.setViewport(ogreWidget)", it stops displaying anything.

Now, I wasn't expecting it to draw the graphics scene, since the QPaintEngine functions are currently just stubbed out (from some debugging messages, they do appear to be called correctly BTW). I was however expecting that the background colour would still be drawn, since I'm not drawing anything on top.

If I don't provide Ogre with the appropriate window handle in initialisation (for testing purposes) then it opens its own seperate window, and appears to be drawing correctly. I also tried adding some rudimentary actions in one of the paint engine functions, and that appears to be 'working' (not that it's what the function is intended to do, I just wanted to see if I could get some result).

I presume then that when I call setViewport(), QGraphicsView must be creating a new subwindow for its viewport widget, or drawing another widget on top, or something, but at this point I have no idea what to start looking at next.

BTW, if I use a QGLWidget in place of my own widget, then it works as expected - so there's clearly something my widget's not doing which it's expected to.

Anybody have any idea what I might try next?

Edit: I had hopes for 'setAttribute(Qt::WA_PaintOnScreen);', but that didn't help.

[wysota]

It's too late for me now to think about it clearly, but for me it looks like a paint engine problem. The background color won't be drawn because your paint engine doesn't draw it (at least that's how I understood it at 2am).

[high_flyer]

Its not 2am, but I am at work, and can't dive in to this at the moment.
However, here is another idea to check:
Maybe its not that big a problem - baybe it has to do with the transparent background?
By default the widgets are transparent (not drawing their background, which is the only thing you implemented), unless you specify autoFillBackground(true);
Its worth a try...

[Waywocket]

Thanks for the replies, but I'm afraid it's not either of those.
I'll see if I can explain any better.
My widget inherits from QWidget, and embeds an OGRE render window.
I've found two ways to do this:

Pass the widget's winId into OGRE's window creation method. This will cause OGRE to re-use and render onto the existing window created by QWidget's constructor.

Alternatively, allow OGRE's window creator to make its own new window, then query its winId and call 'QWidget::create(window_id)' , which makes a QWidget discard the old window and use the new one instead.

In both cases, it's necessary to pass in the parent window handle (parent->winId()), otherwise a 'physically' (best word I can think of) seperate window is created - its own window decorations, can be moved independently, etc.).

Additionally, I've reimplemented QPaintDevice::paintEngine(), and a simple paint engine. Specifically, begin() and end() work, and all other non-optional do nothing except drawPolygon, which I just quickly hacked up to draw the points given as dots, just so I could see if it was doing anything.

This widget works as expected when used normally - added to a QMainWindow or such. As soon as its used as the viewport for a QGraphicsView, it stops displaying anything at all; the OGRE render output is no longer visible.

Out of interest, I removed the handle to the parent window in the call to ogre->createRenderWindow, to make the render window appear seperately, and I can see several dots appearing as drawPolygon is called, indicating that my paint engine is working, but since the canvas its drawing to doesn't display as a graphics view viewport, that doesn't make much of a difference.

The thing that confuses me is what QGraphicsView specifically does when it takes a widget to use as its viewport, because I can't see what could be causing this.

I hope that explains my situation a little better.

[wysota]

If I understand correctly, you just want to embed an external window (of OGRE origin) into your application. In that case what is the point of using it as a viewport of a graphics view? Doesn't OGRE allow you to render its contents into an image or something like that? It would be easier to do it this way. And I think implementing an own paint engine is a dead end.

[Waywocket]

If I understand correctly, you just want to embed an external window (of OGRE origin) into your application. In that case what is the point of using it as a viewport of a graphics view?

Because I want to render a graphics scene as an overlay in OGRE (specifically to a dynamic texture drawn as an overlay material), effectively providing an OGRE GUI using Qt (even better if it becomes possible to draw widgets in a graphics view), hopefully allowing Qt to deal with the input handling. The reason for this is that none of the GUI (or input handling) libraries for OGRE are anywhere near the standard of Qt.

I would just draw other widgets straight on top of the OGRE widget, which works, only that wouldn't allow for alpha compositing which is something I need.

[wysota]

Because I want to render a graphics scene as an overlay in OGRE
I don't think it will work. The OGRE widget is not a real Qt widget, so Qt can't paint over it. It doesn't have access to its contents or anything...


I would just draw other widgets straight on top of the OGRE widget, which works, only that wouldn't allow for alpha compositing which is something I need.

Again, is it possible to force OGRE to draw into some memory buffer or image? Or maybe you can pass OpenGL context from a QGLWidget to OGRE and ask it to paint using it?

[Waywocket]

I don't think it will work. The OGRE widget is not a real Qt widget, so Qt can't paint over it. It doesn't have access to its contents or anything...

I was under the impression that the customised paint engine would cover this. Possibly I'd need to make my own painter as well though - I can't find anything in the documentation which says what components need to be able to read from the widget, and the description for implementing a new paint device says only that you need to implement an appropriate paint engine - in fact, I can't find any mention of any component needing to be able to read the contents of a widget, except for potentially its paint engine.

Bear in mind again that the existing OGRE window, onto which I can successfully draw using my dedicated paint engine, becomes somehow hidden as soon as it is used as the graphics view viewport, and this is all I'm really concerned about at the moment, even if it ultimately transpires that I can't draw usefully on to it.



Again, is it possible to force OGRE to draw into some memory buffer or image?
Probably, but the performance problems incurred would make this infeasible, since you'd need to read data back from the frame buffer, which is intolerably slow on systems with dedicated graphics memory (ie. most of them). (Either that or do all the rendering in software, which would be even worse.)

For this reason, I don't believe that the QGLWidget does this, so I don't believe it should be necessary. I wonder if QGraphicsView contains code to deal specifically with QGLWidgets (don't think so though).


Or maybe you can pass OpenGL context from a QGLWidget to OGRE and ask it to paint using it?
This idea hadn't occurred to me, and there's some chance it might be possible, thanks.

[wysota]

I was under the impression that the customised paint engine would cover this. Possibly I'd need to make my own painter as well though
Not a painter - a paint device and it can't inherit QWidget - that's the main problem.


I can't find anything in the documentation which says what components need to be able to read from the widget, and the description for implementing a new paint device says only that you need to implement an appropriate paint engine - in fact, I can't find any mention of any component needing to be able to read the contents of a widget, except for potentially its paint engine.
Yes, but you won't be painting on the widget, so you won't be able to mix any QWidget and OGRE code other than that which uses QPainter.


Bear in mind again that the existing OGRE window, onto which I can successfully draw using my dedicated paint engine, becomes somehow hidden as soon as it is used as the graphics view viewport, and this is all I'm really concerned about at the moment, even if it ultimately transpires that I can't draw usefully on to it.
Your graphicsview would probably become awfully slow. I think it would be better if you made a real overlay - apply a graphicsview with a regular viewport over the OGRE widget. You'll just have to make the graphicsview and its viewport transparent.



Probably, but the performance problems incurred would make this infeasible, since you'd need to read data back from the frame buffer, which is intolerably slow on systems with dedicated graphics memory (ie. most of them). (Either that or do all the rendering in software, which would be even worse.)
With modern cards it should be possible to use pixel buffers or some simmilar technique (I'm not an expert on that so I can't tell you more).


For this reason, I don't believe that the QGLWidget does this, so I don't believe it should be necessary. I wonder if QGraphicsView contains code to deal specifically with QGLWidgets (don't think so though).
The difference is that you want to paint behind Qt's back and with QGLWidget that's not the case. The only possibility I see is to share the GL context between the widget and the OGRE engine.

[Waywocket]

I think we may be having a misunderstanding here, so for the moment I'm going to give up and try learning all there is to learn about creating new widgets and see if that helps me understand what's happening.
(Just discovered also that there's no non-hacky way of even getting at the OpenGL context of a QGLWidget, which is a little disappointing. I guess they figured since it wouldn't work identically on all platforms then it shouldn't be allowed at all)
Thank you for your time, either way :D.

[pdolbey]

Something like



#IFDEF Q_OS_WIN
HGLRC rc = wglGetCurrentContext();
#ELSE
GLXContext rc = glXGetCurrentContext();
#ENDIF


in the intializeGL() or paintGL() methods of a QGLWidget will probably get the necessary rendering contexts. I've proved the Windows leg first with an OpenCascade OpenGL viewer - the alternate piece is the logical extension for X11.

Pete

[Waywocket]

Thanks for that tip; I'll look into it at some point.

[Waywocket]

That did indeed work, and I've managed to make a subclass of QGLWidget which embeds Ogre as its background, allowing me to use Qt paint calls on top of an Ogre context, with alpha compositing, and to use this as a QGraphcsView viewport - using the bare minimum of Xlib and GLX calls to glue it all together :cool:.
I might post a bit more on this once it's tidied up, but on the other hand I kind of doubt anybody will care...:o

[high_flyer]

oh, we care! :)

[pdolbey]

I care too, especially as you've just tested a line of code that I couldn't.

Pete:D

[Waywocket]

Well I've got a simple Ogre widget, and a corresponding GraphicsView widget, along with a couple of subclasses for those implementing some more demonstrative functionality, and finally a simple demo app, mixing Qt and CEGUI (not sure why you'd want to in reality, but anyway...)

If you're not interesting in building the Ogre demo, the most important bit of code to look at is probably in QOgreGLWidget::initializeGL().

The idea is to get Ogre to use an existing window (which requires that you know its XVisualInfo), and to switch between QGLWidget and Ogre GLXContexts at the appropriate times so neither find themselves in an unexpected state.

The final point is to ensure that both Ogre and Qt don't try to swap buffers; I let Qt do it so that the QGLWidget can get a chance to draw over the window after Ogre's done with that frame.

Apologies for the roughness; I got bored of tidying it all up :P.

Also, I think there was something else I was planning to add to this post, but it's two in the morning so I'll see if I remember tomorrow...
Edit: I think it might have been that there's a bug in Ogre which this triggers. Nothing desperate - you get X Errors when the widget is destroyed; I've provided a patch (http://sourceforge.net/tracker/index.php?func=detail&aid=1738129&group_id=2997&atid=302997).

(Just noticed that CEGUI widgets, including the mouse cursor, are resized along with the window. Text correctly manages to remain the same size though and I'm performing the resize notifications to CEGUI in the same place, so I don't see what's wrong. Guess I must have missed something.)

[desert]

I've been doing some research and this is the closest i've found on Qt+OGRE shared OpenGL rendering.

But have you found a way to share the context instead of switching? Context switching might be costly. Have you read about


params["externalGLContext"] = Ogre::StringConverter::toString( ((unsigned long)(glXGetCurrentContext()) ) );
mRenderWindow = mOgreRoot->createRenderWindow("View", width(), height(), false, &params);

Im doing this but seems OGRE insists on creating a new context.