Hi,

On Mon, 2008-03-03 at 15:49 +0100, Frederik Deweerdt wrote:
> On Mon, Mar 03, 2008 at 02:49:39PM +0100, Brice Figureau wrote:
> > I feel that this may not be the proper fix. I suppose that the event
> > loop should call rxvt_refresh_vtscr_if_needed more often than it does
> > right now.
> > Adding an Xevent counter shown that with the regular 10ms quick timeout,
> > and doing a text selection, it can process more than 50 X mouse events
> > before doing any refresh... Breaking the loop for 5 X events in a row,
> > also eliminates the issue...
> That sounds good. Just to be sure I got it right, it boils down to the
> following, isn't it?
> (with 10 events instead of 5, but that was enough according to my
> quick test).
> 
> Index: src/command.c
> ===================================================================
> --- src/command.c       (revision 259)
> +++ src/command.c       (working copy)
> @@ -2355,7 +2355,7 @@
>         if( select_res > 0 )
>         {
>             /* Select succeeded. Check if we have new Xevents first. */
> -           if( selpage == -1 && XPending( r->Xdisplay ) )
> +           if( selpage == -1 && XPending( r->Xdisplay ) > 10)
>                 continue;
> 
>             /* Read whatever input we can from child fd's*/

I used an independant counter instead of relying on XPending (I didn't
do X11 programming for almost 15 years, forgot about that one :-)).

But your code is not equivalent to mine, mine would have been:

-           if( selpage == -1 && XPending( r->Xdisplay ) )
+           if( selpage == -1 && XPending( r->Xdisplay ) <= 10)

Otherwise the behavior in front of a large backlog of Xevents is (like
mouse selecting a large text is producing): process all the events
except the last 10, waiting 10ms foreach (assuming no output from
underlying command) without refreshing. Thus you have refresh latency of
"size of backlog" x 10ms.

What we want (at least me) is to refresh from time to time while still
processing events, so we can achieve this by:
 * reducing the default select(2) timeout (which means process X11
events more often)

 * forcing a refresh every "n" X11 events.

If you choose the default timeout (10ms) along with 5 events, then you
have at worst a refresh every 50ms (20 refresh per second).

For a smoother experience, I'd suggest reducing select(2) timeout to 5ms
with 5 events for a 40 FPS (that what I'm currently using).

Hope that helps,
-- 
Brice Figureau <[EMAIL PROTECTED]>


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Materm-devel mailing list
Materm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/materm-devel
mrxvt home page: http://materm.sourceforge.net

Reply via email to