emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs and Gnome Canvas


From: YAMAMOTO Mitsuharu
Subject: Re: Emacs and Gnome Canvas
Date: Sat, 17 Jul 2010 10:00:40 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)

>>>>> On Fri, 16 Jul 2010 13:39:28 +0300, Eli Zaretskii <address@hidden> said:

>> The current code assumes that drawing is mainly done for updated
>> area during redisplay, and expose_window is rather subsidiary.  So
>> the latter is not so optimized for frequent use.

> Is it really worth our while to optimize that?  What would be the
> situation where we will get frequent expose events?

If we change drawing during redisplay to addition of dirty area, then
expose occurs on every window-system-level event handling or explicit
flush.

>> For example, it does not accept multiple rectangles for exposed
>> area that is necessary for minimal redrawing.

> Don't we get a single expose event for each exposed rectangular
> area?  If we do, what would be the gain from processing multiple
> rectangles at once?

I'm not X11 expert, but Expose event contains the `count' member.

  The count member is set to the number of Expose events that are to
  follow. If count is zero, no more Expose events follow for this
  window. However, if count is nonzero, at least that number of Expose
  events (and possibly more) follow for this window. Simple
  applications that do not want to optimize redisplay by
  distinguishing between subareas of its window can just ignore all
  Expose events with nonzero counts and perform full redisplays on
  events with zero counts.

Cocoa has a special method for that.

We can minimize rows to be drawn compared with a large union rectangle
that overapproximately covers all rectangles, and we can reduce the
overhead of processing the same window for possibly duplicated areas
compared with calling expose_window for each rectangle.

>> It also reuses functions primarily designed for drawing during
>> redisplay and that does not necessarily efficient for exposure
>> handing.

> Are you talking about draw_glyphs?  If so, how is it biased in favor
> of redisplay, and what would be a more efficient way of drawing
> glyphs in a specified area of the display than what draw_glyphs
> does?

As I mentioned, row overlapping is handled in rather an inefficient
way (by calling draw_glyphs for three times if the row is overlapping
and overlapped).  With double-buffering, we can draw whole the
background of the specified area (possibly containing multiple rows)
at once and then draw the whole foreground afterwards.

                                     YAMAMOTO Mitsuharu
                                address@hidden



reply via email to

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