Re: [MiNT] XAAES slow?

[Odd Skancke <ozk@atari.org>]

man, 20,.06.2005 kl. 14.29 -0500, skrev evan@coolrunningconcepts.com:
> Quoting Frank Naumann <fnaumann@boerde.de>:
> 
> >>> Ok, I found out why zView is so slow regarding handling of WM_REDRAWs.
> >>>
> >> Again, Zview isn't slow in the redraw because it's fast on *any* others AES.
> >
> > That's not a real argument I think.

 I also agree here.

> 
> Agreed.  "Fast" is relative.  If the application can be profiled it should be,
> and making superfluous OS calls is the first thing to get rid of.  You can
> never assume an OS call will return in any reasonable length of time, except
> for a RTOS.
> 
> >>> The problem is that on XaAES, wind_calc() is slow.
> >>>
> >> This is the real problem.
> >
> > And ozk already mentioned that he cache now the wind_calc result inside
> > XaAES and that this heavily speedup the redraw (and it should now the
> > same as on other AES).
> 
> This should make XaAES faster for more than just zview, but I have to 
> agree that
> its the applications responsibility to remember these details and not keep
> asking the AES for data that doesn't change.   Fixing this in zview 
> should make
> zview faster than it is now, on ALL AES versions.

 Very much true.

> 
> However, in zviews defense, in the presence of theming, this data WILL change,
> and its possible that zview will perform correctly if a theme change occurs
> while its running.  XaAES would obviously dump its wind_calc cache when the
> theme changes.

 This data will NEVER change, unless the application tells XaAES that it
supports geometric-changes (still wonder if thats the correct term) on
already created windows, in which case XaAES would notify the
application in some way (WM_GEOCHG, for example).

 What WILL change is this; application creates window, opens it. User
changes theme, this will not affect already created window since
application does not support WM_GEOCHG (just go with it for now). But
this WILL change what wind_calc() returns, since its use was intended to
generate FULL/WORK area coordinates of a window one is about to create,
or am I completely wrong here? If I am wrong, I dont understand why the
wind_get(handle, WF_CURRXYWH) and wind_get(handle, WF_WORKXYWH) modes
exist. One can, if one wants to be extremely difficult, say "what if
theme changes between wind_calc() and wind_create() calls?" Well ...
perhaps I'm not supposed to say this, but if a user manages that, I'll
give that user a reward.

> 
> > Beside from that I think for zview (or the underlying library) it's also
> > good to know about overflous AES calls that can be optimized away (with
> > additional speedup).

 Yes, definately. And keep things as simple as possible :)

> 
> This is what profilers are for :)
> 
> > So theoretically all should be happy now :-)

 

> 
> Until themes are thrown into the mix.

 Yes, becaues of wind_calc() and its usage in WinDom. Hopefully we can
find a solution.


 Best Regards,
Odd Skancke