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