Re: [9fans] vnc[vs] implementation question

Re: [9fans] vnc[vs] implementation question

[andrey mirtchovski]

> the final draw is the only one that can be seen.
> by making it a draw between images of the same
> format you've reduced it to memmove, so the flicker
> should go away.  conversion from cmap8 goes significantly
> slower than memmove.
>

there is still a bit of flicker.  not as much, but still there..  if I
reboot in 8bpp and just do a loadimage(screen); there is no flicker at
all.

performance is the same in all 3 cases (~ 80fps in a term the size
that the 'window' command defaults to :)

i guess the solution is to store the pixels in screen->chan format,
since the benefits of loadimage(screen) are huge.  not that i'll
bother with XaoS, but it's a good thing to keep in mind for something
as graphics intensive as devtv.

Re: [9fans] vnc[vs] implementation question

[Russ Cox]

> in XaoS' case, unfortunately, one can't use this approach, because the
> pixels are written by the program in CMAP8 format (and the image used
> in loadimage(); is alloc-ed in CMAP8 too) and if the screen is
> anything else loadimage(screen, ...); fails...

you could have two images, the cmap8 one and one
the depth of the screen.  then do

	loadimage(icmap8);
	draw(iscreenchan, icmap8);
	draw(screen, iscreenchan);

the final draw is the only one that can be seen.
by making it a draw between images of the same
format you've reduced it to memmove, so the flicker
should go away.  conversion from cmap8 goes significantly
slower than memmove.

> it'd be great to have routines that convert between format en masse
> (similar to the ones in color(2)), but that's just as expensive as
> doing a loadimage();draw() combination.

again, i don't think it's the total expense
so much as the speed of the operation that the
user actually sees.

Re: [9fans] vnc[vs] implementation question

[andrey mirtchovski]

> it's worth noting that vncs is what uses
> the stand-ins for devdraw etc.
>
> vncv doesn't.  vncv probably has good performance
> just because all it does is write blocks to the
> screen.  memmove to the screen is fast.

got it...  the trick (or rather, the problem with xaos) is that it
does
	loadimage(someimage, buffer, ...);
	draw(screen, someimage,...);

in vncv you (I assume) just do a
	loadimage(screen, buffer, ...);

in XaoS' case, unfortunately, one can't use this approach, because the
pixels are written by the program in CMAP8 format (and the image used
in loadimage(); is alloc-ed in CMAP8 too) and if the screen is
anything else loadimage(screen, ...); fails...

it'd be great to have routines that convert between format en masse
(similar to the ones in color(2)), but that's just as expensive as
doing a loadimage();draw() combination.

or maybe there's a trick to it?

Re: [9fans] vnc[vs] implementation question

[Russ Cox]

it's worth noting that vncs is what uses
the stand-ins for devdraw etc.

vncv doesn't.  vncv probably has good performance
just because all it does is write blocks to the
screen.  memmove to the screen is fast.

Re: [9fans] vnc[vs] implementation question

[andrey mirtchovski]

>
> do you have a better way?
>

no. I was simply curious as to why it's done this way.

the performance of vncv is quite good, so I wanted to see if I it does
anything differently with the libdraw routines, possibly something
that could easily be accomodated for other programs, say, XaoS, which
do exhibit jitter...

Re: [9fans] vnc[vs] implementation question

[Russ Cox]

> why does /sys/src/cmd/vnc implement its own dev, devdraw, devmouse and
> devcons?

do you have a better way?

the vnc server is presenting the vnc protocol
from many clients to plan 9 programs as
devdraw, devmouse, devcons, etc.

the amount of code isn't so much, and it's
not clear how to modularize further.
it does work though, and works well.

drawterm suffers the same problem.

russ

[9fans] vnc[vs] implementation question

[andrey mirtchovski]

why does /sys/src/cmd/vnc implement its own dev, devdraw, devmouse and
devcons?

I skimmed through them briefly and it looks like they're almost
identical to the ones in /sys/src/9/port..

thanx