bug#16594: 24.3.50; very slow redraw when resizing windows horizontally

[Eli Zaretskii <eliz@gnu.org>]

> From: Darren Hoo <darren.hoo@gmail.com>
> Cc: 16594@debbugs.gnu.org
> Date: Fri, 31 Jan 2014 11:16:47 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Darren Hoo <darren.hoo@gmail.com>
> >> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  16594@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.