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