[Interest] Many paint events?

[Till Oliver Knoll]

Am 31.03.2014 um 12:45 schrieb "william.crocker at analog.com" <william.crocker at analog.com>:

> On 03/31/2014 03:24 AM, Till Oliver Knoll wrote:
>> Am 30.03.2014 um 22:31 schrieb Brad Pepers<bpepers at me.com>:
>> 
>>> ...
>>> 
>>> Any hints on where to look for this or maybe some other way to code this to avoid the problem?
>> 
>> I don't know where those "extra paint events" come from (or why),
>> but the most obvious thing for me would be to set a (conditional?) breakpoint
>> in your paint event handler and see from where those calls are triggered, and
> under what condition.

Under the condition that it only breaks when one of the "extra paint events" is handled. I placed a question mark there because I don't know how you would differentiate between a "legimitate" and an "extra" paint event, maybe with a "debug counter variable", or only break when you get a full graphicview update...

> 
> I know from experience that that does not help.
> I'm pretty sure the back trace from paintEvent()
> will just lead to the main event loop, not the
> cause.

Yes, you're absolutely right: we already know where the paint event comes from, and why ("because someone called update()").


> 
> What we all really want to know is:
> 
>     Which of the previous calls to update() between
>     point A and now actually scheduled the/a paint event.

In order to figure that (in a "brute-force kind of way") out you'd have to set the breakpoint in the mainloop... doh!

Maybe there's another way: QWidget::update() is a slot, right? If you're "lucky" those extra updates are triggered by someone calling that slot (via a signal). Maybe a tool like "GammaRay" by KDAB would help in such a case? It helps you tracking Qt signals (maybe even QEvents?). Haven't used it so far, but maybe it's worth a try?

Cheers,
  Oliver