From mint-bounce@lists.fishpool.fi Fri Jun 17 20:14:59 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: <1119029716.19495.8.camel@taro.coolrunningconcepts.com> 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> Content-Type: text/plain Date: Fri, 17 Jun 2005 20:10:35 +0200 Message-Id: <1119031836.15790.45.camel@linuxbox> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) 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: 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.3 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: fre, 17,.06.2005 kl. 12.35 -0500, skrev Evan Langlois: > On Fri, 2005-06-17 at 19:20 +0200, Odd Skancke wrote: > > Came to think of it .. what have you set your 'redraw_timeout' to? This > > is a timeout value XaAES uses to allow for clients to service its > > WM_REDRAWS. If all WM_REDRAWS are not serviced before this timeout, the > > clients that are being marked as "lagging" will have its WM_REDRAW queue > > reset and a full set of WM_REDRAWs are sent for each of its windows. > > Perhaps this is what happens here? Try to enlarge this value (I use a > > value of 2000 on the Milan, could be enough with 1000 on 060 Hades). > > So, slower applications get MORE redraw events? If the timeout is too short and a client is being marked as "lagged", then yes. This is what happens; If a client does not service its WM_REDRAWS before the timeout expire, XaAES mark it as "lagging". This also happens if a client locks up, or is very busy. XaAES will now start to service new WM_REDRAWS for the lagged client, which is noticable as the redraw areas are just filled with gray color. As soon as the client enters any of the evnt_xxx() calls, its lagged status is cleared, and a full set of WM_REDRAW's for all its windows is generated. This scheme prevents applications from blocking the whole system. A similar thing happens when a client calls menu_popup() or form_popup (). Since these are non-blocking now, XaAES will intercept anddraw gray rectangles in response to WM_REDRAWS sent to its windows. This is done so because apps think these calls should block screen. Best regards, Odd Skancke