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: Sat, 04 May 2019 17:04:43 -0600 Message-ID: <87lfzlkeic.fsf@gmail.com> References: <87v9yqjdnh.fsf@gmail.com> <83a7g2kqsi.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="222840"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: Alan Third , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 05 01:05:37 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 1hN3ir-000vrP-3P for ged-emacs-devel@m.gmane.org; Sun, 05 May 2019 01:05:37 +0200 Original-Received: from localhost ([127.0.0.1]:33841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hN3ip-0002JR-TU for ged-emacs-devel@m.gmane.org; Sat, 04 May 2019 19:05:35 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hN3i2-0002JM-U6 for emacs-devel@gnu.org; Sat, 04 May 2019 19:04:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hN3i1-00083Z-Mz for emacs-devel@gnu.org; Sat, 04 May 2019 19:04:46 -0400 Original-Received: from mail-pf1-x42c.google.com ([2607:f8b0:4864:20::42c]:44168) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hN3i1-000832-4a; Sat, 04 May 2019 19:04:45 -0400 Original-Received: by mail-pf1-x42c.google.com with SMTP id y13so4736772pfm.11; Sat, 04 May 2019 16:04:45 -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=3AIQZfGO4Pl9SYftni3BwBjOodQjyOh+Jje2IpUOnaE=; b=oEU2KRtlHN0RzSxZyI2tjJf9XRQYq+CSHYH/ShmdzNFrNtCyMpZtfuZLYg851S0Em/ qgqFc/BMmFamWVErMw8upaUiHp42GVTeggbBd5zl+LiYol+Hln+30wQpJ/E8meKpmwOY +a9+t+/a1qlOA0Rn2MlO2BH4hmkqSbRI33t27CfHoBP5vnecVN5j4kyKuoRIxgv2zi/T I/nIc/UWFfFkidB8TbXAq52qQoTx96HkJYC6VwputIB71ZqIdylU7Axf70DqPv4JzuDE lFr+w2/dxYtU25s+fwaL8v3TMmaBOwDt9egxb7XWWS+4G51nfDT8mzBw1m/oNv/NflKQ 7q8Q== 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=3AIQZfGO4Pl9SYftni3BwBjOodQjyOh+Jje2IpUOnaE=; b=kqVBOJsxNnO8WoS8WPtnDvU+gG6rOwgWricwczBQs4/JU5rovJCmPZHRGmhsT7Kt/I z+8o852W1rzxWpIrDuPgv3uCnzwDHavDDJ1gfkAn94fWxwAcQLK2+yL0oCAlEfDneCTH zTqFOMWW/Pe7eK15WVgt+iVhZoF8cCtMRUkvwfsUJI7GjyPBzT1kdyLmaC6Rv6wlBiRL Y/ch5IFdihKETqH8ShuqlEaKgAvAv619MUCYzR/y0gXWF7MtDeEIRKbnazStCkEi/hVK MsME+dOwXNIKI1WUCTMNBRaNgE5iNGeQa96sjhbOseVUAn+d1g5PpCp5jMugQZtbpwfV 42Ug== X-Gm-Message-State: APjAAAWj0X1ZYjMU6vZALyKOcLuPRdiaD0SJre5FU+zsBuSh/pO/9XJn QZa2IqofcSgHr2QUAKGsAxGlG8F9 X-Google-Smtp-Source: APXvYqzoKTrCTi3H18wYoqS3WeInxR9YZ3vWJd5y4dckw+JXo2/liO4D/RGgLOD1vaApPHe1r3RpUw== X-Received: by 2002:a65:4144:: with SMTP id x4mr21880398pgp.282.1557011083965; Sat, 04 May 2019 16:04:43 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id i3sm8721644pfa.90.2019.05.04.16.04.42 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 04 May 2019 16:04:43 -0700 (PDT) In-Reply-To: <83a7g2kqsi.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 May 2019 21:39:25 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::42c 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:236170 Archived-At: Eli Zaretskii writes: >> From: Alex Gramiak >> Date: Sat, 04 May 2019 12:08:34 -0600 >> >> I've attached a WIP patch (for illustrative purposes) creating a new >> union, emacs_color, that removes the single type limitation for the >> internal representation of colours. This approach is intended to be used >> with a new backend that I'm working on which uses a quadruple of >> normalized double values for each colour rather than a single pixel >> value. Using a union would avoid having to frequently convert between >> the two representations. > > 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. Using a union for stored colours would allow for direct access/storage of the colours rather than conversions for every query and drawing operation. Also, AFAIU a GdkRGBA wouldn't necessarily convert into an unsigned long without losing precision. It might also help simplify the NS side to use NSColor objects directly rather than using the unsigned long values as indices to an ns_color_table (CC'd Alan to confirm/deny). >> Question: In realize_gui_face, why is a defaulted underline colour set >> to 0 when defaulted overline/strike-through colours are set to the >> foreground colour? The comment above the underline case mentions that >> it's the same as the foreground colour, so should it be explicitly set >> there as well? > > realize_gui_face just sets a flag, the implementation should be in the > *term.c back-ends. When that flag is set, the color of the underline > should be disregarded and taken from the current foreground color. On > MS-Windows, the underline changes its color according to the > foreground color of the text it underlines. Don't you see the same on X? Yes, I didn't mean that the underline colour wasn't inherited; I was just referring to the value that underline_color is set to when defaulted: face->underline_defaulted_p = true; face->underline_color = 0; where the other defaulted cases set the colour explicitly (perhaps just being overly cautious?): face->overline_color = face->foreground; face->overline_color_defaulted_p = true; face->strike_through_color = face->foreground; face->strike_through_color_defaulted_p = true; AFAICS the value set doesn't matter (*_draw_glyph_string just checks the flags), but I wanted to check that there wasn't a reason that underline_color was different that I was missing.