From mint-bounce@lists.fishpool.fi  Fri Jun 17 23:53:44 2005
X-Original-To: fnaumann@mail.boerde.de
Delivered-To: fnaumann@mail.boerde.de
Subject: Re: [MiNT] XAAES slow?
From: Evan Langlois <Evan@CoolRunningConcepts.com>
To: Odd Skancke <ozk@atari.org>
Cc: MiNT List <mint@fishpool.com>
In-Reply-To: <1119044109.15790.57.camel@linuxbox>
References: <1118934446.15790.7.camel@linuxbox>
	 <0007b541.01948d720389@smtp.t-online.de>
	 <1118973980.15790.24.camel@linuxbox>  <1119028842.15790.29.camel@linuxbox>
	 <1119029716.19495.8.camel@taro.coolrunningconcepts.com>
	 <1119031836.15790.45.camel@linuxbox>
	 <1119033788.19495.22.camel@taro.coolrunningconcepts.com>
	 <1119044109.15790.57.camel@linuxbox>
Content-Type: text/plain
Date: Fri, 17 Jun 2005 16:51:32 -0500
Message-Id: <1119045093.19495.31.camel@taro.coolrunningconcepts.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.1.1 
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - esc14.midphase.com
X-AntiAbuse: Original Domain - fishpool.com
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - CoolRunningConcepts.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-ecartis-version: Ecartis v1.0.0
Sender: mint-bounce@lists.fishpool.fi
Errors-To: mint-bounce@lists.fishpool.fi
X-original-sender: Evan@CoolRunningConcepts.com
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=-1.0 tagged_above=-50.5 required=7.0 tests=AWL,
 BAYES_00
X-Spam-Level: 

On Fri, 2005-06-17 at 23:35 +0200, Odd Skancke wrote:
>  When there are WM_REDRAWs pending, XaAES prevents movements of windows
> until those are serviced by the target. This needs to be done to prevent
> a window moving into an area for which a WM_REDRAW have been generated,
> resulting in overwriting the moving window. I will look into updating
> WM_REDRAW queue on movements and modify/remove not-serviced WM_REDRAWs
> to see if that is possible.

Ah!  That makes sense.  I hadn't thought of that possibility.  I've been
around X too long where the coordinates you get are relative to the
window and the application doesn't care where the window is.  I had
forgotten the possibilty of a window moving over an area with a pending
redraw.  Hmm .. thats tough.