Re: [MiNT] WCOWORK implementation : conclusions.

[Johan Klockars <johan@klockars.net>]

> > Ok I handerstand this, I would like too, have this sort
> > "windows-bitmaps" this will be easier for AES do some operations on

IMO, the only good reasons to do this kind of thing is if you draw very 
complicated things in your windows, or you want to do things like 
transparent or dynamically resizable windows. For normal work it's 
generally not a good idea, which is probably why it's not the default 
mode on any window system I'm aware of (X has always been able to do it, 
but it's seldom used, and I can't say I've seen a Windows program do it) 
that doesn't make transparency and dynamic resizing a priority (MacOS X, 
and  other "next generatio" graphics systems).

> > 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)),

Using up a lot of memory for this may be OK if you have some kind of 
accelerated Atari machine with lots of RAM and no graphics card. The 
graphics cards we have, though, with the possible exception of that 
RagePro based PCI thing that was sold for the Milan, don't have enough 
memory to do useful backing storage in useful resolutions. And you 
_definitely_ don't want to do backing storage in normal RAM if you have 
a graphics card (no hardware accelerated drawing and it will usually be 
slower to blit things to the screen than to just redraw them from scratch).

> 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


Doing this kind of drawing in off-screen bitmap and then blitting to the 
screen is, IMO, only reasonable if you want that transparency etc. 
Otherwise you'd be better off drawing the things on screen directly that 
can be and drawing the rest in the off-screen bitmaps.
Updating by blitting can work relatively well in many cases, but in 
others it's just awful (witness the ARAnyM SDL driver).

Another bad case is when the application in question is drawing in its 
off-screen bitmap but nothing (or only parts of it) gets displayed at 
all because it's covered by other windows.

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


You really wouldn't want to do that.

> the VDI is drawing off-screen.  And if the VDI is drawing direct, it 
> can add
> the window position to coordinates itself.


Having VDI coordinates that are relative to some arbitrary point is 
indeed something that could be useful. I've always planned to add that 
to fVDI.

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

I believe most other window systems have the clipping handling bundled 
with the drawing so that an application doesn't have to deal with that 
by walking a rectangle list like with the VDI/AES. It obviously also 
makes it impossible to draw outside your own windows.

> but when AES should draw it? I suppose when application finish to draw
>
> 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.


There is already that screen lock thing in the AES that could indeed be 
used for this kind of thing.
But, as I've mentioned before, blit updates isn't such a good idea, IMO.

> have send bitmap throw network, this will be slow unfortunatly, it's
>
> 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


Yes, since the drawing part itself could be at the other end of the network.
But this can work equally well without blit updating.

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


Yes.

Anyway, doing VDI drawing via a network shouldn't be bad at all. Just 
consider what the graphics cards on the Falcon are capable of with a few 
(4-6 perhaps) Mbyte/s of bandwidth.
And with VDI extensions to allow remote caching of bitmaps and fonts (to 
some degree already possible, like what fVDI does on the Eclipse/RageII, 
but that has limitations) it could be really nice.

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


Well, there is already an OpenGL based VDI (fVDI on ARAnyM with the new 
native driver). It might be interesting to see if that could be 
convinced to run over a network.

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


No, the problem is hardware accelerated OpenGL in the first place.
In the only place where we have it, ARAnyM, it can be used, both 
directly and by the VDI.

> Virtual desktop is easy to do, I not see why you  need WCOWORK, the AES


They have been done before.

--
| Why are these | johan@klockars.net
|  .signatures  |
| so hard to do | http://www.klockars.net
|     well?     | (fVDI, MGIFv5, QLem)