[Top][All Lists]

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

Re: Future of display engine [Re: Printing]

From: YAMAMOTO Mitsuharu
Subject: Re: Future of display engine [Re: Printing]
Date: Wed, 08 Apr 2009 10:53:10 +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 Wed, 08 Apr 2009 10:19:33 +0900, Kenichi Handa <address@hidden> said:

>> Not a problem, but just a matter of uniformity.  Even in the
>> current xterm.c, colors and clipping information is managed by GC
>> for drawings except texts.  The use of GC extension data enables us
>> to get rid of this special treatment for text drawings.

> Ah, I see your point.  I was thinking the other way round.  I
> vaguely think we can have more uniform display engine if we can have
> various information for displaying in a device independent way.
> Though, I have not investigate it in detail.

Yes. I was thinking about uniformity in the other direction.  Packing
graphics state information such as colors and clipping rectangles into
GC is what Xlib (which is the current standard in Emacs) is doing, and
can be ported to the other graphics frameworks as I showed in the
cairo patch and the Carbon(+AppKit) port (both QuickDraw and Quartz
2D).  Of course, it would be meaningful to change that design so it
fits with some "next generation standard" graphics framework in Emacs.

                                     YAMAMOTO Mitsuharu

reply via email to

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