PDA

View Full Version : resize/repaint strategies for very slow paint situations



jcbikeski
22nd July 2011, 17:59
I'm using Qt 4.6.

I have an application that displays plots of data that require several hundred thousand draw operations on a painter. On a fast computer this can take a few seconds to do. Dragging the mouse to resize causes multiple repaint events which can't be handled well at these drawing speeds.

I've read there is no way to really know when the resize is really over so the best I've heard from others is to restart timer on resize for maybe 0.1 seconds or so after every resize event then repaint when the timer finally has a chance to expire without another resize. So my first question is whether anyone has found a more elegant solution than this.

Some suggest painting to a pixmap outside the paint event handler then repainting the pixmap. I also need to have this widget output to high resolution printer or vector graphic file (like encap. postscript) so I don't know if this pixmap strategy works well or maybe I alter this behavior if I detect the repaint was for printing instead of the screen. Anyway I'm curious if others have had similar needs and found good solutions.

For those that have used the timer approach, I'm wondering if you can share any code snippets on your particular strategy including whether you inhibit paint from event being called until the timer or just have the paint handler ingore the request until you see a flag from the timer routine saying resize is done.

Also, does anyone know of any document that shows clearly the order and reasons resize or repaint gets called so I can be sure I'm addressing all situations related to these events.

Thanks for any help
John

mvuori
22nd July 2011, 19:25
I'd suggest the external image approach:
Have a separate thread that draws a QImage and when it is ready, sends a signal to your widget.
The widget simply draws the image when it is resized, which is practically immediate.
The widget will have a slot that gets the new image and perhaps another slot that gets progress information of the generation of the new updated image, thus being able to draw some info for the user of the need for waiting.

jcbikeski
22nd July 2011, 20:44
thanks, I may go that route. What is the advantage/difference using QImage vs QPixmap for this? I suspect this approach will mean having a bit of a different path to handling printing since I can't draw to a pixel based paint device if for printing I plan to output as vector graphics (users want to resize output image and keep a quality look).

Still even with another thread the resize will have many events for one user dragging. So a simple approach triggers creating a new image when it sees the first resize event. But another will come very quickly (before we're even close to being done drawing) and so I need to abort that thread and restart. Or I need to somehow know if I've seen the last resize (for a while) and start the thread then. If I do the latter then I probably didn't really need a thread. I had hoped that if I could do the actual plotting inside the actual paint event handler (assuming I limit how often it gets called) then I could use the exact same code for printing to a vector graphics file (including encapsulated postscript) by just letting the print renderer provide a different paint device.

Has anyone seen a good presentation of when resize events vs paint events happen such as what triggers, the order of events and how all those may occur for widgets that are part of a larger layout with other images?