Re: [Interest] QGraphicsView and OpenGL in Qt6
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 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 > 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 >
Re: [Interest] QGraphicsView and OpenGL in Qt6
On 23 Nov 2023, at 02:37, Calogero Mauceri 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 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
[Interest] Preventing MultiPointTouchArea interactions to pass through to Flickable
Hi, I’m handling touch interaction on some custom knobs with MultiPointTouchArea. The problem is when I try to interact with this elements when they are contained in a Flickable. Depending on the orientation of the flickable and the interaction, the flickable moves as well. Is there anyway to prevent this kind of interaction between both elements? Is there any newer and more adequate input handler to prevent this problem? Thanks! Nuno ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
