Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSync changes from mozilla-central gfx/wr #3848
Merged
+126
−82
Conversation
and others
added 6 commits
Feb 4, 2020
…ented LayoutSize. r=kvark Without this change, get_line_decoration_sizes returns an (inline_size, block_size) pair, where inline_size is parallel to the line being decorated, and block_size perpendicular. However, these values are generally used as the dimensions of an axis-aligned bounding box for the line, not as specific parameters to the rendering process, so it makes sense to arrange them into a LayoutSize value in this function, since it is already taking the orientation into account anyway. The caller, SceneBuilder::add_line, then doesn't need to swap the components, and the adjustment of the clipping rectangle to avoid partial dots looks a bit more natural: widths with widths, heights with heights. Differential Revision: https://phabricator.services.mozilla.com/D60925 [ghsync] From https://hg.mozilla.org/mozilla-central/rev/3549dd471446c291864822736f4587c81741cd56
…. r=kvark We want to use the same line decoration (dashed, dotted, wavy) shader code for both horizontal and vertical lines, so it makes sense for them to use a coordinate system that has been rotated (transposed, actually) so that .x always runs parallel to the line being decorated, and .y is always perpendicular. Before this patch, we passed the orientation enum as a vertex attribute, used a switch to swap coordinates in the vertex shader, and then swapped them again in the fragment shader. This patch trades the orientation for a f32 'axis select' vertex attribute, and uses `mix` to swap them in the vertex shader. Then no consideration is necessary in the fragment shader: the vLocalPos varying is already in the appropriate form. Since get_line_decoration_sizes is already thinking in terms of line-parallel coordinates, it might seem like a good idea for decoration jobs to simply use line-parallel coordinates throughout. However, this actually results in more swapping and opportunities for confusion: much of the CPU work is concerned with the rectangle the decoration's mask occupies in the texture cache, which is axis-aligned. Differential Revision: https://phabricator.services.mozilla.com/D60926 [ghsync] From https://hg.mozilla.org/mozilla-central/rev/dfb21632ea198c1acdc6a34ee08113d516f666d5
…rma bc failures. on a CLOSED TREE Backed out changeset dfb21632ea19 (bug 1571974) Backed out changeset 3549dd471446 (bug 1571974) [ghsync] From https://hg.mozilla.org/mozilla-central/rev/801277ae423f6f5183d62c45cda342ea28ee6040
…ented LayoutSize. r=kvark Without this change, get_line_decoration_sizes returns an (inline_size, block_size) pair, where inline_size is parallel to the line being decorated, and block_size perpendicular. However, these values are generally used as the dimensions of an axis-aligned bounding box for the line, not as specific parameters to the rendering process, so it makes sense to arrange them into a LayoutSize value in this function, since it is already taking the orientation into account anyway. The caller, SceneBuilder::add_line, then doesn't need to swap the components, and the adjustment of the clipping rectangle to avoid partial dots looks a bit more natural: widths with widths, heights with heights. Differential Revision: https://phabricator.services.mozilla.com/D60925 [ghsync] From https://hg.mozilla.org/mozilla-central/rev/9f54a1daf2f205d25f8d1b12ec09ed29176f9f2d
…. r=kvark We want to use the same line decoration (dashed, dotted, wavy) shader code for both horizontal and vertical lines, so it makes sense for them to use a coordinate system that has been rotated (transposed, actually) so that .x always runs parallel to the line being decorated, and .y is always perpendicular. Before this patch, we passed the orientation enum as a vertex attribute, used a switch to swap coordinates in the vertex shader, and then swapped them again in the fragment shader. This patch trades the orientation for a f32 'axis select' vertex attribute, and uses `mix` to swap them in the vertex shader. Then no consideration is necessary in the fragment shader: the vLocalPos varying is already in the appropriate form. Since get_line_decoration_sizes is already thinking in terms of line-parallel coordinates, it might seem like a good idea for decoration jobs to simply use line-parallel coordinates throughout. However, this actually results in more swapping and opportunities for confusion: much of the CPU work is concerned with the rectangle the decoration's mask occupies in the texture cache, which is axis-aligned. Differential Revision: https://phabricator.services.mozilla.com/D60926 [ghsync] From https://hg.mozilla.org/mozilla-central/rev/71ce2bbd81881f19f797cfc8aec7e7ea2ea8347f
…e tiles. r=mstange This patch introduces a per-tile valid rect. In the initial implementation, this only uses the bounds of the overall picture cache bounding rect. The next part of this patch will make use of true per-tile valid regions, to improve performance where there are holes in a single cache slice. Differential Revision: https://phabricator.services.mozilla.com/D61378 [ghsync] From https://hg.mozilla.org/mozilla-central/rev/42095e4b17091e46bd63d72f17145505ab1f8faf
|
@bors-servo r=auto |
|
|
bors-servo
added a commit
that referenced
this pull request
Feb 4, 2020
Sync changes from mozilla-central gfx/wr
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
moz-gfx commentedFeb 4, 2020
No description provided.