[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs and Gnome Canvas

From: Jan Djärv
Subject: Re: Emacs and Gnome Canvas
Date: Fri, 16 Jul 2010 09:33:16 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv: Gecko/20100608 Thunderbird/3.1

YAMAMOTO Mitsuharu skrev 2010-07-16 04.14:

   1. Don't draw during redisplay, but mark the updated area dirty so
      the upcoming exposure event can trigger the actual redraw for the
      area to be updated.

If some characters change attribute for example foreground color, you have to draw it, there will be no expose.

   2. Restrict the actual drawings to those in response to exposure
      events.  This is the standard way in GTK+ and Cocoa.  That would
      make double-buffering straightforward in GTK+ builds.

This is good, but can the current redisplay engine really update just a part of the display area? Maybe we can set clipping to the expose area? But most redrawings are not because of expose events, but of buffer changes, so I don't know if this would be such a big improvement. If you have double buffering, then you can just copy over the buffer when expose happens.

   3. Make expose_window etc. more efficient.  For example, the
      foreground of same row might currently be redrawn three times for
      some cases in order to handle overlaps between rows with minimal
      flickering.  This can be eliminated if double-buffering is
      introduced and whole the background is drawn at once and then
      whole the foreground is drawn afterwards.

Are there many of these "reduce flicker" drawings going on? Double buffer would be nice, I think it could help with images also (now images are drawn to a pixmap first, then copied to the frame).

   4. Scrolling in redisplay (x_shift_glyphs_for_insert and
      x_scroll_run) might require special treatment because copied area
      might be marked dirty at the time of scrolling.

        Jan D.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]