Limit number of paintEvents per second
-
wrote on 23 Jun 2015, 22:46 last edited by
I have a widget where I draw a grid of squares and, inside mouseMoveEvent, I call update() every time the mouse moves to a new square. After measuring, I discovered that if I move the mouse quickly over the grid, I get something around 130 paintEvent calls / second. This is too much. Is there a (elegant) way of limiting the frequency of paintEvents to 60 or 30 / second?
-
I have a widget where I draw a grid of squares and, inside mouseMoveEvent, I call update() every time the mouse moves to a new square. After measuring, I discovered that if I move the mouse quickly over the grid, I get something around 130 paintEvent calls / second. This is too much. Is there a (elegant) way of limiting the frequency of paintEvents to 60 or 30 / second?
wrote on 23 Jun 2015, 23:05 last edited by alex_malyuI might be wrong,
But this might be totally unrelated to number of updates you make.
Your widget might be repainted cause region affected by mouse movement has to be updated.If I am wrong you may limit the number of updates issued by using timer in order to schedule updates.
Something like start timer after update is called.
If new request for update is needed and timer is already running set the flag to call another update when time is out.If I am right, all you can do is to provide an efficient implementation of repaint with const QRect& and const QRegion& parameters.
-
I might be wrong,
But this might be totally unrelated to number of updates you make.
Your widget might be repainted cause region affected by mouse movement has to be updated.If I am wrong you may limit the number of updates issued by using timer in order to schedule updates.
Something like start timer after update is called.
If new request for update is needed and timer is already running set the flag to call another update when time is out.If I am right, all you can do is to provide an efficient implementation of repaint with const QRect& and const QRegion& parameters.
wrote on 24 Jun 2015, 00:44 last edited by@alex_malyu Thanks for your answer! Using a timer is one of the things I thought about. I'm just wondering if there's not a better way. There must be one.
I'm 100% sure all paintEvents I'm talking about came from my update() calls, I checked it carefully. And I already have a quite acceptable implementation that uses a QRegion to limit the update area only to two squares: the one just selected and the one that was selected previously. Just by doing that, I already got a very nice performance boost, but I still think my program is wasting a lot of cpu time by rendering the thing at more than twice the refresh rate of the monitor.
-
wrote on 24 Jun 2015, 01:41 last edited by
I'm 100% sure all paintEvents
Just for information:
As far as I know frequency of updates already are sort of controlled in the event loop
and some calls may be skipped.
Documentation said "Calling update() several times normally results in just one paintEvent() call."
That was a reason for my claim. -
I'm 100% sure all paintEvents
Just for information:
As far as I know frequency of updates already are sort of controlled in the event loop
and some calls may be skipped.
Documentation said "Calling update() several times normally results in just one paintEvent() call."
That was a reason for my claim.wrote on 24 Jun 2015, 01:54 last edited by@alex_malyu Yes, I'm aware of that. But what I have counted is not the number of times update() was called in a second. It's possible that this number was even higher, but I measured the number of times the paintEvent() code was executed. And I made sure to count only when the "cause" of the event was this specific call to update() when mouse changes the square it is pointing at. I know that by checking that the QRegion that I passed as argument in this call to update() is the same one reaching paintEvent()
-
@alex_malyu Yes, I'm aware of that. But what I have counted is not the number of times update() was called in a second. It's possible that this number was even higher, but I measured the number of times the paintEvent() code was executed. And I made sure to count only when the "cause" of the event was this specific call to update() when mouse changes the square it is pointing at. I know that by checking that the QRegion that I passed as argument in this call to update() is the same one reaching paintEvent()
wrote on 24 Jun 2015, 01:59 last edited bypaintEvent may be a result of mouse changing the location without you calling an update explicitly.
-
paintEvent may be a result of mouse changing the location without you calling an update explicitly.
wrote on 24 Jun 2015, 17:39 last edited by@alex_malyu Well, it actually not. At least in this case (I don't know if this depends on your operating system, or on the type of widget or something like that)
If I comment my update() call, paintEvent is never called, no matter how much I move the mouse over it.
3/7