Framework wide color

[gaaclarke]

issue: flutter/flutter#127855
integration test: #54415

This does the preliminary work for implementing wide gamut colors in the Flutter framework. Here are the following changes:

1. colors now specify a colorspace with which they are to be interpreted
2. colors now store their components as floats to accommodate bit depths more than 8

The storage of this Color class is weird with float/int storage but that is a temporary solution to support a smooth transition. Here is the plan for landing this:

1. Land this PR
2. Wait for it to roll into the Framework
3. Land Switched CupertinoDynamicColor to implements Color flutter#153938 which will make CupertinoDynamicColor implement Color
4. Land another engine PR that rips out the int storage: Removes the int storage from Color #54714

Here are follow up PRs:

1. Changes DlColor to support wide gamut colors #54473 - changes DlColor so the wide gamut colors are rendered
2. Hooks up framework wide gamut to engine wide gamut #54567 - Hooks up these changes to take advantage of wide DlColor
3. Adds wide gamut framework test flutter#153319 - the integration test for the framework repo

There are some things that have been left as follow up PRs since they are technically breaking:

1. The math on lerp hasn't been updated to take advantage of the higher bit depth
2. operator== hasn't been updated to take advantage of the higher bit depth
3. hashCode hasn't been updated to take advantage of the higher bit depth
4. alphaBlend hasn't been updated to take advantage of the higher bit depth
5. toString hasn't been updated to take advantage of the higher bit depth

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide and the C++, Objective-C, Java style guides.
• I listed at least one issue that this PR fixes in the description above.
• I added new tests to check the change I am making or feature I am adding, or the PR is test-exempt. See testing the engine for instructions on writing and running engine tests.
• I updated/added relevant documentation (doc comments with ///).
• I signed the CLA.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

[gaaclarke]

Addressed in #54473

[gaaclarke]

There is a slight change in the results of alpha blending which is tripping up pixel exact golden tests. For example in EmbedderTest.CanRenderSceneWithoutCustomCompositorMetal the blend of the red and green triangle was (r:85, g:170, b:0), but is now showing up as (r:86, g:169: b:0).

[gaaclarke]

@johnmccutchan I chose you to review since you have been involved in discussions about this feature and have a wholistic view of engine/framework. @jonahwilliams I chose you to represent the interests of the engine team. Let me know if you'd like to hear from someone else.

[jonahwilliams]

What happens if I used a p3 color value after this change lands? Does it get clamped or re-interpreted as sRGB?

[jonahwilliams]

You should change the hash code computation in this PR and not as a follow up.

[gaaclarke]

Responded to this in #54415 (comment)

[jonahwilliams]

You should change the == implementation in this PR and not in a follow up. You'll want some sort of fudge factor for the comparisons.

[jonahwilliams]

Thinking about this some more, we want ensure the hashCode is equal if the color is equal, so normaliziing to some bit depth (not 256) is probably required here.

[gaaclarke]

Okay, so I had this all implemented and decided to pull it out and wait for new PR. The reason why is that I want to separate the PRs for landing support for rendering wide gamut colors and support for wider bit depth for Color components. The reason is that the wider bit depth in color is the thing that is most likely going to cause a regression in tests. Rendering wide gamut colors is 3 commits across 2 repos and will be a pain to revert. I really think these should be landed separately.

My plan is to basically do the same math but use a number like 2^12 to match the bit depth for HDMI 2.0. On iOS we currently can only render 2^10.

[gaaclarke]

We could switch the storage back to an int in the meantime if it makes landing this PR easier.

[gaaclarke]

In fact maybe it makes sense to switch the storage to always be fixed point. I could refactor the old code to work from a fixed point where the divisor is 255. Then we can crank it up to 6000. The transmission to the lower levels can remain floats. The benefit is that the change at dart:ui is much simpler. Having 6000 be the fixed-point divisor would allow us to accurately represent 1/2, 1/4, 1/8, 1/10, 1/16. It's close to the 2^12 bit rate.

[gaaclarke]

What happens if I used a p3 color value after this change lands? Does it get clamped or re-interpreted as sRGB?

It will get clamped. After #54473 they will be rendered correctly.

[jonahwilliams]

Clamping seems reasonable. What about gradient colors? The constructors don't take Int32Lists, so we can change the implementation to pass float data now without breaking them. Obvs, atlas and vertices are more complicated.

[gaaclarke]

Clamping seems reasonable. What about gradient colors? The constructors don't take Int32Lists, so we can change the implementation to pass float data now without breaking them. Obvs, atlas and vertices are more complicated.

Yea, those are going to be changed after this lands in different PRs. This is just what is required to make the integration test work.

[gaaclarke]

The failure in the framework tests can be reproduced with

flutter --local-engine=host_debug_unopt_arm64 \
  --local-engine-host=host_debug_unopt_arm64 \
  --local-engine-src-path=/Users/aaclarke/dev/engine/src/ test \
  --name="Cupertino.*focusable\sand" \
  test/material/switch_test.dart 

I've traced the failure and it has to do with Paint.color setter and getter which is reading and writing to ByteData when going through the trace canvas test matcher.

[gaaclarke]

Looks like we have a test too that makes sure the color components are based off of the .value result:

  test('subclass of Color can override value', () {
    const DynamicColorClass color = DynamicColorClass(0xF0E0D0C0);
    expect(color.value, 0xF0E0D0C0);
    // Call base class member, make sure it uses overridden value.
    expect(color.red, 0xE0);
  });

https://github.com/gaaclarke/engine/blob/4771d838406fb5dea21a385bf693c384918d9f29/lib/web_ui/test/ui/color_test.dart#L143-L148

[gaaclarke]

I was able to eliminate some of the framework test failures by making sure things like .red are based on .value. The remaining bugs still seem to be related to Cupertino so possibly another weird subclassing Color behavior. We should really make that class final.

[gaaclarke]

I found the existing error with Cupertino's dynamic color Color subclass. It was relying on withAlpha() which was rewritten to use the float values, but the subclass was using the .value override to make that work. As a result I've deprecated withOpacity() and kept it the same definition.