From mint-bounce@lists.fishpool.fi Tue Jun 21 19:42:48 2005 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <42B850F7.7030503@seznam.cz> Date: Tue, 21 Jun 2005 13:40:07 -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: <1119340933.15790.149.camel@linuxbox> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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=-0.4 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Hi! Odd Skancke wrote: >>> One thing is for sure; wind_calc() can not be used like in WinDom if we >>>want to be able to change themes without restarting the AES. So here we >>>can start discussing solutions.... >> >>Why the way wind_calc() is used in WinDom would make it behave wrong >>when the window CURR vs. WORK rectangle deltas change? I can fix it. > > Because traditionally wind_calc() is used to figure out the deltas of a > 'virtual' window, this call will work with the currently installed > theme. Right. > A theme change will also change these deltas and thus cannot be > used on a window that was wind_calc()'ed when the previous theme was in > use. But this situation doesn't happen in WinDom. The wind_calc() is used every time you do WinDom equivalent of wind_get( WORKXYWH ) so the theme change will be accomodated appropriately. Have you had a look into the CVS when you say it would not cope with such a situation actually (I have sent the URL here previously http://windom.sf.net)? > Using wind_set/get() for existing windows will ensure no such > problems, as those work on the window in question, not a 'virtual' one. As well as wind_calc() right. WinDom tries hard to not to duplicate any AES property (not even the WORK vs. CURR deltas). >>BTW: There is no documentation on the complexity of particular AES call >>(unlike e.g. in the SGI STL documentation) so I assume the AES does >>whatever necessary to keep API calls as fast as possible at any point. >>As allways the comparison point would be n.aes as it is proven to be the >>fastest (or had been for some here already). > > > The whole point of XaAES is to evolve. If the goal of XaAES is to be > n.aes, XaAES is very near completion, and theme changes at runtime is > out of the question. XaAES have a very good reason for its slower > wind_calc(); a standarized easy way for theme modules to tell XaAES the > layout of the window. I would not say that this is to be a 'very good reason' to slow something down. To extend my previous note about the complexity descriptions lack: One would assume that the complexity of wind_get/set/calc() is O(1) as the only thing it needs to actually do is to accumulate some constants (or precomputed values in case of themable AES - I would assume a decend AES to do that) and add them to the appropriate member of the resulting rectangle. Best Regards Standa