From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Removing assumption of unsigned long pixel values for colours Date: Sun, 05 May 2019 19:14:53 +0300 Message-ID: <83zho0khdu.fsf@gnu.org> References: <87v9yqjdnh.fsf@gmail.com> <83a7g2kqsi.fsf@gnu.org> <87lfzlkeic.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="221354"; mail-complaints-to="usenet@blaine.gmane.org" Cc: alan@idiocy.org, emacs-devel@gnu.org To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 05 18:16:14 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hNJoD-000vPy-DG for ged-emacs-devel@m.gmane.org; Sun, 05 May 2019 18:16:13 +0200 Original-Received: from localhost ([127.0.0.1]:43337 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNJoC-0000bV-CP for ged-emacs-devel@m.gmane.org; Sun, 05 May 2019 12:16:12 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNJnF-0000bK-UH for emacs-devel@gnu.org; Sun, 05 May 2019 12:15:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:50095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNJnF-0004LD-E2; Sun, 05 May 2019 12:15:13 -0400 Original-Received: from [176.228.60.248] (port=3128 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hNJnE-00071R-NJ; Sun, 05 May 2019 12:15:13 -0400 In-reply-to: <87lfzlkeic.fsf@gmail.com> (message from Alex Gramiak on Sat, 04 May 2019 17:04:43 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236179 Archived-At: > From: Alex Gramiak > Cc: emacs-devel@gnu.org, Alan Third > Date: Sat, 04 May 2019 17:04:43 -0600 > > > Can you describe the goal, in terms of the advantages of such a > > representation, and the limitations of the existing representation > > that it attempts to resolve? I think whether we want to make this > > change depends on what will we gain from the changes. > > The goal is to avoid frequent conversions between the colour type used > in Emacs and the colour type used in drawing backends. In my case, the > drawing backend is Cairo (GTK), which uses 4 double values in the range > [0, 1] for ARGB. One can see the conversion from XColor to Cairo's > format in x_set_cr_source_with_gc_foreground and > x_set_cr_source_with_gc_background. > > It's not as much of an issue with the X+Cairo backend since the colour > is calculated from XQueryColors which returns an XColor, but the backend > I'm working on uses gdk_rgba_parse to query colors, which returns a > GdkRGBA (which is compatible with Cairo's). This means that a conversion > from the quadruple into unsigned long has to be done for every colour > queried. Such conversion needs about 2 to 3 machine instructions on modern hardware, so why is it a problem? If you are annoyed by seeing it in the sources all the time, then a macro or an inline function should take care of that. Are there other issues that caused you to propose this change? I see a couple of disadvantages with your proposal: . it leaks to platform-independent parts of the code representation that is specific to one platform, something that goes against everything you've been doing lately in your other work . the union you propose has no indication which of its interpretations is being used, which will lead to bugs . the structures which use colors will now be significantly larger, because instead of a single 32-bit or 64-bit number the union will need to hold 4 64-bit double-precision numbers (larger structures slow down Emacs) Against these disadvantages, what are the advantages? just the fact that you can carry the native color representation of some platform? IMO, that's not enough to justify such changes. > Also, AFAIU a GdkRGBA wouldn't necessarily convert into an unsigned long > without losing precision. If we want to increase the number of bits per pixel we support in Emacs, we need to do that for all the platforms. Currently, they all are aligned on 32 bpp, AFAIK. If indeed there will be loss of information (and I'd like to see some evidence to that first), then we need to move all the platforms to higher precision, not just one.