Prerender tile spacing and use the brush shader.

[nical]

On top of #2621 and #2644, bake the tile spacing into an image using a blit render task.
This lets us use the brush shader with tile spacing. In order for spacing to fully work the way we intend it to we need a bit more work (see #2659), but since the image shader we use for tile spacing doesn't do the right thing either, I don't think it would be a problem to move forward with this independently of #2659's resolution.

---

This change is 

[nical]

This might only accidentally work, I didn't write any code to clear the target where the transparent pixels are (I'm guessing we don't automatically clear before blits), and we might want to implement this some other way. But it seems to work (at least in simple cases) with a relatively simple change which is satisfying.

[nical]

I am still a bit unsure about where the line is between the two but we might want to use a picture instead of a render task for this in order to support baking gradients.

[glennw]

Color render targets are always cleared to transparent before any render tasks are drawn into them (there is a possible optimization opportunity to skip this in cases where it doesn't matter).

The gradient + spacing question is an interesting one - baking them might be a bit tricky in cases where there is a transform active, I think. We can ponder that once we get the image + spacing baking working though :)

[bors-servo]

☔ The latest upstream changes (presumably #2663) made this pull request unmergeable. Please resolve the merge conflicts.

[bors-servo]

☔ The latest upstream changes (presumably #2621) made this pull request unmergeable. Please resolve the merge conflicts.

[nical]

Relevant review comment from #2695

webrender/src/device.rs, line 1253 at r1 (raw file):

               dest_rect.origin.x,
               dest_rect.origin.y,
               dest_rect.origin.x + src_rect.size.width,

I don't understand this change. This would mean that we can never do a blit which is a stretch?

Oops, I didn't know we support/need to do blits that stretch. I'll update the PR to support that properly.

[nical]

@glennw I added a commit that adds explicit support for padding in blit render tasks instead of using the target rect size and disallowing stretching blits (although we currently have an assertion checking that the source and destination sizes are equal).

[nical]

images/tile-with-spacing-ref.yaml renders with some garbage in the padded region. I added a bit logging and I am not seeing clears associated to the second blit, only the first one. Putting the padding in the first blit seems to fix the issue (not 100% sure though since it depends on what's in the texture). It's odd though, I'd like to know why I don't seem to be getting all of the clears I expect.

Actually, now that I am poking at this I wonder why we even do two blits and not just one when isolating sub-rects (and prerendering spacing since it uses the same code). I can see things don't show up when I do a single blit but it's not intuitive to me why we need it.

[glennw]

When we pre-render spacing, we're doing the following:

Texture cache -> render task surface -> Texture cache. 

If we don't do the intermediate blit, the source texture is the same as the destination FBO texture, which is undefined behaviour in GL.

[glennw]

(I haven't looked at this in detail, below is just a guess).

I suspect that when drawing items to the texture cache as a final destination, we don't issue any clears on that target type?

So the implicit assumption is that a task that targets the texture cache ends up writing every pixel. If that's the case - we should perhaps add support for clear mode (per render task) to texture cache targets, and a clear mode of "DontCare" if the task knows it will write to every pixel, to avoid clearing the task area in that case.

[nical]

The remaining reftest failure (blend-clipped.yaml) is caused by a difference introduced in the first patch that simplifies the repeated primitive parameters.
We have a primitive with a gradient of size 1887.0×239.0 and stretch size 1887.0×238.5. I added some code to make it so if we have a primitive with a bit of spacing and no repetition we just remove the spacing by making the prim rect equal to the stretch size.
As a result, the1887.0×238.5 rect gets snapped (while the stretch size currently isn't snapped) which introduces the difference.

Gecko shouldn't send non-integer stretch sizes to webrender (although it's something that we haven't fixed yet, so it currently does). I am tempted to change the reftest so that it uses the same stretch size and rect to avoid this configuration, although we could wait for gecko to fix the way it snaps stretch sizes to do that.
Either way I think that the behavior is sound and that the reference image can be updated.

[nical]

I punted on clearing the padding in the second blit and just used the first blit to insert the spacing. We can look into having more involved mechanisms later, but I suspect in the more general case we'll want to move to actually use a picture with more commands instead of just a couple of blit render tasks to better support some of the cases where we currently get sampling artifacts.

@glennw This PR should be ready to land if you are OK with that and the resolution in my previous comment.

Edit: Hold on, the gecko try run of #2704 has more failures than I expected, I'll do another push with this one specifically before we merge it.

[glennw]

The reftest change seems fine. I don't quite follow how the padding / clearing works though - if we don't clear, won't the previous contents of that texture cache allocation be left in the empty space?

[nical]

The first blit properly clears beforehand and we add the padding there. The second one blits the image including the pixels of the padding we prerendered so it shouldn't need a clear (unless blitting does some kind of blending).

[glennw]

Oh, of course. That makes sense :) Is this ready to go then, or do we want to do another try push as you mentioned above?

[nical]

Yeah, waiting for https://treeherder.mozilla.org/#/jobs?repo=try&revision=d20a0909031b4cd589f4b064e59afe4c81796af9 On the other PR's try push there is a number of tests with showing shape with a bit of blurriness at the bottom that I suspect come from here, unfortunately.

[nical]

I think I figured the main problem out, hopefully this try push will come back green: https://treeherder.mozilla.org/#/jobs?repo=try&revision=95142a60f5aa1e2b32b383b578aaea41eaeee372

Edit: it looks great so far with an unexpected pass as a bonus \o/

[glennw]

Reviewed 2 of 5 files at r1, 3 of 6 files at r2, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[glennw]

@bors-servo r+ 🚀

[bors-servo]

📌 Commit c9e4f80 has been approved by glennw

[bors-servo]

⌛ Testing commit c9e4f80 with merge 46a1185...

[bors-servo]

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: glennw
Pushing 46a1185 to master...