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: Mon, 06 May 2019 18:45:20 +0300 Message-ID: <83ftprk2nj.fsf@gnu.org> 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> <87d0kvk489.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="77206"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 06 17:45:54 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 1hNfoQ-000Jyg-4O for ged-emacs-devel@m.gmane.org; Mon, 06 May 2019 17:45:54 +0200 Original-Received: from localhost ([127.0.0.1]:58437 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNfoP-0003Bg-4Y for ged-emacs-devel@m.gmane.org; Mon, 06 May 2019 11:45:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:39986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNfoA-0003BP-Lj for emacs-devel@gnu.org; Mon, 06 May 2019 11:45:39 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hNfoA-00008e-I1; Mon, 06 May 2019 11:45:38 -0400 Original-Received: from [176.228.60.248] (port=3560 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hNfo8-0006Y2-Tm; Mon, 06 May 2019 11:45:38 -0400 In-reply-to: <87d0kvk489.fsf@gmail.com> (message from Alex Gramiak on Mon, 06 May 2019 09:11:18 -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:236197 Archived-At: > From: Alex Gramiak > Cc: emacs-devel@gnu.org > Date: Mon, 06 May 2019 09:11:18 -0600 > > 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? Yes. > 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? I don't know, we will need to discuss this when we have an actual problem. For now this is a hypothetical problem. > I meant if there was any specific reason to Emacs that slightly larger > structures would cause a non-negligible slowdown. It could happen if enlarging a structure makes it large enough to not fit into a cache line. So we should do this only if really necessary, and then very cautiously. The display engine already juggles some very large structures. > 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. I think you are mistaken, doing simple arithmetics, even FP arithmetics, is lightning fast on modern machines, specially since they have several execution units that work in parallel. > > 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 This will bite us at some point because we currently more or less expose the X color values to users. > 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. COLORREF is just the RGB representation of a color, see https://docs.microsoft.com/en-us/windows/desktop/gdi/colorref Our color abstraction is also RGB representation, which AFAIR comes from X. Maybe X uses something different nowadays, but since the RGB color descriptions are exposed to Lisp, changing that would be tricky. So conversion where needed is TRT, I think. And IME it rarely is expensive enough to matter, so I don't think the need to convert per se justifies significant changes in interfaces and infrastructure.