[9fans] mouse cursor madness

[cinap_lenrek@gmx.de]

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.

i found a nice approch for 9front now that might be worth
porting back to bell-labs plan9 / 9atom or anyone who is
interested.

instead of using a timer interrupt, we just create a kernel
process in devmouse that calls cursoroff() and cursoron()
and then waits on a rendezvous point that is woken up every
time the cursor needs to be redrawn. (this can be triggered
by a new mouseredraw() function)

now, all call sites for cursoron() and cursoroff() are from
process contexts, so we can just wait on the drawlock in the
cursoron and cursoroff implementations for the software cursor.

the new mouseredraw() function is used by the software cursor
to schedule a cursor redraw (after the drawlock gets released
again) from swcursoravoid() or swcursorload().

theres no bookkeeping needed anymore like swvers or swpt/swvispt
because we actively trigger the redraw with mouseredraw().

the result is a much more responsive mouse and no flickering
even when having the software cursor over a window that does
heavy drawing. the kernel process still has a sleep timeout to
satisfy the drawactive() interface (screen blanking) but it
can sleep much longer.

code is in the 9front repo.

--
cinap