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 .
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:aintEngine() 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?", 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 .

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

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...s-and-widgets/
http://labs.trolltech.com/blogs/2007...on-the-canvas/

http://labs.trolltech.com/page/Proje...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 .

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:aintEngine(), 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 .