From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alex Gramiak Newsgroups: gmane.emacs.devel Subject: Re: Removing assumption of unsigned long pixel values for colours Date: Sun, 05 May 2019 13:35:01 -0600 Message-ID: <87h8a8k84a.fsf@gmail.com> References: <87v9yqjdnh.fsf@gmail.com> <83a7g2kqsi.fsf@gnu.org> <87lfzlkeic.fsf@gmail.com> <83zho0khdu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="225667"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 05 21:35:55 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 1hNMvS-000wZM-EH for ged-emacs-devel@m.gmane.org; Sun, 05 May 2019 21:35:55 +0200 Original-Received: from localhost ([127.0.0.1]:45013 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNMvR-0002Nn-8v for ged-emacs-devel@m.gmane.org; Sun, 05 May 2019 15:35:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNMug-0002IT-OT for emacs-devel@gnu.org; Sun, 05 May 2019 15:35:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNMuf-0004Om-KW for emacs-devel@gnu.org; Sun, 05 May 2019 15:35:06 -0400 Original-Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]:47067) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNMuf-00044y-B5; Sun, 05 May 2019 15:35:05 -0400 Original-Received: by mail-pl1-x62e.google.com with SMTP id bi2so5224450plb.13; Sun, 05 May 2019 12:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=NY5Bg+Jam+j32oJaIZUEFkiCTtqg5vDwlMdw98hopPI=; b=h33mktSmOcWDfHefDg7YC4p6PpPu0MKUHdsUuGMH6DLgp8kMR7wZpmKV8zu4lRZH4m g/5A7/+b5LmMD2oHkNMU0v5V0TyVmLw+nNvYdQIaCH70tkS2bYCK90DKt03M3rscnKj3 jvorHFXvyWeW3xOeOfk1liUGW2XJ6vRf/SqUSeJU6pjjQjA8oT8ykbm/2F+GopPRmaO0 hN823fWwo/3QcdITTkLisrftzc1TWd6xAjUw76pbP3dChgkK8ZFhnWLh6en7OPkB69oH NwNnZdnziHb2Jz3W5tSe2cXrOXdVj444K2AMfqhoSnDpLHSHJtOapIQSTaJL46tCjoyp bAIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=NY5Bg+Jam+j32oJaIZUEFkiCTtqg5vDwlMdw98hopPI=; b=XaI9cyYEExtDel0DicVfg6mUKosAGzW8wgmDcmJWa0KpfheBlhIy0eO+jwsfYj6qIP 1/0ASf+WTU+KRMds7AWFqw0zPCv+fGCqKE6jZJtRlUPBjDOep+eITY/qbgX1+6hve7/x qmoCkYozi8HiAHjMpZJklXYH9NAtlMKBZtqxY1kN/LJFJjvJ0J+49NjzIIgaXJqrErOx hOe3Zv1K+RpjrAjgiq0i2eIXkfDZnL/rJcx1M6TJnpI9EPp8RX6ddUYxaiXlKyqLlccc JP5DFScEQXpriu8y31ZqyLlrXRGh8LSJ0r+3B3kNOl2UXQisGmEdLbdaeDuS8wGCE1CQ Y4AA== X-Gm-Message-State: APjAAAUlwJm5+TqAlcCSw5r6fDfE1aJz0DSwicKFgh8hjnFup6jh6aZI CXM8ugaaYXTLz3e/MATkZ1tC6eQ4 X-Google-Smtp-Source: APXvYqyvwH7X+Dg/Nvl9rXLy1KPEYc1nmukitSuLhx46IEyo6sADdSEXWF1Y6ugJKKdXn5Bx2R0R/w== X-Received: by 2002:a17:902:a510:: with SMTP id s16mr2413788plq.334.1557084901442; Sun, 05 May 2019 12:35:01 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id f20sm14422669pff.176.2019.05.05.12.34.59 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 05 May 2019 12:35:00 -0700 (PDT) In-Reply-To: <83zho0khdu.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 05 May 2019 19:14:53 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::62e 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:236184 Archived-At: Eli Zaretskii writes: >> 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. It's certainly possible that I'm overestimating the cost of the conversions. It just doesn't seem good to have to do this conversion for every draw operation. Perhaps I should follow the old adage and just use unsigned long with conversions first and benchmark after. > Are there other issues that caused you to propose this change? Not directly, but to avoid the conversions I did add additional complexity by using a local tagged union that I feel is too much trouble. I figured that I'd float this option by before changing strategies. > 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 I'm not sure what leaks you're referring to here. The cases that use .pixel directly should only be in the TTY-specific or X-specific code. > . the union you propose has no indication which of its > interpretations is being used, which will lead to bugs I considered that, but as it looks like faces are tied to frames (which are tied to terminals), then the type shouldn't need to be checked as long as the terminal-independent code doesn't alter it. > (larger structures slow down Emacs) More so than other programs? >> 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. Wouldn't it only need to be done for platforms that support a higher pixel depth? gdk_rgba_parse uses pango_color_parse, which returns a PangoColor (48 bpp RGB), and normalizes each component over 2^16. If using either CAIRO_FORMAT_RGB30 (30 bpp RGB) with image surfaces or using the OpenGL backend (which I believe the GTK Wayland backend uses), then storing ARGB values into an unsigned long would mean lost precision that could have been used.