Re: [MiNT] WCOWORK implementation : conclusions.

["olivier.landemarre@utbm.fr" <Olivier.Landemarre@utbm.fr>]

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

Yes of course it's slower, does Odd wan't a vectorial offscreen for working
area? I not think that possible. Of course it's possible for all draw directly
by AES (widgets, rsrc), but not for working area, except thinking the
application component able to run throw network, especialy if this is use for
AES be able redraw without asking it to the application, it's impossible with
VDI because what is write on screen is made by a list of VDI instruction, but
you not know when you, you erase all for redraw something else, so you can't
erase buffer VDI instruction list. In my opinion only bitmap can be use for
offscreen.

> 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.
Why would you do this? This is incredible idea, how many memory is need for
predisplay a source code of 200Ko??? A lot
Do you think when I have done a small HTML viewer name "Gulliver" that I do a
bitmap and then scroll it, I can't imagine do it, no but I not use VDI to draw I
have an offscreen redraw then do a vro_cpyfm() but this bitmap is only the part
I need redraw no more. This could be usefull to help display some pictures in a
windows but no more, it can't be universal.
>
> 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.
I agree, in fact you are speeking about VDI feature, not really AES, you can
wan't to open an handle for a Window, and said this to VDI that coordinate send
for this handle is relative to the left higher corner, and when this windows is
move the AES said to the VDI this new position. Notice this not new at all,
Window have this for far, and Windom have this sort of facilities. We are not
speeking offscreen. I agree this should exist, but it does not because at this
time there is no link between AES and VDI
>
> > 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.
AES can already know when application have draw something without help of VDI,
just wait for wind_update(END_UPDATE), but notice there is this for only do a
cursor flash!

>
> > 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.
I not agree, see my answer before, not only some opcode.
>  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 agree for widget that is manage by AES but not for working area!
>
> 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.
Thanks
>
> 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).
RSC is vectorial, redraw it thorw network is not difficult, CICON can be send
once (I don't know any software changing CICON at fly), but application can
change some flags in RSC, and most not do it with AES functions (should perhaps
but it's slow), so you can't send the RSC, except RSC manage by AES itself.
>
> 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.
Yes
>
> > 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.
Try Anyplayer, it do it correctly! You can see it in MyAeS, launch Anyplayer,
and display a movie in a window (gem mode), put the Window on the top, then
display a menu on this, Anyplayer take into account rectangle list, the menu is
not redraw, and Anyplayer still continue to display it's video!
Now there is example that not work, take PureC open a file, then put the cursor
on high of the Window, then display menu, unfortunatly it display cursor in the
menu!



>  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.
In fact there is an other way to do this, try MyAeS or Magic (and I suppose
XAAES and NAES do it too), just ask "hide an application", all software I have
test it support it, Anyplayer too.


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

Yes soon after august!
Olivier
>
>
>
>
>


--