Re: [MiNT] XAAES slow?

[Odd Skancke <ozk@atari.org>]

ons, 29,.06.2005 kl. 13.22 -0500, skrev Evan Langlois:
> On Tue, 2005-06-21 at 23:38 +0200, Odd Skancke wrote:
> 
> >  I cant believe this. wind_calc() does NOT work on a given window
> > goddamned it! It has not window context. wind_get/set() does! What the
> > hell is the problem with you all? I'm about to give up this shit!
> 
> I can understand your frustration, but don't give up!

 I was a bit unstable when that came out ,-)

> 
> The problem is people are talking about 3 different things - 
> 1 - The possibility that apps can deal with a theme change if they use
> wind_calc to always check the deltas for the current theme.
> 2 - The idea of backwards compatibility for broken apps that use
> wind_calc wrong, and so wind_calc() should still return data for the old
> theme for theme - and yes I know a window id not passed, but read on!
> 
> My point was that if Windom is over-using wind_calc(), it would always
> get the deltas of the current theme, and so it might allow the
> application to automatically deal with a theme change while running
> without having to tell it (maybe send all apps a resize message and hope
> they figure everything out), assuming wind_calc() always gives the data
> for the new theme.  I don't think this is likely.  

 If the application works exclusively on WORK area of its windows (using
the WCOWORK mode, see other posting or newcalls.txt), no messaging by
the AES would be necessary, unless the WORK itself changed in which case
WM_xxx is sent, as if a normal move or resize happened. But I think that
some form of notification will be present anyway, just in case unforseen
situations require it.

> 
> I think your idea of a "theme has changed" message is better, but its
> not yet decided how an application is to react to this.  It may be
> better for the application to tell the AES - I can survive theme
> changes, and I'll accept "theme has changed" messages, and only in that
> case, and that case only, have wind_calc return data for the new theme,
> not the old, AFTER the message has been recieved and somehow responded
> to.  Perhaps when an application has told the AES it supports this, send
> those apps a RESIZE and then a REDRAW and assume those apps will respond
> correctly.

 I think that we can say that when an application enters WCOWORK mode,
it it also expected that it knows about Theme changes.

> 
> wind_calc() for older apps would report the same data, for the old theme
> that that application is still using, and new windows from that
> application would use the old theme.
> 
> Now - to make that work ...
> 
> Have you considered storing the theme (or the deltas used by a
> particular theme) by the application's pid (in the process table or
> something along those lines)?  wind_calc would then lookup which theme
> that application is using and act accordingly.   If themes for a
> particular application aren't to change while they are running, then
> this would provide the backwards compatibility that people seem to
> expect.

 Yes, this close to what is done now. And this will be kept to be
backwards compatible. What I want to see is new apps not act like old
apps :)


Best Regards
Odd Skancke