[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Removing assumption of unsigned long pixel values for colours
From: |
Eli Zaretskii |
Subject: |
Re: Removing assumption of unsigned long pixel values for colours |
Date: |
Mon, 06 May 2019 05:45:56 +0300 |
> From: Alex Gramiak <address@hidden>
> Cc: address@hidden
> Date: Sun, 05 May 2019 13:35:01 -0600
>
> 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.
Yes, please.
> > . 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.
No, I meant the RGBA representation. The integer color values are our
current abstraction.
> > . 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.
That "as long as" part is already a potential problem. And I see
other opportunities for exciting bugs.
> > (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.
> > 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.
> 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. What you describe could mean a use of a single 'double' for
a color; we definitely don't need 4 'double's yet.
- Removing assumption of unsigned long pixel values for colours, Alex Gramiak, 2019/05/04
- Re: Removing assumption of unsigned long pixel values for colours, Eli Zaretskii, 2019/05/04
- Re: Removing assumption of unsigned long pixel values for colours, Alex Gramiak, 2019/05/04
- Re: Removing assumption of unsigned long pixel values for colours, Eli Zaretskii, 2019/05/05
- Re: Removing assumption of unsigned long pixel values for colours, Alex Gramiak, 2019/05/05
- Re: Removing assumption of unsigned long pixel values for colours,
Eli Zaretskii <=
- Re: Removing assumption of unsigned long pixel values for colours, Daniel Pittman, 2019/05/06
- Re: Removing assumption of unsigned long pixel values for colours, Alex Gramiak, 2019/05/06
- Re: Removing assumption of unsigned long pixel values for colours, Stefan Monnier, 2019/05/06
- Re: Removing assumption of unsigned long pixel values for colours, Alex Gramiak, 2019/05/06
- Re: Removing assumption of unsigned long pixel values for colours, Alex Gramiak, 2019/05/06
- Re: Removing assumption of unsigned long pixel values for colours, Eli Zaretskii, 2019/05/06
- Re: Removing assumption of unsigned long pixel values for colours, Alex Gramiak, 2019/05/06
- Re: Removing assumption of unsigned long pixel values for colours, Eli Zaretskii, 2019/05/06
- Re: Removing assumption of unsigned long pixel values for colours, Alex Gramiak, 2019/05/06
- Re: Removing assumption of unsigned long pixel values for colours, Eli Zaretskii, 2019/05/06