I've always wondered if you could put a QGraphicsScene in another process and then render to shared memory buffer QSharedMemory ( https://doc.qt.io/qt-5/qtcore-ipc-sharedmemory-example.html). Then you could query the shared memory (as a pixmap) in the main application. This would get around the QGraphicsScene blocking the main thread. This approach is great for rendering, but terrible if you want to directly interact with the QGraphicsView / QGraphicsScene using mouse and keyboard. You could even thread the scene by tilting the scene in separate processes. Just an idea.
Phi|ip On Mon, Dec 5, 2016 at 6:39 PM Ch'Gans <chg...@gna.org> wrote: On 8 September 2016 at 18:29, Tomasz Siekierda <sierd...@gmail.com> wrote: > On 8 September 2016 at 04:17, Ch'Gans <chg...@gna.org> wrote: >> >> Hi there, >> >> I'm currently working on a Gerber viewer (Gerber is an old file format >> still widely used in the electronics PCB manufacturing industry, >> dating as far back as the old photo-plotter methods), some of these >> files can get pretty big and I end up with a scene that contains up to >> 2 millions QGraphicsPathItem (biggest one so far, but i'm expected >> even bigger, maybe 10 millions would be an absolute limit). >> These huge files are more the exception than the rule, i still want >> nonetheless my GUI app to be usable. >> A typical usage is to render several file in a single QGV by >> super-imposing them as "layers". >> After profiling and optimising all the non-gui part of my app, my >> bottle-neck is now QGS/QGV painting time (QGScene insert time is not >> too bad at that stage). I haven't started to address this (I could try >> to implement aggressive caching to start with), because I'm happy to >> have that as a use case for rendering the view in a asynchronous way. >> >> By asynchronous, I mean that I want my GUI to not be completely frozen >> during the painting time (we're talking 10's of seconds). Of course >> i'm not expecting to be able to give the user full access to the GUI, >> I simply want to give the user feedback about my >> parsing-processing-rendering-painting pipeline. >> So far, I've used Qt Concurent for the parsing, processing and >> pre-rendering parts, but once this part is finished, the QGraphicsView >> very first painting kicks in and freeze the whole app. >> >> It is the first time that I have to deal with multi-threading that >> would run GUI/Widget business. And I'm not sure how to tackle this. >> >> Ideally, I would like something similar to QtCreator progress bars >> (parsing cmake/qmake/qbs, scanning for auto-test, indexing code model, >> ...). But I'll be happy to start with a small modal dialog showing the >> progress for each step/file (parse a file, process the commands, >> post-process/aggregate into QGS, paint it into QGV). >> I have a similar use case for exporting the QGS to images, pdf and svg. >> >> So far i've found only discussion about optimising the item painting, >> but nothing about running it in a separate thread. >> >> So here am I, does anyone had to deal with this kind of situation in >> the past and is willing to share feedback, advice or comment on the >> topic? > > > Not exactly the same use case, and not the same scale, but in one of the > apps I was involved with we did have performance issues with painting using > QGraphicsView (especially on mobile platforms where there is less CPU and > RAM available). We've got a significant boost in performance by rendering > QPainterPath to a QImage first, and then QGV was only painting this image in > paint(). IIRC. Turns out that i'm working on another project (similar application but different file format and content), and have to deal with the same problem. I haven't tried to render manually into a QImage, but will do shortly. So far i have played with QGraphicsItem::setCacheMode() [1] which does exactly that (pixmap cache), but have been unsuccessful in getting decent results (it's actually slower). One dead-simple technique that help a lot is QGraphicsScene::setMinimumRenderSize(), the drawback is visual "incorectness" as the minimum size get bigger. I have added this feature to the gui in the form of a choice "Level of details: high, medium, low". High mean minimum size = 0 (no optimisation), medium try to find "the right value", and low gives visual artifacts, but allow a very fluid X/Y/Z navigation when all the graphical features are enabled. I still have to spent a decent amount of time to try different way of improving paint performance and find a good way to measure performance, and ultimately both apps will share the same QGraphicsXYZ code. There are lot of areas to explore: - use of OpenGL viewport - QGView optimisation flags - QGView viewport update mode - QGItem cache mode (or manual caching, in my case i can even share cache b/w items) - QGScene minimum render size - QGScene BSP tree depth Have you tried QGItem cache mode ? If so what sort of result did you get? Why did you decide to implement your own caching method? Thanks, Chris [1]http://doc.qt.io/qt-5/qgraphicsitem.html#setCacheMode > >> >> Thanks in advance, >> Chris. >> >> PS: My application is currently able to display such gigantic scenes, >> it just take some time to render (and swallow lot of RAM), and make >> the mouse-wheel based zooming particularly slow, but with a bit of >> patience the result is actually quite amazing. Qt rocks! >> _______________________________________________ >> Interest mailing list >> Interest@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest > > _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest -- Phi|ip
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
