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 #3859

Merged
merged 4 commits into from Feb 14, 2020
Merged

Conversation

@moz-gfx
Copy link

moz-gfx commented Feb 13, 2020

No description provided.

Add support to the yaml reader and writer to be able to specify
that a primitive should set the PREFER_COMPOSITOR_SURFACE flag.

This flag is not currently used, but in future will signal the
picture caching code to promote a primitive to draw on a native
compositor surface where possible.

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

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

moz-gfx commented Feb 13, 2020

@bors-servo r=auto

@bors-servo
Copy link
Contributor

bors-servo commented Feb 13, 2020

📌 Commit 45d334b has been approved by auto

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

bors-servo commented Feb 13, 2020

Testing commit 45d334b with merge 7c4a777...

@bors-servo
Copy link
Contributor

bors-servo commented Feb 13, 2020

💔 Test failed - status-appveyor

gw3583 and others added 3 commits Feb 14, 2020
…=nical,Bert

Simplify some of the logic related to handling multiple
compositor surfaces in future, specifically:

* Only rebuild the tiles map when the tile rect changes.
* Remove need for tiles_to_draw array.

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

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/0c0eb80974b03f6cc153616fe21c8dc229b25c3e
…hs in local space. r=lsalzman

This patch makes the CPU side incorporate the raster scale when
calculating the subpixel position of a glyph. It also makes the shader
side not include the glyph scale factor when recalculating the glyph
position (since it was not known/used when determining the subpixel
position in the first place). This makes the subpixel position stable
when we transition between Screen and Local(raster_scale) spaces.

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

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

moz-gfx commented Feb 14, 2020

@bors-servo r=auto

@bors-servo
Copy link
Contributor

bors-servo commented Feb 14, 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 Feb 14, 2020

📌 Commit 13aac2e has been approved by auto

@bors-servo
Copy link
Contributor

bors-servo commented Feb 14, 2020

Testing commit 13aac2e with merge 1b78e8a...

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

bors-servo commented Feb 14, 2020

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: auto
Pushing 1b78e8a to master...

@bors-servo bors-servo merged commit 13aac2e into servo:master Feb 14, 2020
3 checks passed
3 checks passed
Community-TC (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.