[9fans] mouse cursor madness

[9fans] mouse cursor madness

[cinap_lenrek]

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

Re: [9fans] mouse cursor madness

[erik quanstrom]

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

Re: [9fans] mouse cursor madness

[cinap_lenrek]

i found it not to be a big deal to just redraw the cursor without
any delay. this is usualy very quick anyway. the only exception
is when another process holds onto the drawlock for a long
time because of some expensive operation (poly drawing). and in
that case, the cursor draw process will be queued on the drawlock and
will be scheduled right after the other process releases the lock.

the important thing is that the cursor drawing doesnt block mouse
event processing and delivery to userspase. (which still happens
at interrupt time)

i think the HZ value shouldnt matter. because the redraw interrupt
was triggered every 33ms. the resolution of the time base should
not be important in that case.

the effect is mostly visible if you have one process doing lots
of poly draws in a tight loop. then the cursor redraw interrupt
will miss the drawlock most of the time and the cursor started
rocking arround at a rate of like 1HZ on my x200. the mouse
events themselves arent affected, its just the redrawing of the
software cursor.

--
cinap

Re: [9fans] mouse cursor madness

[erik quanstrom]

On Mon Apr 15 14:37:00 EDT 2013, cinap_lenrek@gmx.de wrote:
> i found it not to be a big deal to just redraw the cursor without
> any delay. this is usualy very quick anyway. the only exception
> is when another process holds onto the drawlock for a long
> time because of some expensive operation (poly drawing). and in
> that case, the cursor draw process will be queued on the drawlock and
> will be scheduled right after the other process releases the lock.

i find i get a lot of flicker (and unnecessary delay) when
scrolling text quickly.

try
	echo scroll>/dev/wctl
	time cat /sys/src/9/port/*

and hz does matter because the sleep in mouse proc
may be woken a minimum rate of hz*nproc.

so for the system i'm working on, i think one could get 8000hz
(or more) cursor redraws per second after your change.

before the maximum rate was 30.

- erik

Re: [9fans] mouse cursor madness

[cinap_lenrek]

> and hz does matter because the sleep in mouse proc
> may be woken a minimum rate of hz*nproc.

ah! right. you could get even faster redraws on a mp system when
another idle processor is available. it might not just wait for the
hz timer tick but schedule the woken up mouseproc as soon as it
appears in its run queue no?

in the text scroll case, you'r already drawing to the screen at
a high rate. why should we draw the cursor at a lower rate other
than getting a more regular flicker pattern?

--
cinap

Re: [9fans] mouse cursor madness

[erik quanstrom]

also, i think that mouse.xy should be updated inside a lock.

- erik

Re: [9fans] mouse cursor madness

[erik quanstrom]

On Mon Apr 15 16:28:37 EDT 2013, cinap_lenrek@gmx.de wrote:
> > and hz does matter because the sleep in mouse proc
> > may be woken a minimum rate of hz*nproc.
>
> ah! right. you could get even faster redraws on a mp system when
> another idle processor is available. it might not just wait for the
> hz timer tick but schedule the woken up mouseproc as soon as it
> appears in its run queue no?
>
> in the text scroll case, you'r already drawing to the screen at
> a high rate. why should we draw the cursor at a lower rate other
> than getting a more regular flicker pattern?

i'm finding that flicker is still a problem with catclock if you
align the cursor bottom with the bottom of the tail, and the
rhs of the cursor with the middle of the cat's right foot.

- erik