From mint-bounce@lists.fishpool.fi Mon Jun 20 14:39:24 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <42B6B87A.1080108@seznam.cz> Date: Mon, 20 Jun 2005 08:37:14 -0400 From: Standa Opichal User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] XAAES slow? 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@coolrunningco In-Reply-To: <1119177626.15790.88.camel@linuxbox> Content-Type: text/plain; charset=UTF-8; format=flowed X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: opichals@seznam.cz 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=2.1 tagged_above=-50.5 required=7.0 tests=BAYES_00, RCVD_IN_SORBS X-Spam-Level: ** Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wh58-508.st.uni-magdeburg.de id j5KCdNel002387 Hi! Just few notes/answers: * It seems to me that the subject 'XAAES slow?' changed to 'Blame others'. What about solving the root of the problem here? :( * There has always been open discussion with WinDom developers until we reached some point we could agree on (Unlike here :(). * Definitely bring the discussion on the WinDom list if this proves to be the N.AES vs. XAAES problem ;))) * http://windom.sf.net FYI: I will be offline most of the time for approximately 3 weeks. Best Regards STanda Odd Skancke wrote: > 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