Re: [MiNT] WCOWORK implementation : conclusions.

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

Selon evan@coolrunningconcepts.com:

> Quoting "olivier.landemarre@utbm.fr" <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