From mint-bounce@lists.fishpool.fi Thu Jul 21 11:22:11 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <42DF69A1.9010504@utbm.fr> Date: Thu, 21 Jul 2005 11:23:45 +0200 From: Olivier Landemarre User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MiNT List Subject: Re: [MiNT] WCOWORK implementation : conclusions. References: <1121808544.5660.30.camel@linuxbox> <20050719215349.6dlkrcbl47c4g88s@coolrunningconcepts.com> <42DDF84C.10409@asrael.franken.de> <42DE3FF8.6050802@utbm.fr> <1121892800.5660.105.camel In-Reply-To: <42DF5051.7060806@gabo.pl> Content-Type: text/plain; charset=UTF-8; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by portail1.utbm.fr id j6L9Jnma032699 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: olivier.landemarre@utbm.fr Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.4 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id j6L9MBFj013457 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