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

Require immutable, threadsafe render notifier at renderer initialization #1904

Merged
merged 2 commits into from Oct 22, 2017

Conversation

@jdm
Copy link
Member

jdm commented Oct 20, 2017

This addresses one of the top intermittent test failures in Servo and cleans up an awkward part of the renderer API. Instead of storing an optional notifier inside of a shared mutex, we require that the notifier is cloneable and is responsible for its own mutation requirements. This puts the onus on the implementation of a particular notifier to deal with threadsafety concerns, rather than making all consumers pay for it.


This change is Reviewable

@jdm jdm force-pushed the notifier branch 2 times, most recently from b4fe45a to 21212f1 Oct 20, 2017
@kvark
kvark approved these changes Oct 21, 2017
frame_config: FrameBuilderConfig,
recorder: Option<Box<ApiRecordingReceiver>>,
blob_image_renderer: Option<Box<BlobImageRenderer>>,
enable_render_on_scroll: bool,
) -> RenderBackend {
) -> RenderBackend<T> {

This comment has been minimized.

@kvark

kvark Oct 21, 2017

Member

nit: Self

fn new_frame_ready(&mut self);
fn new_scroll_frame_ready(&mut self, composite_needed: bool);
fn external_event(&mut self, _evt: ExternalEvent) {
pub trait RenderNotifier: Send + Clone {

This comment has been minimized.

@kvark

kvark Oct 21, 2017

Member

would it make sense to provide an empty implementation, e.g. for ()?

This comment has been minimized.

@jdm

jdm Oct 21, 2017

Author Member

I don't see the purpose if no code makes use of it.

@@ -132,7 +132,7 @@ static NEXT_NAMESPACE_ID: AtomicUsize = ATOMIC_USIZE_INIT;
/// GPU-friendly work which is then submitted to the renderer in the form of a frame::Frame.
///
/// The render backend operates on its own thread.
pub struct RenderBackend {
pub struct RenderBackend<T> {

This comment has been minimized.

@jrmuizel

jrmuizel Oct 21, 2017

Contributor

Is there a reason this needs to be generic instead of using a trait object? Having it generic is going to increase wrench's already bad build times and we don't have any need to inline or devirtualize the notifier.

This comment has been minimized.

@jdm

jdm Oct 21, 2017

Author Member

I have rewritten the changes to retain the trait object.

@jdm jdm force-pushed the notifier branch from 21212f1 to 78fd025 Oct 21, 2017
@glennw
Copy link
Member

glennw commented Oct 22, 2017

Reviewed 7 of 13 files at r1, 6 of 6 files at r2.
Review status: all files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.


Comments from Reviewable

@glennw
Copy link
Member

glennw commented Oct 22, 2017

@bors-servo r+

Thanks!

@staktrace Heads up - this will need an update to Gecko bindings. The render notifier is provided at initialization now and has slightly different requirements. Once this lands, I'll write a Gecko patch for that and post it here.

@bors-servo
Copy link
Contributor

bors-servo commented Oct 22, 2017

📌 Commit 78fd025 has been approved by glennw

@bors-servo
Copy link
Contributor

bors-servo commented Oct 22, 2017

Testing commit 78fd025 with merge d741f47...

bors-servo added a commit that referenced this pull request Oct 22, 2017
Require immutable, threadsafe render notifier at renderer initialization

This addresses one of the top intermittent test failures in Servo and cleans up an awkward part of the renderer API. Instead of storing an optional notifier inside of a shared mutex, we require that the notifier is cloneable and is responsible for its own mutation requirements. This puts the onus on the implementation of a particular notifier to deal with threadsafety concerns, rather than making all consumers pay for it.

<!-- 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/1904)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Oct 22, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: glennw
Pushing d741f47 to master...

@bors-servo bors-servo merged commit 78fd025 into master Oct 22, 2017
6 of 9 checks passed
6 of 9 checks passed
Taskcluster (pull_request) TaskGroup: Exception
Details
Taskcluster (push) TaskGroup: Exception
Details
code-review/reviewable 3 discussions left (jrmuizel, kvark)
Details
continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
dependency-ci Dependencies checked
Details
homu Test successful
Details
@glennw glennw deleted the notifier branch Oct 23, 2017
@staktrace
Copy link
Contributor

staktrace commented Oct 23, 2017

@glennw thanks for the heads up. Please post the patch to https://bugzil.la/wr-future-update when you have it, thanks!

@glennw
Copy link
Member

glennw commented Oct 23, 2017

@staktrace OK, attached a patch to that bug. I'm unfamiliar with bugzilla workflow, but hopefully that should be what you need to update for the notifier API changes (I've tested them locally).

@staktrace
Copy link
Contributor

staktrace commented Oct 23, 2017

@glennw Perfect, thanks!

@jrmuizel jrmuizel mentioned this pull request Apr 8, 2018
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

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