[Top][All Lists]
[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
- Re: Emacs and Gnome Canvas, (continued)
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/17
- Re: Emacs and Gnome Canvas, YAMAMOTO Mitsuharu, 2010/07/17
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/17
- Re: Emacs and Gnome Canvas, YAMAMOTO Mitsuharu, 2010/07/17
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/17
- Re: Emacs and Gnome Canvas, YAMAMOTO Mitsuharu, 2010/07/17
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/18
- Re: Emacs and Gnome Canvas, YAMAMOTO Mitsuharu, 2010/07/18
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/18
- Re: Emacs and Gnome Canvas, YAMAMOTO Mitsuharu, 2010/07/18
- Re: Emacs and Gnome Canvas,
YAMAMOTO Mitsuharu <=
- Re: Emacs and Gnome Canvas, YAMAMOTO Mitsuharu, 2010/07/16
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/17
- Re: Emacs and Gnome Canvas, YAMAMOTO Mitsuharu, 2010/07/17
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/16
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/15
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/15
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/15
- Re: Emacs and Gnome Canvas, Eli Zaretskii, 2010/07/15
- Re: Emacs and Gnome Canvas, Jan Djärv, 2010/07/15
- Re: Emacs and Gnome Canvas (was: Emacs, QT and Cairo), Dirk-Jan C . Binnema, 2010/07/15