Direct3D revisited

[uj]

I've understood that (experimental) support for Direct3D has been dropped . But what does this mean? Does it mean that the plan was that Qt optionally would do all drawing with Direct3D under Windows, and now it's not going to be like that? Or does it mean that there won't be any Direct3D equivalent to QGLWidget?

It looks like QGLWidget is quite a thick binding to OpenGL. It's fully integrated with the rest of Qt and you can for example draw with Qpainter in a QGLWidget. Lets assume you don't require quite that much for Direct3D. You would be satisfied with a much thinner binding that would coexist with Qt but with a bare minimum of integration. What would be the least effort to accomplish that and what would be the best strategy to accomplish it. Qq is open source so maybe there's even an initiative going on to develop a "QD3DWidget"?

I guess it would be most natural to inherit QWidget and try to somehow get hold of the underlying Win32 window. One probably could reuse much of the QGLWidget implementation. I note that Qt can interoperate with ActiveX. Could that be a better approach?

If I go for Qt I'm going to use OpenGL. After all, portability is one of the major reasons for using Qt in the first place. The reason I'm asking is that I would feel more comfortable with a fall-back strategy in place. Direct3D has a strong presence and isn't going away anytime soon. I may never use it but I would like some indication as to what effort would be involved if I have to. This would also give an indication of how extendible Qt is.

Thank you.

[uj]

Any takers?

[wysota]

But what does this mean? Does it mean that the plan was that Qt optionally would do all drawing with Direct3D under Windows, and now it's not going to be like that?
Yes, that's exactly what it means. But Direct3D backend was never enabled in Qt directly so it doesn't make much difference, especially now that the OpenGL backend is quite mature and the raster engine has been improved significantly as well.

Or does it mean that there won't be any Direct3D equivalent to QGLWidget?
There never was one so that's correct as well. But you can use Direct3D in your application regardless. Qt simply won't aid you in it in any significant way.

[quote]It looks like QGLWidget is quite a thick binding to OpenGL.
Well... that's discussable :)


It's fully integrated with the rest of Qt and you can for example draw with Qpainter in a QGLWidget.
The latter is thanks to the OpenGL painting backend which translates all QPainter calls to OpenGL.


What would be the least effort to accomplish that and what would be the best strategy to accomplish it. Qq is open source so maybe there's even an initiative going on to develop a "QD3DWidget"?
Developing your own widget is one of the options but you can just set a bunch of flags on any widget telling Qt you will be responsible for drawing it and then just do regular D3D stuff (I know pretty much nothing about D3D so I can't tell you any details).


If I go for Qt I'm going to use OpenGL. After all, portability is one of the major reasons for using Qt in the first place. The reason I'm asking is that I would feel more comfortable with a fall-back strategy in place. Direct3D has a strong presence and isn't going away anytime soon. I may never use it but I would like some indication as to what effort would be involved if I have to. This would also give an indication of how extendible Qt is.

OpenGL will never go away as well so you needn't be concerned about it. After all it's a standard in 3D graphics.

[thomasfreedy]

Hello,

What flags do you set to tell QT not to handle painting of a widget? I'm doing a Direct3D class which draws correctly but the paintevent overwrites the screen. I'm
using 4.6 on Windows CE on a Atom D510.

Thanks,
Thomas

[minimoog]

Flag Qt::WA_PaintOnScreen and reimplement QWidget::paintEngine to return 0.