From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1a1b983d25524afdc837ffc669ef14e3@rei2.9hal>
Date: Mon, 15 Apr 2013 19:35:49 +0200
From: cinap_lenrek@gmx.de
To: 9fans@9fans.net
In-Reply-To: <8860d1bf09bc55e9c7837dcedb7cd266@ladd.quanstro.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] mouse cursor madness
Topicbox-Message-UUID: 424e6402-ead8-11e9-9d60-3106f5b1d025

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