From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Mon, 15 Apr 2013 13:28:32 -0400 To: 9fans@9fans.net Message-ID: <8860d1bf09bc55e9c7837dcedb7cd266@ladd.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] mouse cursor madness Topicbox-Message-UUID: 4247f504-ead8-11e9-9d60-3106f5b1d025 On Sun Apr 14 14:17:35 EDT 2013, cinap_lenrek@gmx.de wrote: > the way the mouse cursor is drawn currently is quite complicated. > the cursor is redrawn from a timer interrupt 30 times a second > and the software cursor also installs its own timer interrupt > handler to redraw itself when it got overdrawm (swcursoravoid). > > when a programs use draw operations heavily, the chances become high > that when the software cursor interrupt handler finds the drawlock > busy, so it has to retry to draw on the next tick. (thats why > cursoron() has a return value... to indicate the retry). > > this causes ugly flickering and it keeps the machine busy for > no reason. hey, this is an interesting approach. it seems much cleaner. but i'm not seeing as much flicker reduction as i was expecting, and text scrolling speed is not (as expected) improved. part of this may be that i've set HZ=1000, but it also seems to me that a coalescing scheme might be in order. even with HZ=100, one could have a minimum of 100 cursor redraws/sec, which seems excessive. any ideas on this? - erik