From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs, colors and gdk-pixbuf. Date: 13 Apr 2003 22:31:38 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <921D608D-6DE4-11D7-BB92-00039363E640@swipnet.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1050266711 19220 80.91.224.249 (13 Apr 2003 20:45:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 13 Apr 2003 20:45:11 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sun Apr 13 22:45:04 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 194oLY-0004zW-00 for ; Sun, 13 Apr 2003 22:45:04 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 194oMb-00031r-00 for ; Sun, 13 Apr 2003 22:46:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 194oDq-0004o3-0A for emacs-devel@quimby.gnus.org; Sun, 13 Apr 2003 16:37:06 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 194o9K-0002dF-00 for emacs-devel@gnu.org; Sun, 13 Apr 2003 16:32:26 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 194o9E-0002UH-00 for emacs-devel@gnu.org; Sun, 13 Apr 2003 16:32:22 -0400 Original-Received: from mail1.kens.com ([209.70.202.39]) by monty-python.gnu.org with smtp (Exim 4.10.13) id 194o8m-0001ww-00 for emacs-devel@gnu.org; Sun, 13 Apr 2003 16:31:52 -0400 Original-Received: (qmail 9297 invoked by uid 1002); 13 Apr 2003 20:31:45 -0000 Original-Received: from unknown (HELO localhost.localdomain) (dak@my.gnus.org@62.226.12.170) by 0 with SMTP; 13 Apr 2003 20:31:45 -0000 Original-Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.7/8.12.7) with ESMTP id h3DKVd65028426; Sun, 13 Apr 2003 22:31:41 +0200 Original-Received: (from dak@localhost) by localhost.localdomain (8.12.7/8.12.7/Submit) id h3DKVdV9028422; Sun, 13 Apr 2003 22:31:39 +0200 Original-To: "Jan D." In-Reply-To: <921D608D-6DE4-11D7-BB92-00039363E640@swipnet.se> Original-Lines: 92 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13213 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13213 "Jan D." writes: > Some time ago there was some discussion about improving image and > color handling in Emacs. Meaning that I said "oh this sucks so bad, can't be do something about it?". And of course the easiest way out is to use existing code that sucks less. There is a disadvantage of course: it is not nice if the only Emacs that offers reasonable performance and semantics for images and colors is the GTK version. There are two answers to that: a) other toolkits usually should also have their own favorite ways of dealing with the same problem, so one could try shifting work load more into the toolkits if that is found to be the case. b) the generic Emacs code for handling the stuff gets an overhaul. > One suggestion as to use gdk-pixbuf to handle images. I have made > some tests, the actual code to get gdk-pixbuf in is not that big. The problem is not to get gdk-pixbuf or other stuff "in". The problem is making sure that everything it does well no longer needs to be tampered with by Emacs in any way. Now Emacs does have one particular frame-specific setting, the gamma correction, that would probably need some thought to integrate well. And color allocation of Emacs is abysmal. > I haven't actually checked if this does make color handling > better. There needs to be one consistent strategy for color allocation also for text/borders/etc. Gdk should be able to be used for that. > First, gdk-pixbuf is inherently single displayed. This means that > Emacs would be limited to one display. Since GTK also is > single-displayed (perhaps not 2.2, there has been talk about some > changes, I haven't checked this yet), we could make gdk-pixbuf the > default for GTK. >>From the release announcements: GTK+-2.1.5 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.1/ This is the final prerelease before GTK+-2.2. The major change as compared to the stable GTK+-2.0.6 is support for multiple displays and multiple screens in GDK, although there are numerous minor changes as well. Since Emacs is potentially multiheaded (see, for example, the talk-connect function), it would probably be better if the GTK port followed suit where possible and supported. I _do_ have the nagging suspicion that multihead in Emacs might be broken anyway, that it might possibly behave erratically when confronted with a mixture of displays with different display characteristics and color depths, perhaps even a tty among them. XEmacs deals with part of this problem through specifiers (which I don't really understand) which it instantiates into a displayed object when confronted with a particular locale (such as a display with its own characteristics). > The part of gdk-pixbuf is the part that renders into X11. Emacs > could use its own version of this code, suitable modified. Is that > something people think is OK (using private versions of other > libraries)? Must license issues be investigated or is it OK to > modify stuff from GTK? There are people more suitable than myself to answer this on this list. If you don't get an answer soon, I can give you a guess at what it might be. > Another thing is that gdk-pixbuf may have been compiled with image > support that is different from the one Emacs has today > (i.e. gdk-pixbuf may not have, for example, TIFF support compiled > in). Should we try to make a configure test to see what image types > gdk-pixbuf supports, and then fall back to "native" support for the > others? Or just fail at runtime if an image type is used that > gdk-pixbuf supports? Better to fail when an image type is used that is _not_ supported... I'd not try making an odd mixture in one executable. Of course, this might mean that EPS images are scheduled for extinction. I might have been the only one that was as foolish to try using them in a serious application (preview-latex) anyhow, and they were and still are completely unusable which is why preview-latex has been reworked to do its own handling of GhostScript for image conversion. I don't think that many people would particularly notice their loss. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum