Re: [MiNT] XAAES slow?

[Odd Skancke <ozk@atari.org>]

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