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

Only trigger a frame build if scene properties have changed. #2927

Merged
merged 1 commit into from Jul 24, 2018

Conversation

@gw3583
Copy link
Collaborator

gw3583 commented Jul 24, 2018

In many important use cases (e.g. video playback on youtube) the
display list doesn't change very often. Typically, the only
thing changing between frames are the natively decoded video
texture surfaces.

In these cases, we can save a significant amount of CPU usage
and battery power by not building a frame at all.

Previously, any call to set/update dynamic properties would
trigger a frame rebuild. However, it's often the case that
Gecko sends dynamic properties updates that are either empty
or exactly the same as the previous frame.

With this change, WR will compare the scene properties and
only trigger a frame rebuild if they have actually changed.

This is a partial step towards fixing #2917 - a couple of
other changes are also needed to completely avoid a frame
rebuiild in this use case.


This change is Reviewable

@gw3583
Copy link
Collaborator Author

gw3583 commented Jul 24, 2018

r? @kvark and / or @staktrace

@@ -602,12 +602,9 @@ impl RenderBackend {
}

fn process_frame_msg(
&mut self,
document_id: DocumentId,
doc: &mut Document,

This comment has been minimized.

@kvark

kvark Jul 24, 2018

Member

nit: might as well just make it a method of Document

This comment has been minimized.

@gw3583

gw3583 Jul 24, 2018

Author Collaborator

Done

}
let mut pending_properties = self.pending_properties
.take()
.unwrap_or(DynamicProperties::new());

This comment has been minimized.

@kvark

kvark Jul 24, 2018

Member

nit: unwrap_or_default could be handy

This comment has been minimized.

@gw3583

gw3583 Jul 24, 2018

Author Collaborator

Done

self.float_properties
.insert(property.key.id, property.value);
if let Some(pending_properties) = self.pending_properties.take() {
if pending_properties != self.current_properties {

This comment has been minimized.

@kvark

kvark Jul 24, 2018

Member

would it be worse to just keep the properties_changed flag and update it in set_properties and update_properties?

This comment has been minimized.

@gw3583

gw3583 Jul 24, 2018

Author Collaborator

Within a single transaction, Gecko often has at least one set_properties, followed by an append_properties. It seems more robust to compare after all changes for a transaction have occurred.

pub struct DynamicProperties {
pub transforms: Vec<PropertyValue<LayoutTransform>>,
pub floats: Vec<PropertyValue<f32>>,
}

impl DynamicProperties {

This comment has been minimized.

@kvark

kvark Jul 24, 2018

Member

nit: [derive(Default)] could replace this

This comment has been minimized.

@gw3583

gw3583 Jul 24, 2018

Author Collaborator

Done

In many important use cases (e.g. video playback on youtube) the
display list doesn't change very often. Typically, the only
thing changing between frames are the natively decoded video
texture surfaces.

In these cases, we can save a significant amount of CPU usage
and battery power by not building a frame at all.

Previously, any call to set/update dynamic properties would
trigger a frame rebuild. However, it's often the case that
Gecko sends dynamic properties updates that are either empty
or exactly the same as the previous frame.

With this change, WR will compare the scene properties and
only trigger a frame rebuild if they have actually changed.

This is a partial step towards fixing #2917 - a couple of
other changes are also needed to completely avoid a frame
rebuiild in this use case.
@gw3583 gw3583 force-pushed the gw3583:faster-properties branch from 6d96a60 to b21331e Jul 24, 2018
@kvark
kvark approved these changes Jul 24, 2018
Copy link
Contributor

staktrace left a comment

The changes look good to me, thanks!

@kvark
Copy link
Member

kvark commented Jul 24, 2018

@bors-servo
Copy link
Contributor

bors-servo commented Jul 24, 2018

📌 Commit b21331e has been approved by kvark

bors-servo added a commit that referenced this pull request Jul 24, 2018
Only trigger a frame build if scene properties have changed.

In many important use cases (e.g. video playback on youtube) the
display list doesn't change very often. Typically, the only
thing changing between frames are the natively decoded video
texture surfaces.

In these cases, we can save a significant amount of CPU usage
and battery power by not building a frame at all.

Previously, any call to set/update dynamic properties would
trigger a frame rebuild. However, it's often the case that
Gecko sends dynamic properties updates that are either empty
or exactly the same as the previous frame.

With this change, WR will compare the scene properties and
only trigger a frame rebuild if they have actually changed.

This is a partial step towards fixing #2917 - a couple of
other changes are also needed to completely avoid a frame
rebuiild in this use case.

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

bors-servo commented Jul 24, 2018

Testing commit b21331e with merge cf9b780...

@bors-servo
Copy link
Contributor

bors-servo commented Jul 24, 2018

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

@bors-servo bors-servo merged commit b21331e into servo:master Jul 24, 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.