[Interest] QGraphicsView and OpenGL in Qt6

[Michael Jackson]

 <hot take>
I’d like to chime in with a real world application that we have been
developing. It has a VTK based 3D rendering engine inside a Qt application
that is widget based. It did not start out great. We burnt 10 months with
3~4 engineers trying to develop this application as a QML desktop
application and it was just one thing after another in QML that just would
stop us in our tracks. QML on Desktop just isn’t as mature as Widgets on
the Desktop and suggesting for someone to rewrite a generally well working
desktop application to QML is not just a huge disservice but would be a
huge mistake. We ended up taking the last 2 months of the contract and spun
up a widgets based application and got more features completed for the
client in those 2 months than we did with 10 months of QML development. I
know things change but after that little exercise I am not sure anyone
would ever convince me to try QML on the desktop again. Period. If QWidgets
goes away we would probably just move to another language all together
rather than try QML. QML on Phones and tablets? Sure. Go for it. Desktop,
stay away. Far Far away.
</hot take>

And ironically enough, our application will also be trying to render large
tiled mosaics through VTK. Our tiled images are 2K x 2K each and our data
sets are upwards of 500 to 700 tiles at this point. The QTable idea sounds
interesting. I would have to research how to render the table inside an
OpenGL scene.


--
Mike Jackson                    mike.jackson at bluequartz.net
BlueQuartz Software         www.bluequartz.net

On Nov 23, 2023 at 9:38:35 AM, Shawn Rutledge via Interest <
interest at qt-project.org> wrote:

>
> On 23 Nov 2023, at 02:37, Calogero Mauceri <mauceri at actgate.com> wrote:
>
> Hi all,
>
> We finally decided to port our Qt5 based application to Qt6.
> It is a pretty complex application. The main view is a QGraphicsView with
> multiple items: images, paths, possible animations and so on.
>
> I remember in Qt5 OpenGL rendering was experimental with lots of issues.
> My question is, is QGraphicsView OpenGL rendering more stable in the Qt6
> era? or even better, is it suggested to render using OpenGL? (note: it is a
> cross platform application that should run on Windows, Mac or Linux
> machines).
>
> To be more specific. The QGraphicsView shows a map. The map is made up of
> multiple tiles that should align perfectly. Each tile is a
> QGraphicsPixmapItem. After porting to Qt6, it sometimes happens that when
> applying a scale to the tiles, then there are gaps between them. It does
> not always happen, but it can.
> I'm pretty sure the QGraphicsPixmapItems are properly scaled and
> positioned. It was working as expected in Qt5.
>
>
> Depending on how much you want to invest in porting, maybe it’s time to
> check whether you can use Qt Quick now?
>
> I have also wondered if we need explicit support for large tiled images.
> We need tiles in Qt Location for example, but in that case it’s already
> conventional to download pre-rendered fixed-size tiles, so that’s what we
> do; and the implementation is a C++ one-off, not depending on any reusable
> tiling implementation, since we don’t have one yet.  I also wondered how
> many people will want to use QtPDF to render very large pages
> (architectural drawings, electrical schematics, maps and so on), so I
> figured the tiling mechanism might be useful there too, if we had one.  But
> I tried using TableView for that, and it was reasonably successful.
> TableView does a good job with instantiating the tiles just-in-time: you
> only get as many tiles as you can see onscreen, and an extra “border” of
> spare tiles in case you then pan the view by small increments.  In the PDF
> case, rendering tiles is the bottleneck, because QtPDF uses the same raster
> engine that Chrome does to render PDF pages, and it's not
> multi-thread-capable; so tiling with TableView made it possible to render
> large pages at a higher resolution than you could fit into a single GPU
> texture, but caused a big slowdown (rendering each tile took almost as long
> as rendering the whole page at maximum texture size: just a demonstration
> of what’s wrong with CPU-based raster engines).  But if you can get your
> tiles quickly, I think TableView is great for that.  The tiles can fit
> together perfectly with no gap, and you get the advantage of its
> well-maintained dynamic loading mechanism.  Each tile is a Qt Quick
> Item-based delegate though (at least an Image, plus whatever else you
> declare there), so as with item views in general, you should avoid making
> your delegates too complex (interactive per-tile features), because the
> overhead gets multiplied by the number of delegates.
>
> Graphics View on the other hand has not been getting much attention in R&D
> for over a decade already: only bug fixes.  (Many of us haven’t used it
> much ourselves, aren’t very familiar with the implementation, and haven’t
> learned all the lessons that we could from it.  This includes me, although
> I had a simple use case for it once in an application.)  We hope it will
> eventually be obsolete when we’ve developed solutions for the known use
> cases in Qt Quick, but we also know that we’re not there yet.  I suspect
> that tiling could be considered just a specialization of a more general
> spatial-instantiation architecture: if you have a big collection of 2D
> assets with random sizes and positions, stored in some kind of model (QAIM
> or hopefully something better?), can we propose a standard API to figure
> out which views of them (delegates) will intersect the viewport?
>  (Obviously, without instantiating all the delegates just to find out)  One
> big difference between CPU-based rendering and Qt Quick is that you have to
> create scene-graph nodes now: avoid procedural rendering, don’t make your
> own draw calls; so for efficiency, you have to decide which ones to create.
>  (The rendering code will cull the SG nodes that are currently
> out-of-bounds, but they still take memory.)  But in Qt Quick, scene graph
> nodes are usually instantiated by Items; so probably you want to decide
> which of those to create.  Thus most applications are working 2 layers away
> from the actual rendering nowadays.  (Alternatively, one big smart
> QQuickItem subclass can selectively populate SG nodes within its own bounds
> rather than having an Item per asset that needs to be drawn, but you
> probably have to write more and less-reusable code that way.  You’ll need
> the QQuickItem::ItemObservesViewport flag to find out what region of your
> big item is actually visible in the viewport.)
>
> Maybe that’s part of what the replacement for Graphics View needs to
> eventually do.  (And should we extend it to 3D too?)  We can discuss
> further if anyone has ideas about it.
>
> Anyway tiling ought to be relatively easy with what we have now.
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20231129/38912c25/attachment.htm>