-
Couldn't load subscription status.
- Fork 301
Description
Tile spacing exists so that we can implement bacground-repeat: space which more or less means add some space between repetitions such that the first repetition starts exactly at the top left of the element and the last repetition ends exactly at the lower right of the element.
Example:
data:text/html,<div style="width:500px;height:200px;border:1px solid lightgrey; background:linear-gradient(to right, black 1px, lime 0, lime 199px, black 0); background-size: 200px 200px; background-repeat: space">
The current plan to support tile spacing is to bake the spacing in a render target by blitting the image with some transparent pixels around it, and then use the regular image shader to render it.
Repeating in the fragment shader makes it hard to support variable spacing to adjust repetitions so that they line up with the element's edge. We could support this by allowing non-integer spacing, but this means that a repeated image that would have been crisp in gecko today could be a bit blurry with webrender.
I'm tempted to say "meh, a bit of blurriness in with background-repeat: space is fine.", but others will (and already do) think otherwise.
If not having blurry repeated background-repeat: space images is important we could:
- Keep decomposing repeated images/gradients with spacing on the CPU. This means we potentially will generate a lot of primitives each frame and can't use a brush segments per repetition because of the limit of (MAX_VERTEX_TEXTURE_WIDTH - VECS_PER_PRIM) / VECS_PER_SEGMENT which means a bit less than 512 segments per primitive.
- come up with a way to avoid the blurriness in the shader
- maybe having a dedicated repeated_image_with_annoying_parameters.glsl that compensates the factional offset to avoid the extra blurriness somehow.