Skip to content
This repository was archived by the owner on Feb 25, 2025. It is now read-only.

Conversation

@flar
Copy link
Contributor

@flar flar commented Feb 3, 2022

An initial stab at maintaining data for ColorFilter objects in the engine's own data structures so that we can use it directly for optimizations. This code may serve as a prototype for how we keep our own data around for other structures like ImageFilter and Shaders.

Note that even if we deal with a part of the system that can only communicate to us via SkCanvas operations, we can still dig out the Blend and Matrix types of Color Filters when they get used in a DisplayList. Only the Srgb <-> Linear ColorFilters can get lost in that type of flow.

@flar flar added the Work in progress (WIP) Not ready (yet) for review! label Feb 3, 2022
@flar flar requested a review from chinmaygarde February 3, 2022 06:56
@flar flar changed the title (WIP) maintain ColorFilter construction details for embedding in DisplayList maintain ColorFilter construction details for embedding in DisplayList Feb 4, 2022
@flar flar removed the Work in progress (WIP) Not ready (yet) for review! label Feb 4, 2022
@flar flar requested review from chinmaygarde and gw280 and removed request for chinmaygarde February 4, 2022 00:06
if (!filter) {
current_color_filter_type_ = kNone;
Push<ClearColorFilterOp>(0, 0);
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to factor all of this logic out into our own ColorFilter class? We could have a ctor that takes an SkColorFilter and returns a ColorFilter that has this logic in it, and other ctors like ColorFilter(color, blendmode), ColorFilter(matrix)... etc. We would then store that object on the DisplayListBuilder and reference that in UpdateCurrentOpacityCompatibility().

I think that adding excessive logic like this to DisplayListBuilder makes the class more and more difficult to keep track of what's going on, especially if we are planning to start adding logic similar to this for other objects like ImageFilters and Shaders. Conceptually I see DisplayListBuilder as just a simple recorder/dispatcher class, but maybe that's a faulty view on my part.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a local branch that I haven't turned into a PR yet where I do this. I create "display_list_color_filter.h/cc". There is a subclass that holds an SkColorFilter, but I don't have it do that logic in its constructor (because it's a constructor). I may make a factory static method, though, that encapsulates this logic.

@flar flar added the Work in progress (WIP) Not ready (yet) for review! label Feb 13, 2022
@flar flar changed the title maintain ColorFilter construction details for embedding in DisplayList (WIP) maintain ColorFilter construction details for embedding in DisplayList Feb 13, 2022
@flar flar closed this Mar 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Work in progress (WIP) Not ready (yet) for review!

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants