From: Alex Gramiak <agrambot@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Removing assumption of unsigned long pixel values for colours
Date: Mon, 06 May 2019 09:11:18 -0600 [thread overview]
Message-ID: <87d0kvk489.fsf@gmail.com> (raw)
In-Reply-To: <83pnowjo63.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 May 2019 05:45:56 +0300")
Eli Zaretskii <eliz@gnu.org> 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 <Using a platform needing 64-bits>
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.
next prev parent reply other threads:[~2019-05-06 15:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-04 18:08 Removing assumption of unsigned long pixel values for colours Alex Gramiak
2019-05-04 18:39 ` Eli Zaretskii
2019-05-04 23:04 ` Alex Gramiak
2019-05-05 16:14 ` Eli Zaretskii
2019-05-05 19:35 ` Alex Gramiak
2019-05-06 2:45 ` Eli Zaretskii
2019-05-06 14:13 ` Daniel Pittman
2019-05-06 16:11 ` Alex Gramiak
2019-05-06 16:51 ` Stefan Monnier
2019-05-06 20:03 ` Alex Gramiak
2019-05-06 15:11 ` Alex Gramiak [this message]
2019-05-06 15:45 ` Eli Zaretskii
2019-05-06 16:29 ` Alex Gramiak
2019-05-06 16:54 ` Eli Zaretskii
2019-05-06 17:14 ` Alex Gramiak
2019-05-06 17:39 ` Eli Zaretskii
2019-05-06 18:00 ` Eli Zaretskii
2019-05-06 19:49 ` Alex Gramiak
2019-05-07 2:29 ` Eli Zaretskii
2019-05-06 8:12 ` Alan Third
2019-05-06 9:18 ` mituharu
2019-05-06 15:06 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d0kvk489.fsf@gmail.com \
--to=agrambot@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.