From mint-bounce@lists.fishpool.fi  Tue Jun 21 01:52:18 2005
X-Original-To: fnaumann@mail.boerde.de
Delivered-To: fnaumann@mail.boerde.de
Message-ID: <42B75568.3000709@seznam.cz>
Date: Mon, 20 Jun 2005 19:46:48 -0400
From: Standa Opichal <opichals@seznam.cz>
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: <1119298313.15790.119.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: <mailto:ecartis@lists.fishpool.fi?Subject=help>
List-unsubscribe: <mailto:mint-request@lists.fishpool.fi?Subject=unsubscribe>
List-Id: <mint.lists.fishpool.fi>
X-List-ID: <mint.lists.fishpool.fi>
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: **

Hi!

Odd Skancke wrote:
> read. What I said is that WinDom makes loads of unnecessary calls on
> each WM_REDRAW, and that zView serviced its redraws very slow because
> "the problem is that wind_set() in XaAES is slow". <-- read carefully!!!

OK :)

>>* There has always been open discussion with WinDom developers until we 
>>reached some point we could agree on (Unlike here :().
> 
>  Does the WinDom authors read this list? 

As far as I know yes. At least Arnaud and Me ;)

>  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.

Best Regards

Standa

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).