GNU bug report logs - #16594
24.3.50; very slow redraw when resizing windows horizontally

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Darren Hoo <darren.hoo <at> gmail.com>
Cc: 16594 <at> debbugs.gnu.org
Subject: bug#16594: 24.3.50; very slow redraw when resizing windows horizontally
Date: Fri, 31 Jan 2014 10:22:06 +0200

> From: Darren Hoo <darren.hoo <at> gmail.com>
> Cc: 16594 <at> debbugs.gnu.org
> Date: Fri, 31 Jan 2014 11:16:47 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Darren Hoo <darren.hoo <at> gmail.com>
> >> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  16594 <at> debbugs.gnu.org
> >> Date: Fri, 31 Jan 2014 02:57:58 +0800
> >> 
> >> In case I have not described my problem precise enough, maybe this
> >> screencast I take will clear things up a bit:
> >> 
> >> http://blog.glib.cc/resize.html
> >
> > I see nothing of the kind on my system.  Moreover, what you show
> > doesn't look like an Emacs redisplay problem, but rather like some
> > low-level redraw problem.
> 
> indeed, it seems that this redisplay_internal is problematic:

No, it's read-char and x_write_glyphs.  The latter calls the X server.

Of the total 345 ms, 130 ms are used by read-char and another 154 ms
by x_write_glyphs and x_clear_end_of_line, together these two take 284
ms, or 82% of the time.  The rest is distributed among the following
functions that are part of the display engine:

  redisplay_internal   18 ms
  update_window        36 ms
  update_window_line   14 ms

Given that dragging the divider involves redrawing every line in every
window, these times are entirely reasonable, and seem to confirm my
suspicions that the problem is on the X level.

Previous Next

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