From mint-bounce@lists.fishpool.fi Sun Jun 19 12:44:41 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Subject: Re: [MiNT] XAAES slow? From: Odd Skancke To: MiNT List In-Reply-To: <20050619015454.t7xyf5g6awisk0o4@coolrunningconcepts.com> References: <42B09A61.9020204@yahoo.fr> <1118887948.12057.11.camel@linuxbox> <42B18304.3030406@yahoo.fr> <1118934446.15790.7.camel@linuxbox> <42B1AEE7.3010707@yahoo.fr> <1119105225.15790.70.camel@linuxbox> <20050619015454.t7xyf5g6awisk0o4@coolrunningconcepts.com> Content-Type: text/plain; charset=utf-8 Date: Sun, 19 Jun 2005 12:40:26 +0200 Message-Id: <1119177626.15790.88.camel@linuxbox> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: ozk@atari.org Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.4 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id j5JAifke022576 søn, 19,.06.2005 kl. 01.54 -0500, skrev evan@coolrunningconcepts.com: > Quoting Odd Skancke : > > > >> 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