Re: [MiNT] WCOWORK implementation : conclusions.

[evan@coolrunningconcepts.com]

Quoting Olivier Landemarre <olivier.landemarre@utbm.fr>:
> Ok I handerstand this, I would like too, have this sort
> "windows-bitmaps" this will be easier for AES do some operations on
> windows like moving it. Praticaly the application should have a VDI ID
> v_opnbm() for each windows (it's suppose have a lot of memory (>128Mo)),

Also while things look faster and you do fewer redraws in many cases, there is
also a worst-case with this method.  You draw to the off-screen bitmap, and
then blit to the screen, so there are two operations instead of just 
one.  This
is especially true of scrolling - you might want to have a design with a very
tall memory bitmap and let the AES handle the scrolling completely by itself.

This is also a case when sending just the width and height would be good.  The
application doesn't need to know the position of the window on the screen if
the VDI is drawing off-screen.  And if the VDI is drawing direct, it can add
the window position to coordinates itself.

> but when AES should draw it? I suppose when application finish to draw
> application should send to AES that AES should draw it (probably with a
> clipping value). Now you want have a network display solution, so you

You could do automatic display.  If the AES and VDI are tied together, 
then the
AES can know when the application has made VDI calls and needs an update.

> have send bitmap throw network, this will be slow unfortunatly, it's
> like VNC, if I compare this solution to X11 and more powerfull Windows

It doesn't have to be slow.  Even if the VDI is drawing to offscreen bitmaps,
all you have to send across the network is VDI opcodes and parameters, not the
bitmaps.  If you attach to an already running session, and don't want to save
all VDI calls that have been made (aka a "canvas" widget), then you send the
bitmap across the network once (slow to connect to an existing session), but
updates can be done by just sending the VDI calls.

Additionally, you can rely on the host windowing system to handle all of the
window manipulations.  Only the display side needs to worry about window
positions and such.

Now, X11 can be sped up as fast or faster than VNC.  Even the old LBX 
extension
helps some.  I forget the name of the new one, but it a simple shell script
implementation.

> (sorry!) network display solution this slow (Windows solution is very
> very fast, notice that protocole for this is open (I can't remember
> name) for client (there is Linux solution client), so before doing this

Remote Desktop.

I'm not too familiar with it, but if you implement your protocol at a higher
level, so that the display side implements more of the work, there will be a
larger speedup.  For example, trasnfer the RSC file across once, and the
conversion between formats only has to be done once.  All widget drawing can
then be done on the display side.  Instead of having the AES call the VDI to
update the display and then detect the display update (probably by just 
looking
at the clipping rectangle that was used) and send a large bitmap over the
network, you just send the opcode and parameters for the AES call across the
network and let the remote side do all the drawing (with their current theme).

X's main drawback is the lack of widget-set that can be drawn client-side
instead of sending its bitmap across the network.   We already have a standard
widget set.

> perhaps we should look on existing solution, and I think it's vectorial
> solution use and not bitmap). Notice too that solution can't use
> hardware acceleration, for opengl for example this will be a problem.
> But why not but I not see what WCOWORK mode do in this, probably an id
> v_opnbm() for each window is enough no?

Well, actually X11 is vector, and with one of the new compressing extensions,
its very fast (there are always some bitmaps on the display, and X didn't
compress them).  X11 also supports OpenGL over the network, throgh the GLX
protocol.  However, if someone were to add OpenGL to the VDI, or at least
through some sort of standard API, it should be possible to send the 
calls over
the network instead of the result of those calls.

The problem isn't the network or WCOWORK, its the lack of an API for hardware
accelerated OpenGL.

> Virtual desktop is easy to do, I not see why you  need WCOWORK, the AES
> can do what it wan't this exactly like when you have a wind_close()
> without destroy, you simply ignore windows, in this case you have ignore
> some applications windows, change probably focus and menu when you
> change virtual desktop thats all.

As long as the application isn't a movie display program.  You switch virtual
desktops and the movie would still play on every virtual desktop.  I suppose
the AES can return no visible rectangles and hope the application isn't dumb
enough to ignore the rectangle list for speed and just assume its window is on
top.  It would also be inefficient since it would try to display constant
updates, but wouldn't be able to.  There is no "WM_HIDDEN" message to tell
clients they have no window.   Maybe sent "WM_UNTOPPED" to all windows 
or maybe
"WM_ALLICONIFY" before the virtual desktop change.  You can close a window
without destroying it, but there is no AES message that tells the 
program to do
so.

> > The biggest problem with WCOWORK mode as I see it, is that applications
> > that want to support WCOWORK and still be usable on older AES's need to
> > do extra checks. This will complicate writing applications, and one
> > needs access to both the older AES and XaAES. But I wont listen to
> > arguments of that sort, because WCOWORK removes so many restrictions it
> > deserves a shot.
> I think you have not think to all solutions, I try soon test an other
> but it's summer I prefer benefit from my garden at this time!

I agree.  I'd like to hear about the results of your testing and what
alternative you have come up with.