Hi, On Sun, 2008-03-02 at 16:41 -0800, Gautam Iyer wrote: > On Sat, Mar 01, 2008 at 04:04:52PM +0100, Brice Figureau wrote: > > >>> I'm really pleased with what I found so far, except that mouse > >>> highlighting some text is slow as hell (it takes about 1 second to > >>> refresh the highlighted section when I move the mouse). > >>> > >>> This was tested with the default parameters (no sys config, no file > >>> config). I also checked without xft and/or antialiasing, but still > >>> so slow. > >>> > >>> Did I miss something or is it a bug? > >> > >> I think this is intentional. IIRC, mrxvt doesn't highlight text until > >> the mouse has almost stopped moving. This was a good thing earlier, > >> since Xft + AA redraws were quite expensive. Things have changed now, > >> so perhaps we can either get rid of it, or add an option to disable > >> it... > > > > Can you point me to where have a look in the code, I'll see if I can > > produce a patch to add an option to disable it? > > I remember looking through the mouse code a while ago. (Mainly to > implement the xterm2 mouse standards, which goes nicely with Vim). I > never did end up understanding the code...
Thanks. After some code reading, I think that I understand what happens: It seems there is an event loop (in rxvt_cmd_getc) which basically is waiting for either some X events or some characters from the underlying command (shell or whatever). This event loop contains a select whose timeout can be short or long depending on the type of current action (ie should do a selection or not, etc...). The short timeout is 10ms (TIMEOUT_USEC). If the timeout is reached (ie the underlying command didn't return anything for 10ms), then we try to grab new X events (that could have piled up during the select), returning to the top part of the event loop to process them, and finally ending again in the select. Only if there is no more events for a 10ms timeframe, then the screen refreshed (and my selection by the same way). This means, that is you continuously expand a mouse selection, then the screen will be refreshed only later when we can find a 10ms span without any new events. My measurement showed that we had several selection change/increase before going to the screen refresh part (sometimes about 10 or more event loop, each waiting at least 10ms, for a grand total of more than 100ms). A crude hack is to force the short select timeout to 1ms instead of 10ms in rxvt_adjust_quick_timeout. I did it and indeed it fixes my issue. 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... Does anyone wants a patch? -- 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
