Re: [MiNT] XAAES slow?

[Odd Skancke <ozk@atari.org>]

tor, 16,.06.2005 kl. 18.55 +0200, skrev Zorro:
> >
> > Yes .. just tested under n_aes and it is fast. Could you provide me
> >with details on how you service WM_REDRAWS? XaAES combines WM_REDRAWS
> >too, you know, so if two redraws can be combined, they are. Perhaps
> >XaAES needs to treat WM_REDRAWS apps send itself differently...
> >  
> >
> I don't handle the GEM events myself, I use Windom for that.

 Ok, I found out why zView is so slow regarding handling of WM_REDRAWs.
The problem is that on XaAES, wind_calc() is slow, due to
configurability (which is not apparent yet). And, wind_calc() was called
SEVERAL TIMES for EACH WM_REDRAW received. In my opinion this is sick,
but this is what users of Windom must accept because I dont recon I can
convince windom authors. So now I have XaAES keep the calculations of
previous wind_calc()'s, which makes wind_calc() VERY fast providing the
request match a previous calc.

 Can anyone explain to me why wind_calc() calls are required here?

> 
> For the resize function, you can see by yourself in the source code of
> the file /catalog/catalog_size.c... it's easy to understand ( 50 lines
> of code maximum).

> 
> 
> >>And again, the problem is not only with zview, it was only an example.

 This is not a zview problem per say at all. It is overkill by Windom.
XaAES have all such info on each window. I wonder if we should define
new ways of obtaining such info on a "per-window" basis, since soon one
can change themes realtime in XaAES. Then it would be nice to have libs
such as windom gather correct info ;-)


 Best Regards,
Odd Skancke