add ability to set weather the background should be cleared on RendererOptions

[jaredpetker]

Addition to #605 to have the ability to selectively clear the background.

The above pr almost did everything for my use case with not wanting the main background to be cleared. Even though you can currently set the clear color as transparent, this is obviously not good enough. I need the ability to draw over a pre-existing context entirely.

---

This change is 

[glennw]

I'm not sure I understand what this PR achieves, and I think it will break other things.

The renderer draws a number of passes as required - the last pass is always drawn to the framebuffer (well, currently bound FBO at start of render), and all other passes are drawn to intermediate internal render targets (these are used for things like box shadow caches etc).

The code here changes the clear of the internal render target passes, if I'm reading it correctly? Lots of parts of the renderer rely on the internal targets being cleared to a specific color / alpha, and I'm not sure how this would be related to the effect you're trying to achieve? I wonder if you're hitting the case where there are clear tiles that are being drawn as opaque, perhaps? (if so, there's a fix for that coming soon-ish in #648).

[jaredpetker]

I do know that clear tiles even with alpha of 0 were causing me issues before, and it's possible that is also the issue now? I suppose this fixes the issue for me at the moment (but I understand the concern), I can try pulling in the other pr to my local and giving it ago.

[jaredpetker]

I guess to be more clear, what I'm trying to solve is the fact that I'm drawing a pre-existing context. Say I have a game, or some other sort of thing going on, and using webrender to draw on top. Currently, without this, I can't achieve this, since even if I draw with argb 0000, it clears what was previously drawn to black.

[glennw]

Yep, I understand the use case - but it's not clear to me how this change could fix that.

In theory (perhaps I'm missing something or there is a bug), the code path that this PR changes should only affect whether or not internally used render targets are cleared.

Whether or not these internal render targets are cleared should have no effect on the way the final scene is composited to the frame buffer. But clearly it's having some effect for you, which is what I don't understand :) Is the code pushed somewhere that I could try and repro locally? Or are you able to paste a minimal list of a display list that shows the problem?

[jaredpetker]

It's not currently public, soon to be, I bet I can use the sample and come up with a simple case for this however.

…

On Tue, Dec 20, 2016 at 7:16 PM, Glenn Watson ***@***.***> wrote: Yep, I understand the use case - but it's not clear to me how this change could fix that. In theory (perhaps I'm missing something or there is a bug), the code path that this PR changes should only affect whether or not internally used render targets are cleared. Whether or not these internal render targets are cleared should have no effect on the way the final scene is composited to the frame buffer. But clearly it's having some effect for you, which is what I don't understand :) Is the code pushed somewhere that I could try and repro locally? Or are you able to paste a minimal list of a display list that shows the problem? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#655 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQVDM1UqEUg9t-PzloXlFyHzJKwwzAqks5rKJoDgaJpZM4LRer4> .

-- Cheers, Jared Petker

[glennw]

Sure - if you can fork the sample and send me a link with a repro, I'll take a look :)

[bors-servo]

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

[glennw]

Closing for now, since I don't think this is the right solution. Feel free to open an issue with more details and / or repro.