From mint-bounce@lists.fishpool.fi Fri Jul 22 00:55:23 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <1121986403.42e0276381231@webmail2.utbm.fr> Date: Fri, 22 Jul 2005 00:53:23 +0200 From: "olivier.landemarre@utbm.fr" 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@lin In-Reply-To: <20050721162007.rpqxazr3bzggw8o8@coolrunningconcepts.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.8 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.8 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 j6LMtMsK007301 Selon evan@coolrunningconcepts.com: > Quoting "olivier.landemarre@utbm.fr" : > > > 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 > > Of course its possible. > > > 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. > > Well, it is true that the VDI doesn't really have a good erase. Or rather > the > use of any erase functions aren't common the screen. However, I'm sure > you can > find a way to make this work. Perhaps by watching which calls affected the > entire area or something. Looks difficult, need help of VDI, perhaps should add a function to do it. In fact, we should change how to work, and add as in Opengl lists, and this list could be attach to a redraw of a window, but it should be an application wan't, if not it's near impossible I think. > > And while I'm on the subject, I've often mentioned the idea of a "canvas > widget". This would be quite beneficial. Basically it would be a new AES > object like you would put into a FORM, like a GBOX object. You place this > CANVAS object into a window. The canvas would open its own workstation > and the > AES could automatically handle the redraws. You then send VDI calls to the > CANVAS and it will remember them as well as draw them. A "clear" command > allows a specific clearing of the internal display list to forget all > previous > information (and should clear to whatever default color is defined by the > current theme - and default text color would be determined by theme, > etc). All > VDI calls sent to the CANVAS could be relative to the canvas itself, not the > screen, allowing the whole thing to be moved easily with the window. > > Such an AES object would simplify quite a bit of programming and could be > used > remotely quite easily. Older apps could either use bitmaps to display > remotely, like VNC, or see how well detecting screen clears works. > > > 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. > > RAM is cheap. Unlike the majority of people on this list, I'm actually > using a > system that has off-screen rendering. XP does not. OS X does, but OS X is > also all hardware accelerated. Xorg using Xcomposite extensions is about > the > same as what you are talking about - you draw off-screen and then blit the > changes to the window. Scrolling is horrible! > > Even if you can't keep the whole window off-screen, I would at least keep a > pretty sizable buffer off-screen to keep things sped up. > > > 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 > > Yup, I know. Just wondering who's gonna jump in and do it :) I not write a VDI, this could be run with NVDI (and most people use NVDI), but we can speek with Johan, it looks agree with this, it could be something like this: wind_get(WF_VDIHANDLE) this send a VDI handle for the window ask, inside this function do a v_opnvwk() then call a specific new function in VDI to specify offset v_origin(handle,x,y) (perhaps not this name I think already see this name but it's for example) Application can use it, if window move in wind_set(WF_CURXYWH), if handle was ask previously for this windows then call v_origin(handle,newx,newy) if wind_delete() this call v_clsvwk() This looks quite easy to add, is Johan and Odd agree? > > > 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! > > I don't want to know when the cursor flashes. I want to know when the > working > area has actually changed, and which portion of it has changed - > similar to the > Xdamage extension. Only way I can think of is for the VDI to keep a > "damaged" > rectangle and then every drawing operation, it can add to the rectangle > size. > > Other applications (such as virtual desktop managers that show icons of the > window contents or network protocols, etc) can then use this information to > inquire exactly what has changed so they can make updates as efficient as > possible. > > Redrawing a remote window every time the cursor flashes is just silly. > Speaking of which, any CANVAS widget or multi-line edit box should have an > AES > controlled cursor so we don't have applications locking the screen to draw a > blinking cursor. Some handling of insert-mode and over-write mode with > different cursors and things of that sort should be automatically handled by > the edit box, and shared with the canvas. > > > 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. > > With a compressed data channel, sending the parts of the RSC needed for that > specific AES call can be done at every call and it will still be faster than > sending the screen across. Yes it's true RSC is alway's small. > > > 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. > > What message is sent to the Application? And does the application > KNOW that it > is hidden and shouldn't make any more attempts to draw anything? This is something very stupid, there is no specific message, they send only a WM_MOVE message outside the screen, and it work with all application I know! Sometime solutions are original! and so simple! > > > Yes soon after august! > > Olivier > > Cool Olivier