resize/repaint strategies for very slow paint situations

[mvuori]

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]

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?