[Interest] Many paint events?

[Derek Cole]

This maybe irrelevant but I implemented a similar image viewer a couple
of years ago. I ca post later when I am at a computer to look at the
actual working code, but for now,
http://stackoverflow.com/questions/6459278/read-image-files-with-qimagereader-using-qtconcurrent

This has some code snippets that may be interesting until I can post
the whole thing.

Sent from my Windows Phone From: Brad Pepers
Sent: 3/30/2014 4:31 PM
To: interest at qt-project.org
Subject: [Interest] Many paint events?
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

_______________________________________________
Interest mailing list
Interest at qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest