From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: Future of display engine [Re: Printing] Date: Wed, 08 Apr 2009 10:53:10 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <5f0660120903280331y780c80b7i57a8115dc4b029eb@mail.gmail.com> <49CE3A84.9070705@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1239155612 30644 80.91.229.12 (8 Apr 2009 01:53:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Apr 2009 01:53:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Kenichi Handa Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 08 03:54:51 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LrN03-0001FP-UT for ged-emacs-devel@m.gmane.org; Wed, 08 Apr 2009 03:54:48 +0200 Original-Received: from localhost ([127.0.0.1]:39516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrMyf-0003Tp-Ob for ged-emacs-devel@m.gmane.org; Tue, 07 Apr 2009 21:53:21 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrMyb-0003TW-Rs for emacs-devel@gnu.org; Tue, 07 Apr 2009 21:53:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrMyX-0003T3-A6 for emacs-devel@gnu.org; Tue, 07 Apr 2009 21:53:17 -0400 Original-Received: from [199.232.76.173] (port=36012 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrMyX-0003T0-7K for emacs-devel@gnu.org; Tue, 07 Apr 2009 21:53:13 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:53308) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LrMyW-00088y-Gb for emacs-devel@gnu.org; Tue, 07 Apr 2009 21:53:13 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 4FA3E2C40; Wed, 8 Apr 2009 10:53:10 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by monty-python.gnu.org: NetBSD 3.0 (DF) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:110135 Archived-At: >>>>> On Wed, 08 Apr 2009 10:19:33 +0900, Kenichi Handa 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 mituharu@math.s.chiba-u.ac.jp