Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix for race condition when caching render tasks. #2313

Merged
merged 1 commit into from Jan 17, 2018

Conversation

@glennw
Copy link
Member

glennw commented Jan 17, 2018

When the renderer receives multiple Frames from the backend
in a single render loop, it drops the old frames and just
draws the most recent frame.

If that old frame contained a render task to write to the
texture cache, then the texture cache will never be updated.

This patches tracks whether a frame has any texture cache
render tasks, and whether it has been drawn before. If a
frame which meets those conditions is being replaced, then
do a render of that frame first, skipping the main framebuffer
pass.

This is not ideal since we may end up drawing offscreen render
tasks that were batched but which aren't strictly necessary
for the texture cache render target. However, it is very rare
that the render backend is (a) producing frames faster than they
are being consumed by the renderer and (b) also contain texture
cache tasks.


This change is Reviewable

When the renderer receives multiple Frames from the backend
in a single render loop, it drops the old frames and just
draws the most recent frame.

If that old frame contained a render task to write to the
texture cache, then the texture cache will never be updated.

This patches tracks whether a frame has any texture cache
render tasks, and whether it has been drawn before. If a
frame which meets those conditions is being replaced, then
do a render of that frame first, skipping the main framebuffer
pass.

This is not ideal since we may end up drawing offscreen render
tasks that were batched but which aren't strictly necessary
for the texture cache render target. However, it is very rare
that the render backend is (a) producing frames faster than they
are being consumed by the renderer and (b) also contain texture
cache tasks.
@glennw
Copy link
Member Author

glennw commented Jan 17, 2018

r? @kvark

This is a rather inelegant fix - if you have a better idea of how to solve it quickly, let me know!

@glennw
Copy link
Member Author

glennw commented Jan 17, 2018

@jrmuizel @staktrace I don't think it's likely you'll see this in Gecko, but if you are seeing it, and Gecko has updated past #2284 then this may explain any intermittent failures with box shadows.

}

// Glyph
if !self.font_indices.is_empty() {

This comment has been minimized.

@kvark

kvark Jan 17, 2018

Member

I assume these lines are just moved

This comment has been minimized.

@glennw

glennw Jan 17, 2018

Author Member

Yep, just indented.

@@ -1778,6 +1779,10 @@ impl FrameBuilder {
&self.clip_store,
RenderPassIndex(pass_index),
);

if let RenderPassKind::OffScreen { ref texture_cache, .. } = pass.kind {

This comment has been minimized.

@kvark

kvark Jan 17, 2018

Member

hmm, so any non-main-FBO tasks are considered for has_texture_cache_tasks? If the problem is only about skipping the tasks that are required for future rendering, we need a distinction between re-usable and non-reusable tasks, and only checks for the former here

This comment has been minimized.

@glennw

glennw Jan 17, 2018

Author Member

It checks for the texture_cache target being non-empty. So this excludes temporary render tasks.

// (in order to update the texture cache), issue
// a render just to off-screen targets.
if self.active_documents[pos].1.frame.must_be_drawn() {
self.render_impl(None).ok();

This comment has been minimized.

@kvark

kvark Jan 17, 2018

Member

technically, we only need to render the pos indexed document, not all of them.
Perhaps, we could accumulate the documents into something like inactive_documents vector that is flushed whenever we happen to render stuff?

This comment has been minimized.

@glennw

glennw Jan 17, 2018

Author Member

True - would it be OK to do that as a follow up?

@kvark
Copy link
Member

kvark commented Jan 17, 2018

@bors-servo
Copy link
Contributor

bors-servo commented Jan 17, 2018

📌 Commit db9a055 has been approved by kvark

@bors-servo
Copy link
Contributor

bors-servo commented Jan 17, 2018

Testing commit db9a055 with merge 9cad76a...

bors-servo added a commit that referenced this pull request Jan 17, 2018
Fix for race condition when caching render tasks.

When the renderer receives multiple Frames from the backend
in a single render loop, it drops the old frames and just
draws the most recent frame.

If that old frame contained a render task to write to the
texture cache, then the texture cache will never be updated.

This patches tracks whether a frame has any texture cache
render tasks, and whether it has been drawn before. If a
frame which meets those conditions is being replaced, then
do a render of that frame first, skipping the main framebuffer
pass.

This is not ideal since we may end up drawing offscreen render
tasks that were batched but which aren't strictly necessary
for the texture cache render target. However, it is very rare
that the render backend is (a) producing frames faster than they
are being consumed by the renderer and (b) also contain texture
cache tasks.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/2313)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Jan 17, 2018

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: kvark
Pushing 9cad76a to master...

@bors-servo bors-servo merged commit db9a055 into servo:master Jan 17, 2018
3 checks passed
3 checks passed
Taskcluster (pull_request) TaskGroup: success
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.