Benjamin K. Stuhl wrote: > One other possibility is to have each widget render to a QPicture in the > UI thread and then offload the QPicture-to-QImage rendering (which is > probably the expensive part, especially if antialiasing is turned on) to a > background thread. The PlotWindow would just recomposite whenever it got a > new layer from the background thread; each rendering request should > probably be tagged with the widget's changeset number so that the > rendering thread can throw out already-out-of-date requests.
This seems to be quite a good idea. I've done some benchmarks. Repeatedly drawing some examples, the multixy and multiaxes examples are 8% faster using QPicture, sin is 2% faster. A test with 40000 points is 2% slower. It seems a little strange that it is often faster rendering to a QPicture, then drawing to a QPixmap, rather than drawing directly. Perhaps it is some sort of improved cache locality within Qt. It shouldn't be hard to separate the rendering out to another thread in this case. The one problem I can think of is the question of how to terminate a rendering thread if the document has changed. It looks like QThread.terminate is dangerous, so should be avoided. We could fire off a thread each time the document changes, but it could make single core machines a bit busy. I wonder whether it is possible to raise an exception in a different thread - seems doubtful. The only solution I can think of is to check for some sort of stop signal at entry to rendering each widget, and raise an exception if it is present, falling back to rendering the next QPicture. Jeremy -- Jeremy Sanders <j...@ast.cam.ac.uk> http://www-xray.ast.cam.ac.uk/~jss/ X-Ray Group, Institute of Astronomy, University of Cambridge, UK. Public Key Server PGP Key ID: E1AAE053 _______________________________________________ Veusz-discuss mailing list Veusz-discuss@gna.org https://mail.gna.org/listinfo/veusz-discuss
