From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: PNG pictures have gamma correction twice applied Date: Mon, 11 Nov 2002 12:43:50 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: <200211111743.gABHhoA16796@rum.cs.yale.edu> References: <200211061556.gA6FuCU6005082@localhost.localdomain> <200211111658.gABGwDC16585@rum.cs.yale.edu> <200211111730.gABHUx7L010488@localhost.localdomain> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037201369 22578 80.91.224.249 (13 Nov 2002 15:29:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 13 Nov 2002 15:29:29 +0000 (UTC) Cc: "Stefan Monnier" , rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18BzCf-000482-00 for ; Wed, 13 Nov 2002 16:13:17 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18BzOc-00066k-00 for ; Wed, 13 Nov 2002 16:25:38 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BJ4Z-0001TR-00; Mon, 11 Nov 2002 13:14:07 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18BIbW-0001Ae-00 for emacs-devel@gnu.org; Mon, 11 Nov 2002 12:44:06 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18BIbS-0001AF-00 for emacs-devel@gnu.org; Mon, 11 Nov 2002 12:44:05 -0500 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BIbL-00019B-00; Mon, 11 Nov 2002 12:43:56 -0500 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id gABHhoA16796; Mon, 11 Nov 2002 12:43:50 -0500 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: David.Kastrup@t-online.de (David Kastrup) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9368 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9368 > "Stefan Monnier" writes: > > > > Now x_alloc_nearest_color is defined in src/xterm.c. It first calls > > > gamma_correct on the function in question (which does the gamma > > > correction with a very expensive floating point operation), then > > > calls x_alloc_nearest_color_1, which does a costly operation of > > > figuring out a closest color. > > > > Have you checked whether this "costly operation" is actually done > > in your case ? It should only happen if the XAllocColor fails, which > > should never be the case in a 16bpp (or more) display. > > Correction: which should not be the case when there is no palette > involved of any kind. If there is, XAllocColor will allocate the > next free color slot. Since the Emacs display code never deallocates > a color again, the color palette will run out of colors eventually. > Whatever colors happen to be in the palette at that time, get used > for the "closest" color. If you have, for example, a color diagram > as an image, the red top will allocate all the colors away, and blue, > green and white will be all represented by shades of red. IIUC, the problem is not with the closest-match thing per se, but with the fact that Emacs doesn't deallocate colors. And that for images, it's probably better to pre-allocate a set of colors and stick to them, since most images will otherwise overflow the 256-color palette. Agreed. The code you're looking at was really meant for text originally. > For that reason it would be more prudent to allocate a fixed palette, > even if it has just 4x4x4 colors, and use that. For images, yes. For text, I don't see the need: I hate it when an application allocates 64colors of my small colormap only to use 10 of them; and doesn't even get them right because it approximates within the 64 it pre-defined rather than using the exact color. > Just making use of whatever happens to be present in the current palette > is an emergency measure. For some users, it's the "normal case" (many apps gobble up most/all the colormap). > And asking for the current palette again for every new > pixel is not going to be reducing the X traffic... That's the part of the caching which could be improved. Stefan "who cares about 256-color displays and Emacs displaying text much more than about Emacs displaying images"