From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 15 Apr 2013 15:23:31 -0400
To: 9fans@9fans.net
Message-ID: <e4006fa5ed21180cd123bbdabb82d70a@ladd.quanstro.net>
In-Reply-To: <1a1b983d25524afdc837ffc669ef14e3@rei2.9hal>
References: <1a1b983d25524afdc837ffc669ef14e3@rei2.9hal>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] mouse cursor madness
Topicbox-Message-UUID: 42566490-ead8-11e9-9d60-3106f5b1d025

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