Re: [MiNT] XAAES slow?

[Odd Skancke <ozk@atari.org>]

 Hello

tir, 21,.06.2005 kl. 13.40 -0400, skrev Standa Opichal:
> 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.

 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.

 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?

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

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

 And again, you have heard about wind_get(WF_CURRXYWH) and wind_get
(WF_WORKXYWH)? These two gives you exactly what wind_calc() gives you,
with a lot less overhead. Even on other AES's where theme never changes,
thus wind_calc() can use static calculations.

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

 This 'very good reason' translates to 'impossible to be as fast' when
non-static themes come into question.

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

 This is simply not true. Widgets can have any font-size, any sized
icons used for widgets, and they can be arranged in any order. In order
to keep these things as simple as possible, and to reduce the amount of
duplicate code in theme module code, I'm trying to develop a decent
system where a structure provided by the theme module describe the
window layout. This involves a callback for each widget to get its
dimentions. And for the existing theme-code this means calling the VDI
to get size of fonts, etc. And since this is done on a 'per-window'
basis to allow for greater modularity and theme change at anytime, it is
impossible to use constants. After this is done for a window, its
'instance' of the theme never change. Unless the application indicates
it supports theme-changes on created windows in which case the
geometrics may change drastically.

 For this reason, XaAES will never be as fast as n.aes (or other AES's)
doing wind_calc() on a never-before calc'ed window.

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


 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"



 Best Regards,
Odd Skancke