Re: [MiNT] XAAES slow?

[Odd Skancke <ozk@atari.org>]

 Ok, calmed down after a small short circuit caused by comments in
another post here....


tir, 21,.06.2005 kl. 17.10 -0400, skrev Standa Opichal:
> Hi!
> 
> I must say that all in all you are right that it seems not to be a best 
> practice to use wind_calc() in an existing window context. But read on 
> please...

 Thanks ;-)

> 
> Odd Skancke wrote:
> >>But this situation doesn't happen in WinDom. The wind_calc() is used 
> >>every time you do WinDom equivalent of wind_get( WORKXYWH ) so the theme 
> >>change will be accomodated appropriately.
> > 
> >  My arguments are based on situations where theme changes does not
> > affect already created windows (which must be specifically supported by
> > each application). In this case wind_calc() will return wrong (current
> > theme) deltas instead of the (previouse theme) deltas that were
> > effective at the time the window was created. So yes, this situation
> > will arise as WinDom handles things now.
> 
> Ok, this way it would not work obviously.
> 
> >  I still would like to see WinDom use wind_get/set() to gather info
> > about existing windows. Why the use of wind_calc() at all regarding
> > existing windows when wind_get/set() exists?
> 
> I think it is possible to use the wind_get() in the place I am talking 
> about in WinDom. It is now just an implementation dependency as WinDom 
> implements some AES features when those are missing in the AES in use 
> (toolbars and window menus). I will keep an eye on that (or someone in 
> the WinDom list as I am hading out for the next weeks) and eventually 
> avoid this I believe.
> 
> >>Have you had a look into the CVS when you say it would not cope with 
> >>such a situation actually (I have sent the URL here previously 
> >>http://windom.sf.net)?
> > 
> >  Ah, it is available via CVS :) Didnt know that.
> 
> You didn't bother to click on the link ;)

 I did actually, but obviously I didnt look close enough :)

> 
> >  And since I cannot see any other use for wind_calc() than calculate the
> > deltas of a 'virtual' window, it will work on the theme in use, because
> > its results are supposed to be used to create a new window _now_ (with
> > the current theme).
> 
> Hmm, what about the following:
> 
> switch( evnt_messag() )
>    case WM_SIZED:
>      give_me_work_rectangle() to optimize further redraws and setup all 
> coordinates now rather than doing this in the WM_REDRAW where this 
> doesn't belong to.
>        * for one example let say I have a lot of elements that need to 
> recompute on window size/position change and I need this to be handled 
> before I do the redraw...

 wind_get(WORKXYWH) will get you current work-area (before you do
wind_set(WF_CURRXYWH) to change it) Then you can do wind_get(WORKXYWH)
again to get new work-area (after wind_set(WF_CURRXYWH)). Then you can
recompute things that need to be recomputed. Then you just service the
WM_REDRAWS, waiting in evnt_multi()/evnt_mesag(). Normally XaAES sends
WM_REDRAWS only for areas that really need to be redrawn. This means
that if the user makes the window smaller, no WM_REDRAWS are sent at
all. If, however, you need to reformat the content of the window, like a
browser or documentprocessor, you can have XaAES send redraws for the
whole window by using wind_set(handle, WF_OPTS). This saves the overhead
of you having to send yourself WM_REDRAWS.

 Is this something along the lines you wanted to do?

> 
> Would we need an extended API to do wind_calc() in the particular window 
> context to accomodate theme changes?

 I still dont get why wind_calc() is needed here. What does wind_calc()
provide that wind_get(handle, WF_CURRXYWH/WF_WORKXYWH) doesnt? I think
all the API's you need to do the above is already there.

 As far as I know, you cannot change (that is, remove/add or move) the
widget layout on existing windows anyway. If this was possible,
wind_calc() would also have a window-context (that is, a window-handle
parameter), I'm sure. 

> 
> >  Why cant we just accept that wind_calc() should not be used to gather
> > info on existing windows? Because it works on all other AES's? This is
> > the very definition of a HACK in my opinion, "wow, works! lets forget
> > documentation, propably there is no future either"
> 
> Which documentation states when _exactly is the wind_calc() to be used_ 
> as opposed when it _can_ be used? IIRC no documentation ever gave us 
> this information until now.

 I think that wind_calc() not having a specific context says enough. And
when there is no specific context, I think 'current' context is a good
assumption, in this case the 'current' theme.

> 
> Anyway the compendium states the following (which is very similar to the 
> problem we have - no particular window context available):
> 
> Comments       wind_calc() is unable to calculate correct values when
>                 a toolbar is attached to a window. This can be corrected,
>                 though, by adjusting the values output by this function
>                 with the height of the toolbar.
> 
> Thanks for making it clear.

 No problems.

Best Regards
Odd Skancke