Re: [9fans] was 8½ slow and that lead to rio?

Re: [9fans] was 8½ slow and that lead to rio?

[rob pike]

Rio was written for Brazil, in which the kernel had no graphics at
all, and all graphical operations were done in user mode and then
blasted as raw pixels onto the screen.  That became untenable at low
bandwidth, so when we put the draw operator in, the graphics
functionality went back in the kernel as a stopgap.  I hope it doesn't
stay there, but it was an easy way to focus on the interesting
problems.

There are three reasons that rio doesn't multiplex the graphics: 1)
history, as mentioned above; 2) speed; 3) to avoid the code bloat.
Much of 8½'s source code involved grubbing around and rewriting
graphics messages for the clients.  This meant that the graphics code
was scattered between library, kernel, and window system.  Rio avoided
all that gunk and doesn't need to change if the graphics interface
changes, as it has a couple of times.  It's a huge improvement.

So the real answer is engineering, not performance.

-rob

Re: [9fans] was 8½ slow and that lead to rio?

[okamoto]

According to our understanding, using memdarw(2) or memlayer(2)
will not cause those problem, if we can restrict copying of those huge
size of image data only once at the beginning of making image.   Present
our implementation demands real time copying of those data. :-)
Now, we are changing our direction.

Than you very much Russ.

Kenji

Re: [9fans] was 8½ slow and that lead to rio?

[Russ Cox]

Yes.  I believe the whole story is in the window(2) man page.
Anything you've been doing with memlayer
should be possible to translate into that interface,
which basically translates back into memlayer
calls after reaching the kernel.

Instead of using a transparent layer to overlap
the entire base image, you can create small opaque
windows and put them where you want, reordering
them as you find necessary.  Think about the
layering that rio has to do when moving windows
around.  All that is done with window(2).

Russ

Re: [9fans] was 8½ slow and that lead to rio?

[okamoto]

>allocimage(2) can be used such a purpose?

allocwindow(2), of course...

Kenji

Re: [9fans] was 8½ slow and that lead to rio?

[okamoto]

Good day (returned from lunch :-), Russ.

We need a transparent layer to overlap entirely the base image,
in some case it'll make only a small window, but for annotating,
we have to overlap it over entire window with transparent property.

allocimage(2) can be used such a purpose?

Kenji

Re: [9fans] was 8½ slow and that lead to rio?

[Russ Cox]

You should be able to accomplish the same
effect by allocating a window with allocwindow
for each layer.  Have a look at /sys/src/libdraw/menuhit.c
for one example, or at rio for a more complicated
but perhaps clearer example.  Then the kernel will handle the layers
and you should see the performance you expect.

Russ

Re: [9fans] was 8½ slow and that lead to rio?

[okamoto]

>No programs in the standard distribution use them directly.
>Are you?

Yes, we are using those for making layer structure in our program
where we need a base layer of image, which shouldn't be affected
through changing other layers for showing tentative information,
such as showing alititude data pointed by the mouse, or for making
some anotations on the image etc.  If we don't have such a layer
structure, we have to redraw the base layer everytime we made and
erased such tentative informations.

Kenji

Re: [9fans] was 8½ slow and that lead to rio?

[Russ Cox]

> memdraw(2) or memlayer(2) works on user memory space.  When we
> try to make it run in cpu(1) environment, huge amount of data will be
> copied from cpu server's user memory space to terminal.  We are dealing
> with several to tens megabyte images, and feel it's slow in a 100MBPS network.
> We may have two ways here( or more?):
> (1) forget cpu(1) command
> (2) do memdraw and memlayer also in  kernel memory space.

memdraw(2) and memlayer(2) exist almost only for the
purpose of implementing the devdraw device in the kernel.
No programs in the standard distribution use them directly.
Are you?  Can you be more specific about the programs
you're running?

Russ

Re: [9fans] was 8½ slow and that lead to rio?

[okamoto]

>so when we put the draw operator in, the graphics
>functionality went back in the kernel as a stopgap.  I hope it doesn't
>stay there,

memdraw(2) or memlayer(2) works on user memory space.  When we
try to make it run in cpu(1) environment, huge amount of data will be
copied from cpu server's user memory space to terminal.  We are dealing
with several to tens megabyte images, and feel it's slow in a 100MBPS network.
We may have two ways here( or more?):
(1) forget cpu(1) command
(2) do memdraw and memlayer also in  kernel memory space.

I prefer second choice, because we have plenty of memory in cheap
price now. :-)  However, choosing (1) may also reasonable by the same
reason of above.  In this case, cpu server and terminal has no difference
each other...

Kenji  -- I may be on a wrong way, of course

[9fans] was 8½ slow and that lead to rio?

[Fco.J.Ballesteros]

IIRC, when 8½ was gone it was mainly to allow applications
to access the graphics device without having to go through the
window system. I'm wondering if that made 8½ so slow that the
change was needed. Or was the interface change from bitblt to the
draw operator the actual reason?