[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] XAAES slow?



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