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: Mon, 06 May 2019 09:11:18 -0600 Message-ID: <87d0kvk489.fsf@gmail.com> References: <87v9yqjdnh.fsf@gmail.com> <83a7g2kqsi.fsf@gnu.org> <87lfzlkeic.fsf@gmail.com> <83zho0khdu.fsf@gnu.org> <87h8a8k84a.fsf@gmail.com> <83pnowjo63.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="200547"; 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 Mon May 06 17:13:25 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 1hNfIx-000q08-4z for ged-emacs-devel@m.gmane.org; Mon, 06 May 2019 17:13:23 +0200 Original-Received: from localhost ([127.0.0.1]:58025 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNfIw-0004IV-4V for ged-emacs-devel@m.gmane.org; Mon, 06 May 2019 11:13:22 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:60718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNfGx-0003QH-8B for emacs-devel@gnu.org; Mon, 06 May 2019 11:11:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hNfGv-0005QM-JH for emacs-devel@gnu.org; Mon, 06 May 2019 11:11:19 -0400 Original-Received: from mail-pg1-x52b.google.com ([2607:f8b0:4864:20::52b]:35811) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hNfGv-0005PK-DY; Mon, 06 May 2019 11:11:17 -0400 Original-Received: by mail-pg1-x52b.google.com with SMTP id h1so6613046pgs.2; Mon, 06 May 2019 08:11:17 -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=9G8rOL0QsWD8fvZQ/Yc9kwumNaFaqZ0BOTKTQ/GsD0o=; b=NGNPInr9WC+Tu8k0Bc+sMyhtHUxwrEGfeIp5AmtyQy8Zzog/6y5RNmTJSX2PDLGAo6 0sHBhgFqd/JvTXx+cIVt7mJtltY+gM1RcyExoFpw7JNmcoGJLIZG9Bjmr8ISJSsVmgjl v1OxVicbfVO+jDsMOPSz7mU8UWCY8WM6dJm+omzGkxVEfQbj/fQss7c9YjJG/DYqwb2l iZatcwCPWSjTfmRuMK8GCdiB8BUmFAbtx1soXp3dObK3ZmK9skOFO0G91C2GUM1ldmI4 HWPjucx/tkN8vPkaxO4NH0bpO6CiTfof85WJ0I76VwOi8lzEje1u+CTSuEzE+xXU/j4Z 6JNA== 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=9G8rOL0QsWD8fvZQ/Yc9kwumNaFaqZ0BOTKTQ/GsD0o=; b=lYjTp7fmAOOU6ey0GWlI4UKtYbDAPQL59nFabluZ2J5IueyziqHh4/CqeKmqg5A4qC laasfTzweB4qy/rMwDFpG3XvrDBsz6l45ScKK/svc3lcMW7SzXvsPzfOBj6Un/W6tVrG fRBrlUnFv4uPN/h6pyPrTF2auKTNrD+Q0SCVlrSgeE+NMFXVSVqZNn2EQYlueP+3VKVL h8j0jM2pkzhyX7tsBh+mLBo5ZanRbtWgnb4Sm8Kl8BEC37llNF4hUbPGsGZQo9x0PMJ6 TeTjExdCbFjIVx8DI/WVf0YkM/7iI0WDEgVs6E9vWDzy1H9WJwnADOtASaZTnTNTITx4 9+GA== X-Gm-Message-State: APjAAAViNKCAfSGUaEihtuYw5mFvuasxcBpBNAgJGgbsOAenna0qXfgP v0P6cWnsaWWKgfbpocIFT2F1Y8FN X-Google-Smtp-Source: APXvYqxmKBDhVOWWp3xOuV7ZSUNFcOoIENByqB38ODF/saseBApL8wHFywpeLNSGvnH9u45fAp58gA== X-Received: by 2002:a65:4302:: with SMTP id j2mr32353861pgq.291.1557155475146; Mon, 06 May 2019 08:11:15 -0700 (PDT) Original-Received: from lylat ([2604:3d09:e37f:1500:1a72:4878:e793:7302]) by smtp.gmail.com with ESMTPSA id a4sm14334770pfj.36.2019.05.06.08.11.13 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 06 May 2019 08:11:14 -0700 (PDT) In-Reply-To: <83pnowjo63.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 May 2019 05:45:56 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::52b 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:236196 Archived-At: Eli Zaretskii writes: >> 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. > > No, I meant the RGBA representation. The integer color values are our > current abstraction. Do you mean the conditional GdkRGBA in emacs_color? I don't think that's really any different than the platform-specific output_data types. What would the alternatives be in the case that a single representation couldn't handle all supported platforms? >> > (larger structures slow down Emacs) >> >> More so than other programs? > > Why should other programs matter here? I don't want to have slow-down > in the inner-most loops of Emacs, because that causes legitimate user > complaints. Faces are used in redisplay. I meant if there was any specific reason to Emacs that slightly larger structures would cause a non-negligible slowdown. In any case, I would have thought that the conversions would cause more of a slow-down, but we can perhaps find that out later. >> > 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? > > No, we want all platforms to support the same color representation, > for various good reasons. For example, platform-independent > representation of standard colors. Ideally, but if there is no way to represent a certain precision on a particular platform, and if the size of structures is of concern to you, then would it not make sense to only support the maximum precision possible? I meant something along the lines of: #ifdef typedef unsigned long long emacs_pixel; #else typedef unsigned long emacs_pixel; #endif >> 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. > > Once again, I'm okay with discussing a change for all the platforms, > but it needs to show benefits for all of them, or at least a > majority. I'm not sure about the situation on other platforms, but IMO it would be worthwhile to discuss a change even if it benefits only a single supported platform as long as it doesn't introduce non-trivial complexity to the other platforms (such as the above #ifdef). > What you describe could mean a use of a single 'double' for > a color; we definitely don't need 4 'double's yet. I'm not sure that a single double would suffice here. P.S. You mention "platform-independent representation of standard colors", but isn't the unsigned long used differently on different platforms already? NS and X seem to use it as indices to color tables (AFAIU X uses the pixel value to lookup a 48-bpp RGB triplet and store it in an XColor), and w32 uses it to embed a COLORREF.