GNU bug report logs - #23801
25.0.95; term.el redraws extremely slow with bidi support enabled, and large buffers

Previous Next

Package: emacs;

Reported by: Phil Sainty <psainty <at> orcon.net.nz>

Date: Sun, 19 Jun 2016 10:38:01 UTC

Severity: normal

Found in version 25.0.95

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #17 received at 23801 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 23801 <at> debbugs.gnu.org
Subject: Re: 25.0.95; term.el redraws extremely slow with bidi support
 enabled, and large buffers
Date: Mon, 20 Jun 2016 17:28:43 +0300
> Date: Mon, 20 Jun 2016 11:41:17 +1200
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Cc: 23801 <at> debbugs.gnu.org
> 
> > Can you reproduce the problem using 'ls'?
> 
> No, the majority of commands do respond quickly.
> 
> I suspect you'll need to do something which repaints the entire 
> terminal.

I don't understand what that means.  The output from "ls" repaints the
entire terminal as well, as it produces 1500 lines, much more than is
shown in the window.

Perhaps you mean cursor motion commands, i.e. escape sequences that
move the cursor up and down the screen, not just down?  But if that is
the reason, I'd expect to see its signs in the profile, which was not
the case, I think.  If you load term.el (not the .elc file!), and then
run your experiments under the profiler (profiler-start), what does
profiler-report produce?

> Both previous examples are drawing a background colour (before 
> eventually
> drawing some text over the top, which happens quickly). Perhaps there 
> are
> a ton of escape sequences being processed for the colours?

Probably, but I don't see how bidirectional display could slow down
this processing, because AFAIU these escape sequences are converted to
faces that are put on the displayed text, something that doesn't
involve the bidirectional reordering for display at all.

> I guess it simply depends on exactly what each application is
> doing. GNU Midnight Commander is a file manager. I think "mc"
> followed by "exit" should be a pretty easy/safe test for you to try?

My problem is precisely that I cannot figure out what could the
application be doing that would be so profoundly affected by
bidirectional display.

Does making the screen buffer (term-buffer-maximum-size) smaller help
in any way?




This bug report was last modified 8 years and 336 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.