[Interest] Many paint events?

[Brad Pepers]

I have a class derived from QAbstractScrollArea using Qt 5.2.0 and it re-implements paintEvent.  It's used as a view into a much larger image and that image is drawn by background threads.  So the image may be 10,000 by 5,000 pixels but the view is 900x600 and those 10,000 by 5,000 pixels are broken up into 64x64 pixel tiles.  So in the paintEvent code it converts the viewport and scroll bars into the list of tiles to display and then either kicks off a background thread to draw the tile if it doesn't exist or do a drawImage of the tile if is does exist.  When the background thread has created the tile it sends a signal back to the main thread which does an update on the tiles place in the scroll area which will do another paintEvent and draw the tile.

So this is all working well and I was just looking at performance and in particular how many times paintEvent is called.  I see it called the first time for the whole 900x600 scroll area which kicks off all the background threads and I added debug info so I can see when the background work is done and the update calls.  Those updates cause more paintEvents and because sometimes a few background threads are done at once, the paint events they cause are usually a combination of a few of the tiles.  This is all well and good and expected but then at the end when all the background threads are done, I see 13 calls to paintEvent for the entire 900x600 area.

Any idea what could be causing 13 full paint events like this?  By this time the tiles all exist so it just draws them and causes no more work but it seems very wasteful.  I found this because I was adding some other drawing on top of the tiles and was surprised how many times that drawing was being done.  I added debugging to any other place in the code that calls update on the viewport and there are no others. How can I be ending up with over a dozen repaints of the whole scroll area from calling update on individual 64x64 tiles?

Any hints on where to look for this or maybe some other way to code this to avoid the problem?

--
Brad