Quote Originally Posted by Waywocket View Post
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.