[Interest] QGraphicsView and OpenGL in Qt6

Mon Nov 27 14:18:34 CET 2023

Volker,

thanks for you suggestion.
Just filed a bug report

https://bugreports.qt.io/browse/QTBUG-119494

Calogero

On Fri, Nov 24, 2023 at 5:37 PM Volker Hilsheimer <volker.hilsheimer at qt.io>
wrote:

> Hi Calogero,
>
> QGraphicsView is still supported, and, like all of Qt Widgets, is in no
> danger of being deprecated. If you think that you are experiencing a bug in
> Qt, please report as usual, with a reproducer that is ideally not your
> pretty complex application :)
>
> Interesting information might be which platform you see this on, and
> whether you are running your UI on a display with a fractional scale level,
> as that might result in rounding errors in the integer-based painting
> architecture of Qt Widgets and QGraphicsView.
>
> Volker
>
>
> On 23 Nov 2023, at 16:28, Calogero Mauceri <mauceri at actgate.com> wrote:
>
> Hi Shawn,
>
> Thanks for your exhaustive explanation.
> As I mentioned the application is pretty complex, it is not only showing
> tiles but much more items the user can interact with. Reimplementing it
> would be a huge amount of work that would require too much time and
> resources and be bug prone.
>
> I am looking for a fix/workaround with the current QGraphicsView, if there
> is one. If using OpenGL rendering is safe enough I'm OK in enabling it. The
> fact that Graphics View is not supported anymore (and possibly at risk of
> deprecation in future Qt releases) does not make me feel so good though.
>
> On Thu, Nov 23, 2023 at 3:40 PM 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
>>
>
>
> --
> Calogero Mauceri
> Software Engineer
>
> Applied Coherent Technology Corporation (ACT)
> www.actgate.com
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
>
>

-- 
Calogero Mauceri
Software Engineer

Applied Coherent Technology Corporation (ACT)
www.actgate.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20231127/41daa82f/attachment.htm>