Commits on Feb 4, 2020

1. Bug 1571974: Make prim_store::get_line_decoration_sizes return an ori… …

   …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

   

   Jim Blandy authored and moz-gfx committed Feb 4, 2020
   ec61634

2. Bug 1571974: Simplify orientation handling in line decoration shaders… …

   …. 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

   

   Jim Blandy authored and moz-gfx committed Feb 4, 2020
   b174a8e

3. Backed out 2 changesets (bug 1571974) for turning bug 1518179 into pe… …

   …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

   

   Oana Pop Rus authored and moz-gfx committed Feb 4, 2020
   3fb7bfe

4. Bug 1571974: Make prim_store::get_line_decoration_sizes return an ori… …

   …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

   

   Jim Blandy authored and moz-gfx committed Feb 4, 2020
   d2cbd3f

5. Bug 1571974: Simplify orientation handling in line decoration shaders… …

   …. 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

   

   Jim Blandy authored and moz-gfx committed Feb 4, 2020
   af9cef2

6. Bug 1608280 - Part 1 - Add a valid_rect to picture cache and composit… …

   …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

   

   gw3583 authored and moz-gfx committed Feb 4, 2020

   Loading status checks…
   74380b6