Re: [MiNT] XAAES slow?

[Standa Opichal <opichals@seznam.cz>]

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...

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 ;)

>  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...

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

>  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.

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.

Standa