Re: [MiNT] XAAES slow?

[Standa Opichal <opichals@seznam.cz>]

Hi!

Odd Skancke wrote:
> > > One thing is for sure; wind_calc() can not be used like in WinDom if we
> > > want to be able to change themes without restarting the AES. So here we
> > > can start discussing solutions....
> >
> > Why the way wind_calc() is used in WinDom would make it behave wrong 
> > when the window CURR vs. WORK rectangle deltas change? I can fix it.
>
>  Because traditionally wind_calc() is used to figure out the deltas of a
> 'virtual' window, this call will work with the currently installed
> theme.

Right.

> A theme change will also change these deltas and thus cannot be
> used on a window that was wind_calc()'ed when the previous theme was in
> use.

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.

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

> Using wind_set/get() for existing windows will ensure no such
> problems, as those work on the window in question, not a 'virtual' one.

As well as wind_calc() right. WinDom tries hard to not to duplicate any 
AES property (not even the WORK vs. CURR deltas).

> > BTW: There is no documentation on the complexity of particular AES call 
> > (unlike e.g. in the SGI STL documentation) so I assume the AES does 
> > whatever necessary to keep API calls as fast as possible at any point. 
> > As allways the comparison point would be n.aes as it is proven to be the 
> > fastest (or had been for some here already).
>
>
>  The whole point of XaAES is to evolve. If the goal of XaAES is to be
> n.aes, XaAES is very near completion, and theme changes at runtime is
> out of the question. XaAES have a very good reason for its slower
> wind_calc(); a standarized easy way for theme modules to tell XaAES the
> layout of the window.

I would not say that this is to be a 'very good reason' to slow 
something down. To extend my previous note about the complexity 
descriptions lack: One would assume that the complexity of 
wind_get/set/calc() is O(1) as the only thing it needs to actually do is 
to accumulate some constants (or precomputed values in case of themable 
AES - I would assume a decend AES to do that) and add them to the 
appropriate member of the resulting rectangle.

Best Regards

Standa