Confirmed users
138
edits
Gecko:2DGraphicsSketch: Difference between revisions
Jump to navigation
Jump to search
→Patterns
| Line 139: | Line 139: | ||
''The goal here is to be able to quickly stack-allocate patterns which are colors and SourceBuffers, but also to be able to cache backend-specific objects for the pattern.'' So these are not refcounted, are regular C++ values, and can be stack-allocated. But Pattern subclass objects can be different sizes so direct assignment between different kinds of patterns is not allowed. We do not use the placement new trick to change a Pattern to an implementation class. | ''The goal here is to be able to quickly stack-allocate patterns which are colors and SourceBuffers, but also to be able to cache backend-specific objects for the pattern.'' So these are not refcounted, are regular C++ values, and can be stack-allocated. But Pattern subclass objects can be different sizes so direct assignment between different kinds of patterns is not allowed. We do not use the placement new trick to change a Pattern to an implementation class. | ||
Bas: Hrm, I'm not sure we need to quickly stack allocate these. I think it's better to make the objects lightweight and just use 'real' pattern objects since particular for our own hardware backend a lot will go in here. For colors we should probably just cache a bunch and make them easily accessible (much like GDI stock objects), or perhaps even include a full 'maskcolor' in the CompositionOp (we could then blend 'alpha' into that color), and treat NULL as a fully white source. Specifying no pattern with a none-white mask color would then automatically behave as a 'color' pattern, and this would for example map fairly well on what shaders do internally. Just thinking out loud here though. | Bas: Hrm, I'm not sure we need to quickly stack allocate these. I think it's better to make the objects lightweight and just use 'real' pattern objects since particular for our own hardware backend a lot will go in here. For colors we should probably just cache a bunch and make them easily accessible (much like GDI stock objects), or perhaps even include a full 'maskcolor' in the CompositionOp (we could then blend 'alpha' into that color), and treat NULL as a fully white source. Specifying no pattern with a none-white mask color would then automatically behave as a 'color' pattern, and this would for example map fairly well on what shaders do internally. Just thinking out loud here though. We also probably want radial/linear gradient patterns separately, and maybe factor out gradient stops like D2D does, although I'm not sure there's much value in the latter. | ||
Patterns can only be used with a DrawTarget using the same backend type. | Patterns can only be used with a DrawTarget using the same backend type. | ||