[9fans] vncv sw cursor trail

[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

Re: [9fans] vncv sw cursor trail

[lucio]

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

It's been long overdue!  Thank you.

++L

Re: [9fans] vncv sw cursor trail

[erik quanstrom]

On Tue May  7 05:03:57 EDT 2013, yarikos@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

Re: [9fans] vncv sw cursor trail

[Gorka Guardiola]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

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

> On Tue May  7 05:03:57 EDT 2013, yarikos@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.

[-- Attachment #2: Type: text/html, Size: 1170 bytes --]

Re: [9fans] vncv sw cursor trail

[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

Re: [9fans] vncv sw cursor trail

[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. 

Re: [9fans] vncv sw cursor trail

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

> 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

Re: [9fans] vncv sw cursor trail

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

> 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?

Re: [9fans] vncv sw cursor trail

[erik quanstrom]

On Tue May  7 14:51:13 EDT 2013, yarikos@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

Re: [9fans] vncv sw cursor trail

[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

Re: [9fans] vncv sw cursor trail

[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