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. > 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
