[Interest] [QGV] Asynchronous painting of millions QGPathItem

[Tomasz Siekierda]

On 8 September 2016 at 04:17, Ch'Gans <chgans at 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 at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160908/7722fe52/attachment.html>