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

Sync changes from mozilla-central gfx/wr #3994

Merged
merged 18 commits into from Jun 25, 2020
Merged

Conversation

@moz-gfx
Copy link

moz-gfx commented Jun 24, 2020

No description provided.

nical and others added 17 commits Jun 24, 2020
…d of per-cluster. r=gw

After this change, clusters just keep a range of indices in the prim list's instance array.

Differential Revision: https://phabricator.services.mozilla.com/D80461

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/26fbdf4c708744a2f3a4201ba9c5b2823f0e3010
…lt framebuffer. r=jimb

For performance reasons in SWGL software compositors. to avoid unnecessary
full-screen copies of the framembuffer, we need to allow those compositors to
map their underlying widget surfaces and pass that buffer to SWGL so that they
can be directly rendered to. That also requires supporting custom strides, as
we can't always enforce the particular layout of the buffers handed off to us.
To that end, InitDefaultFramebuffer is generalized to take such information
and then many places where we rely on a specific hard-coded SWGL-calculated
stride have been altered to deal with a caller-supplied stride.

Differential Revision: https://phabricator.services.mozilla.com/D80267

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/671f7c62e83faa9f322a967a3a67917d3278ab9f
This patch a simple utility to help with pre-allocating vectors that we can't recycle and use it with the primitive headers.

Differential Revision: https://phabricator.services.mozilla.com/D80194

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/ac1dec27b771d02de0d729b6c458924fcddf28ae
Vector reallocations in CompositeState::push_surface are taking about 2% of total frame building time before this patch. There was an effort at preallocating some with constant values but I suspect these constants haven't been updated along with picture cachign heuristics.

Differential Revision: https://phabricator.services.mozilla.com/D80195

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/1e531a6c2590fc38bc1c0393f036b393e26f2118
It would be wasteful to preallocate all batch builders because the majority of them have only a single batch, while typically only one will will have many batches. Thankfully we can acurately guess which pictures will produce many batches by checking whether they have more than one cluster.

Differential Revision: https://phabricator.services.mozilla.com/D80469

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/45ef8e463b6ee4af10d09c6fd3be7a202644abd7
@moz-gfx
Copy link
Author

moz-gfx commented Jun 24, 2020

@bors-servo r=auto

@bors-servo
Copy link
Contributor

bors-servo commented Jun 24, 2020

📌 Commit 6419133 has been approved by auto

@bors-servo
Copy link
Contributor

bors-servo commented Jun 24, 2020

Testing commit 6419133 with merge 1b39ae4...

bors-servo added a commit that referenced this pull request Jun 24, 2020
Sync changes from mozilla-central gfx/wr
@bors-servo
Copy link
Contributor

bors-servo commented Jun 25, 2020

💥 Test timed out

We detect empty scroll roots by checking the valid scrollable size
of a frame, in order to avoid attaching picture cache slices to
these redundant scroll frames.

However, under some fractional zoom scenarios, rounding CSS pixels
to device pixels can result in small rounding errors.

Apply the same epsilon check that Gecko uses in APZ code in order
to detect if a scroll frame is actually scrollable.

Differential Revision: https://phabricator.services.mozilla.com/D80943

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/b425233628af9b3bfddcd4756940aac2444c8db1
@moz-gfx
Copy link
Author

moz-gfx commented Jun 25, 2020

@bors-servo r=auto

@bors-servo
Copy link
Contributor

bors-servo commented Jun 25, 2020

💡 This pull request was already approved, no need to approve it again.

  • This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.
@bors-servo
Copy link
Contributor

bors-servo commented Jun 25, 2020

📌 Commit a97c35c has been approved by auto

@bors-servo
Copy link
Contributor

bors-servo commented Jun 25, 2020

Testing commit a97c35c with merge 200e81e...

@bors-servo
Copy link
Contributor

bors-servo commented Jun 25, 2020

☀️ Test successful - status-taskcluster
Approved by: auto
Pushing 200e81e to master...

@bors-servo bors-servo merged commit 200e81e into servo:master Jun 25, 2020
2 checks passed
2 checks passed
Community-TC (pull_request) TaskGroup: success
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

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