Problems with Open-Source Downloads read https://www.qt.io/blog/problem-with-open-source-downloads and https://forum.qt.io/post/638946
QQuickWindow::beforeRendering and updatePaintNode() questions
dv__ last edited by
In my application, some custom quickitems perform their own OpenGL based 3D rendering. The GL viewport is adjusted according to the item's rectangle (handled in a slot connected to beforeSynchronizing). These items are not part of a true 3D scene, they are just individual 3D objects that I can rotate etc. (Imagine an item containing a 3D cube drawn with OpenGL.) It all works well, but there are a few lingering points with the rendering order.
First, since currently I am using the beforeRendering() signal to render, these items are drawn first. But I'd like to have a background drawn with QtQuick. I could switch to afterRendering(), but I also need some overlay elements...
Second, using beforeRendering() is a problem if my rendering calls enable blending and items overlap, because the scenegraph will not sort the drawing in the beforeRendering() stage. This means that for example an opaque element that is in front of a translucent element will appear as if it were behind it.
These problems could be solved by rendering in updatePaintNode() instead, but the documentation warns against doing 3D rendering in there - it is reserved for 2D and 2.5D. Now, what does "2.5D" in this case mean? Can I use the depth buffer? Do individually drawn 3D objects count as a "2.5D" case? I suppose this warning goes against trying to draw true 3D scenes with a "world" containing multiple 3D objects etc. So, would this be OK with updatePaintNode(), or not? Where would you see the limit beyond which rendering in updatePaintNode() is a really bad idea?
Also, I can't use framebuffer objects, because I've had problems with them on embedded. Less so on i.MX6 (although the Vivante drivers can be kinda delicate about FBOs), more so on other platforms. Also, I want the items to be smoothly resized, and having to reallocate FBOs during the resizing would make this impossible.