Thread: [ocemp-devel] update after unlock
Status: Beta
Brought to you by:
marcusva
From: Martin F. <mf...@te...> - 2006-11-06 22:35:49
Attachments:
unlock.patch
|
Hi, Bothering you again :) I have noticed that quickly moving the mouse *within* a button causes it to repeatedly update sometimes causing noticible flickering of the mouse pointer (more or less noticable depending on the machine, CPU usage is also high during this) The reason seems to be that the MOUSEMOVE event in ButtonBase causes set_state(STATE_ENTERED) to be repeatedly called. However in button: def set_state (self, state): self.lock () if self.child: self.child.state = state ButtonBase.set_state (self, state) self.unlock () The unlock causes an update even if nothing was done (BaseWidget.set_state filters does nothing if no state change occured) Here is a proposed patch for this. I'm not quite sure about the changes to Bin (in particular why is Bin different to Container in that the locked check is done before the resize check). Regards, Martin |
From: Marcus v. A. <ma...@sy...> - 2006-11-07 13:01:17
|
On, Mon Nov 06, 2006, Martin Fuzzey wrote: > Hi, > Bothering you again :) Argh ;-). > I have noticed that quickly moving the mouse *within* a button causes it= =20 > to repeatedly update sometimes causing noticible flickering of the mouse= =20 > pointer (more or less noticable depending on the machine, CPU usage is=20 > also high during this) Sounds like a bug in the ButtonBase code I did not notice after the latest SIG_ENTER/SIG_LEAVE changes. > The reason seems to be that the MOUSEMOVE event in ButtonBase causes=20 > set_state(STATE_ENTERED) to be repeatedly called. > However in button: >=20 > def set_state (self, state): > self.lock () > if self.child: > self.child.state =3D state > ButtonBase.set_state (self, state) > self.unlock () >=20 > The unlock causes an update even if nothing was done=20 > (BaseWidget.set_state filters does nothing if no state change occured) I will look into it the next days (ENOTIME at the moment :-/). Thanks for reporting. =20 > Here is a proposed patch for this. > I'm not quite sure about the changes to Bin (in particular why is Bin=20 > different to Container in that the locked check is done before the=20 > resize check). Seems to be a typo. At least i cannot remember anymore why they differ here. Maybe there was some issue I wrote down somewhere. I'll look into this, too. (note to self: better code documentation). Regards Marcus |
From: Marcus v. A. <ma...@sy...> - 2006-11-15 12:34:31
|
On, Mon Nov 06, 2006, Martin Fuzzey wrote: > Hi, > Bothering you again :) > I have noticed that quickly moving the mouse *within* a button causes it= =20 > to repeatedly update sometimes causing noticible flickering of the mouse= =20 > pointer (more or less noticable depending on the machine, CPU usage is=20 > also high during this) [...] Now fixed in CVS. Regards Marcus |