[9fans] vncv sw cursor trail

[Yaroslav]

When using vncv on a terminal with software cursor (vesa, rpi) the
mouse cursor leaves a trail. This seem to be caused by the fact that
vncv loads picture updates with loadimage(2) directly to screen.
Loading to an offscreen image followed by a draw(2) to screen removes
the artifact:

/n/dump/2013/0507/sys/src/cmd/vnc/draw.c:106,111 -
/sys/src/cmd/vnc/draw.c:106,112
static void
updatescreen(Rectangle r)
{
+ Image* img;
int b, bb;

lockdisplay(display);
/n/dump/2013/0507/sys/src/cmd/vnc/draw.c:120,129 -
/sys/src/cmd/vnc/draw.c:121,135
/*
* assume load image fails only because of resize
*/
+ img = allocimage(display, r, screen->chan, 0, DNofill);
+ if(img == nil)
+ sysfatal("updatescreen: %r");
b = Dx(r) * pixb * Dy(r);
- bb = loadimage(screen, rectaddpt(r, screen->r.min), pixbuf, b);
+ bb = loadimage(img, r, pixbuf, b);
if(bb != b && verbose)
fprint(2, "loadimage %d on %R for %R returned %d: %r\n", b,
rectaddpt(r, screen->r.min), screen->r, bb);
+ draw(screen, rectaddpt(r, screen->r.min), img, nil, r.min);
+ freeimage(img);
unlockdisplay(display);
}

Submitted as /n/sources/patch/vncv-curtrail
--
- Yaroslav

[lu...@proxima.alt.za]

> Submitted as /n/sources/patch/vncv-curtrail

It's been long overdue! Thank you.

++L

[erik quanstrom]

On Tue May 7 05:03:57 EDT 2013, yar...@gmail.com wrote:
> When using vncv on a terminal with software cursor (vesa, rpi) the
> mouse cursor leaves a trail. This seem to be caused by the fact that
> vncv loads picture updates with loadimage(2) directly to screen.
> Loading to an offscreen image followed by a draw(2) to screen removes
> the artifact:

i'm not convinced this fix gets at the real issue. (and allocating
new images might amplify latency.)

the issue, and this fact this fix works must mean that
devdraw(3)'s 'd' command usually doesn't cause (much)
cursor flicker, but the 'y' command does.

so either there is a timing or locking problem on the pi,
or swcursoravoid(r) is not called for the 'y' command.

i think this could be tested by putting a big fat swcursoravoid()
in the 'y' case in devdraw.

the pc screen.c has this warning,
/*
* always calling swcursorhide here doesn't cure
* leaving cursor tracks nor failing to refresh menus
* with the latest libmemdraw/draw.c.
*/
this seems to me to indicate a bug, i.e. interlocking is broken.

i am using the memdraw from p9p which fixes a number of
bad drawing cases. (no more blue pngs.) and i don't use
vnc, so it's hard for me to replicate.

- erik

[Gorka Guardiola]

On Tue, May 7, 2013 at 4:10 PM, erik quanstrom <quan...@quanstro.net> wrote:

On Tue May  7 05:03:57 EDT 2013, yar...@gmail.com wrote:
> When using vncv on a terminal with software cursor (vesa, rpi) the
> mouse cursor leaves a trail.  This seem to be caused by the fact that
> vncv loads picture updates with loadimage(2) directly to screen.
> Loading to an offscreen image followed by a draw(2) to screen removes
> the artifact:

i'm not convinced this fix gets at the real issue.  (and allocating
new images might amplify latency.)

 This problem happens in 386 too (I mean the original

problem this patch is addressing or tries to address).

G.

[erik quanstrom]

> This problem happens in 386 too (I mean the original
> problem this patch is addressing or tries to address).

the problem is still in the kernel. hacking around it in
vnc won't fix the problem for other programs. hwdraw
should behave the same for either, so something in
the kernel should be corrected.

- erik

[Anthony Sorace]

> i am using the memdraw from p9p which fixes a number of
> bad drawing cases. (no more blue pngs.) and i don't use
> vnc, so it's hard for me to replicate.

I use 9atom on the pi daily and vncv often a d have never observed this behavior.

[Ярослав Коломієць]

> the issue, and this fact this fix works must mean that
> devdraw(3)'s 'd' command usually doesn't cause (much)
> cursor flicker, but the 'y' command does.
>
> so either there is a timing or locking problem on the pi,
> or swcursoravoid(r) is not called for the 'y' command.

Correct: swcursoravoid is called from hwdraw; memdraw (the 'd' case) does call hwdraw, memload (the 'y' case) does not.
Other programs avoid the issue because the programs do not load images directly to screen.

I guess what happens is the cursor draw scheduled after swcursoravoid saves part of the remote cursor image which is being drawn in meantime.
This is yet to be verified.

> (and allocating new images might amplify latency.)

The potential latency hit could be avoided by pre-allocating an offscreen storage big enough (double-buffering); this would cost more kernel draw memory though.
So until latecy suffers in practice the cost doesn't worth paying.

Yaroslav

[Ярослав Коломієць]

> I use 9atom on the pi daily and vncv often a d have never observed this behavior.

does 9atom uses a higher HZ setting which could make swcursor be drawn sooner?

[erik quanstrom]

On Tue May 7 14:51:13 EDT 2013, yar...@gmail.com wrote:
>
> > the issue, and this fact this fix works must mean that
> > devdraw(3)'s 'd' command usually doesn't cause (much)
> > cursor flicker, but the 'y' command does.
> >
> > so either there is a timing or locking problem on the pi,
> > or swcursoravoid(r) is not called for the 'y' command.
>
> Correct: swcursoravoid is called from hwdraw; memdraw (the 'd' case) does call hwdraw, memload (the 'y' case) does not.
> Other programs avoid the issue because the programs do not load images directly to screen.

i think the assertion that memload "loads directly to the screen" is not correct.
at least to my walking through memload.

- erik

[erik quanstrom]

> i think the assertion that memload "loads directly to the screen" is not correct.
> at least to my walking through memload.

i read wrong. i think this may fix the issue in a systemic, but not
entirely satisfying way. it does seem rather optimistic that we can
just scribble on the screen.

Top:
dl = dst->layer;
if(dl == nil){
/* call memdraw so that hwdraw gets called */
tmp = allocmemimage(r, dst->chan);
n = loadfn(tmp, r, data, n);
memdraw(dst, r, tmp, r.min, nil, r.min, S);
freememimage(tmp);
return n;
}

by the way, hz should have nothing to do with it since i'm
using cinap's technique of a mouse process that redraws the
cursor when asked, or every 20ms, whichever comes first.

- erik

[Yaroslav]

> by the way, hz should have nothing to do with it since i'm
> using cinap's technique of a mouse process that redraws the
> cursor when asked, or every 20ms, whichever comes first

This might as well explain the fact 9atom users don't experience the
problem: local cursor is redrawn sooner than bitmap update for remote
cursor arrives.

The problem also disappears when a severe latency induced on the path
to vnc server (sshnet through a distant machine or so).
--
- Yaroslav