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.hilshei...@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 <mauc...@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@qt-project.org> wrote: > >> >> On 23 Nov 2023, at 02:37, Calogero Mauceri <mauc...@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@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@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@qt-project.org https://lists.qt-project.org/listinfo/interest
