[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] WCOWORK implementation : conclusions.



Adam Klobukowski wrote:

Olivier Landemarre napisał(a):

Hello Odd

...

I will try to explain a few things that will be possible with WCOWORK
mode. Mind you, these things have to be implemented first. This fact,
that things have to be implemented first, is what makes certain ppl not
see the benefit. New features or new things that dont have effect NOW is
called incomatible, and of no use. Some of the things (altho not yet
existing), will not be possible without WCOWORK mode.



Thanks a lot, I have think to your answer and have only technical discution with you.

1. The AES can setup offscreen bitmaps for the windows opened by the
application. These 'window-bitmaps' only contains the WORK area of a
given window, and this can be used for multitude of things. For example
effectful windowing on hardware capable of it, or having the output sent
over the network in a server/client solution. Ofcourse, much of this
also needs VDI support.


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


You're mistaken here.

Most modern windowing systems are using such (offscreen windows) technology. Windows does so sinse 2000 or XP. X uses it since introducing X.org, transparency and similar stuff. And it aint slow (with HW acceleration ;) ).

I know this for OSX, but I think when send redraw to network on other computer, most is vectorial, I can't imagine this could be bitmap only! But for 2000 I don't think so I have one here, and really it look not have offscreen for working area because this zone is redraw far after the other parts of the windows. I don't know if it's because software should do something specific and software do not it's possible.


When to draw it? AES knows best: when it needs to (window redraws), and if application modifies it. This need AES - VDI integration, but it will be fast, esp. with FastRam - fVDI already does such things IIRC (if FastRam avialible, there is whole-screen buffer in fastram, all operations are done on it, and modified parts are copied to st-ram (with simple move it is fast)).

Yes you have true, it's need AES - VDI integration, this is only way to do this correctly, it can't be solve with only AES changes.

Olivier