From mint-bounce@lists.fishpool.fi Fri Jun 17 23:38:37 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: <1119033788.19495.22.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> <1119031836.15790.45.camel@linuxbox> <1119033788.19495.22.camel@taro.coolrunningconcepts.com> Content-Type: text/plain Date: Fri, 17 Jun 2005 23:35:09 +0200 Message-Id: <1119044109.15790.57.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.4 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: fre, 17,.06.2005 kl. 13.43 -0500, skrev Evan Langlois: > On Fri, 2005-06-17 at 20:10 +0200, Odd Skancke wrote: > > 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. > > Instead of redrawing all windows completely when "lagged" is cleared, > can all the redraws for which XaAES has handled a redraw be merged into > 1 rectangle? This would have the same effect if the whole screen had > been drawn on, but could save some resources if most of the window had > never been touched. Yes, this is probably possible, and I'll look into this later... > > > This scheme prevents applications from blocking the whole system. > > When would the application block the whole system? It would just > eventually do its redraws. The task switching doesn't depend on the AES > at all does it? 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. > > > 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. > > I assume you mean this is just for the application that has called > menu_popup or form_popup. Do the rest of the applications still get > regular redraws? Correct. Best Regards, Odd Skancke