Re: [MiNT] XAAES slow?

[Odd Skancke <ozk@atari.org>]

søn, 19,.06.2005 kl. 01.54 -0500, skrev evan@coolrunningconcepts.com:
> Quoting Odd Skancke <ozk@atari.org>:
> 
> 
> >> 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,
> 
> I had a short discussion with one of the original authors of Windom about some
> of its odd redraw behavior and removing quite a few extra calls that weren't
> necessary.  Some very basic changes would remove quite a few redundant calls.
> 
> The response was to bring it up on the Windom list and talk to ... I 
> forget who
> exactly is the new "major developer" .. but they are on this list and the
> aranym one.  Get with me if you'd like a recap of my suggestions.

 Yes, I'd like to see what your suggestions were :)

> 
> > 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
> 
> I bet you could convince them.   In fact, I heard there was some new version
> coming out with a new API, and since I couldn't find much of any 
> information on
> it, I just decided I was spread too thin to look into it.

 The first thing I would like to see is getting Windom into the CVS, so
one can help.

> 
> > previous wind_calc()'s, which makes wind_calc() VERY fast providing the
> > request match a previous calc.
> 
> Thats an excellent way to handle it!
> 
> >  Can anyone explain to me why wind_calc() calls are required here?
> 
> If I remember, the information is never saved, so for each window a number of
> calls are done and intersections computed (more than needed), and then a user
> function is called for each rectangle, and since the previous 
> information isn't
> saved, it makes more calls.

 There are WF_WORKXYWH and WF_CURRXYWH wind_set() modes to figure out
all one need to service anything about an already opened window. I dont
get why wind_calc() is used here.

> 
> >  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 ;-)
> 
> A theme change would likely signal a full redraw of every window, and would
> clear any internal AES caches.  Since the current solution doesn't cache any
> information, client side, things should work fine.   The changes I suggested
> wouldn't hurt this either as it only holds this information during the redraw,
> and not between redraws.  As long as no apps cache such information between
> redraws, you should be fine.

 This is not so simple. The problem is that wind_calc() will return
information based on the 'current' theme, which may have changed since
the already opened window for which info is collected was opened. As
soon as a window is opened, its layout (that is, relation between a
window's full extent and work area) wont change. This means that a theme
change only affects windows opened _after_ the change. I will most
probably make theme changes possible on already opened windows too, but
this is somehting apps would need to support and new things such as
WM_GMCHG (GeoMetricChanGe -- if that is the correct word ;-)) message
tells the application that window's layout have changed.

> 
> Is there any documentation on the theme ability?  Is it only window themes, or
> buttons and sliders and such too?

 No documentation as far as I know. The only "attempt" at themes are the
WF_DCOLOR/WF_COLOR wind_set() modes. And the work I do now is in very
early stages, defining api's etc.


 Best Regards
Odd Skancke