For Draw (non-native) and CA modes, we include the per-tile
valid rect in the clip rect from the surface.
For DC (non-virtual) mode, a per-tile clip rect is set on the
visual for each tile, separate from the overall clip rect that
is set on the surface visual.
For DC (virtual) mode, the Trim API is used to remove pixels
in the virtual tile area that are outside the valid / clipped
region.
Note: Although the valid rect is now applied in the native
compositors, it's currently only based on the overall picture
cache bounding rect. Thus, with this patch there isn't any
noticeable performance improvement. Once this lands and is
working correctly, the follow up patch to calculate a smaller
valid region per-tile is a small amount of work.
Differential Revision: https://phabricator.services.mozilla.com/D61424
--HG--
extra : moz-landing-system : lando
I think this probably only shows up with fission oop iframes, tabs probably avoid this path.
The problem occurs when we reconstruct the containing iframe for a style change, we briefly hide the child document, clearing the display list on the parent via ClearCachedResources. Then show it again, we attempt an empty transaction and this succeeds because there is nothing to stop it. (The non-wr case fails because the layer contents are missing and that causes the empty transaction to fail.)
So keep track if we have sent a display list to the parent to allow/disallow an empty transaction.
This fixes a couple webrender+fission reftest failures but it's also a general rendering bug in webrender+fission reproducible in a regular browser.
Differential Revision: https://phabricator.services.mozilla.com/D61577
--HG--
extra : moz-landing-system : lando
I think this probably only shows up with fission oop iframes, tabs probably avoid this path.
The problem occurs when we reconstruct the containing iframe for a style change, we briefly hide the child document, clearing the display list on the parent via ClearCachedResources. Then show it again, we attempt an empty transaction and this succeeds because there is nothing to stop it. (The non-wr case fails because the layer contents are missing and that causes the empty transaction to fail.)
So keep track if we have sent a display list to the parent to allow/disallow an empty transaction.
This fixes a couple webrender+fission reftest failures but it's also a general rendering bug in webrender+fission reproducible in a regular browser.
Differential Revision: https://phabricator.services.mozilla.com/D61577
--HG--
extra : moz-landing-system : lando
So as to avoid UB. It is somewhat unfortunate/dumb the fact that we need to do
this and we can't detect when we forget to do it :(
Give it uint8_t as it's type as that's enough and consistent with LogicalSide.
Differential Revision: https://phabricator.services.mozilla.com/D62390
--HG--
extra : moz-landing-system : lando
When BasicCompositor is used, BasicCompositor does not use CompositorWindow.
Differential Revision: https://phabricator.services.mozilla.com/D61345
--HG--
extra : moz-landing-system : lando
This is another one which is included everywhere. If the OOL call mattered we
could move these to a different header or something, but I suspect it won't.
Differential Revision: https://phabricator.services.mozilla.com/D62173
--HG--
extra : moz-landing-system : lando
We include it everywhere because it's included from gfxTypes.h.
This should avoid including all the generated bindings _everywhere_.
Differential Revision: https://phabricator.services.mozilla.com/D62174
--HG--
extra : moz-landing-system : lando
In bug 1578329 I introduced two scoping mistakes:
- A marker was made to have a shorter duration.
- A label was scoped too short and so would most likely be missed during
sampling.
This patch reverts to the original wider scope.
Differential Revision: https://phabricator.services.mozilla.com/D62274
--HG--
extra : moz-landing-system : lando
Fourth iteration: improve the detail in reported tile invalidations.
The invalidation enum stores the old and new values for lightweight
types. For a change in PrimCount, the old and new list of ItemUids is
stored (if logging is enabled); the tool can then diff the two to see
what was added and removed. To convert that back into friendly strings,
the interning activity is used to build up a map of ItemUid to a string.
A similar special-casing of Content Descriptor will print the item
that's invalidating the tile, plus the origin and/or rectangle.
Also adding zoom and pan command line options both to fix high-DPI
issues and also to allow zooming out far enough to see out-of-viewport
cache lifetime and prefetching due to scrolling.
Also fix a bug where interning updates get lost if more than one update
happens without building a frame: switch to a vector of serialized
updatelists (one per type) instead of allowing just one string (per
type).
Differential Revision: https://phabricator.services.mozilla.com/D61656
--HG--
extra : moz-landing-system : lando
The test is meant to check that tupes work and a tuple of a single element needs a comma to differentiate it from just being the element.
Differential Revision: https://phabricator.services.mozilla.com/D61681
--HG--
extra : moz-landing-system : lando
This ensures that even if APZ is force-disabled, the permanent offset between
the visual and layout viewports is preserved during rendering.
Differential Revision: https://phabricator.services.mozilla.com/D62094
--HG--
extra : moz-landing-system : lando
Bug 1609002 made it so that the async scroll offset sent to webrender
is taken from only the layout component of the async transform, rather
than the combined layout and visual components. The consequence of
this is that the layout-only transform is in LayerPixel space (and
unnaffected by the async zoom) rather than ParentLayerPixel
space (which is affected by async zoom).
To convert the value to LayoutDevicePixel space, as webrender expects,
we were dividing by the pinch zoom scale, which includes the async
zoom. This was causing content to jump around whilst async panning and
zooming, as the scroll offset was incorrectly scaled. This is fixed
by instead dividing by the cumulative resolution, which does not
include the async zoom.
Differential Revision: https://phabricator.services.mozilla.com/D61787
--HG--
extra : moz-landing-system : lando
Bug 1609002 made it so that the async scroll offset sent to webrender
is taken from only the layout component of the async transform, rather
than the combined layout and visual components. The consequence of
this is that the layout-only transform is in LayerPixel space (and
unnaffected by the async zoom) rather than ParentLayerPixel
space (which is affected by async zoom).
To convert the value to LayoutDevicePixel space, as webrender expects,
we were dividing by the pinch zoom scale, which includes the async
zoom. This was causing content to jump around whilst async panning and
zooming, as the scroll offset was incorrectly scaled. This is fixed
by instead dividing by the cumulative resolution, which does not
include the async zoom.
Differential Revision: https://phabricator.services.mozilla.com/D61787
--HG--
extra : moz-landing-system : lando
To avoid computing transform bounds over and over. It is generally just better.
Replace the various "overridebounds" thingies by using the "fallback" of the
transform-reference-box code which we need anyway.
Differential Revision: https://phabricator.services.mozilla.com/D61890
--HG--
extra : moz-landing-system : lando
Implement WaylandDMABUFSurfaceImage which is backed by dma buf memory on Wayland and it holds
decoded video images produced by ffmpeg va-api decoder.
Differential Revision: https://phabricator.services.mozilla.com/D61678
--HG--
extra : moz-landing-system : lando
Implement WaylandDMABUFSurfaceImage which is backed by dma buf memory on Wayland and it holds
decoded video images produced by ffmpeg va-api decoder.
Differential Revision: https://phabricator.services.mozilla.com/D61678
--HG--
extra : moz-landing-system : lando
This patch adds reporting the surface types used by the image frame in a
bit mask (such if it is a CAPTURE including a DATA_SHARED, the mask will
be 1 << CAPTURE | 1 << DATA_SHARED), as well as an estimated size
included in the report as decoded-unknown for when we do not know if the
surface is on the heap or the non-heap specifically. This is the default
implementation for a SourceSurface as well, so we should no longer have
the case where surfaces appear empty despite being in the cache. It also
makes requests being validated as always notable for reporting purposes.
Differential Revision: https://phabricator.services.mozilla.com/D61458
--HG--
extra : moz-landing-system : lando
We will no longer allow OMTP on 32-bit systems with less than 2GB of RAM
and 2 or fewer cores. These systems are unlikely to realize a benefit
from OMTP and see a higher than normal incidence of OOM crashes in the
content process due to OMTP having a higher memory footprint.
Differential Revision: https://phabricator.services.mozilla.com/D60058
--HG--
extra : moz-landing-system : lando
We incorporate the reference frame origin offset for non-animated
transforms, but forgot for animated transforms. Since the offset itself
is not animated, we should still incorporate it into the snapping
transform.
Differential Revision: https://phabricator.services.mozilla.com/D61689
--HG--
extra : moz-landing-system : lando
The test is meant to check that tupes work and a tuple of a single element needs a comma to differentiate it from just being the element.
Differential Revision: https://phabricator.services.mozilla.com/D61681
--HG--
extra : moz-landing-system : lando
SyncObjectD3D11Host::Synchronize() calling in RenderCompositorANGLE::BeginFrame() is still necessary for D3D11DXVA2Manager::CopyToImage(). Then backout Bug 1596630.
Differential Revision: https://phabricator.services.mozilla.com/D61658
--HG--
extra : moz-landing-system : lando
We need a way to switch it on and off to compare the performance and power usage of various test cases.
The new pref is "webrender.enable-multithreading" and does not require a restart.
Differential Revision: https://phabricator.services.mozilla.com/D61589
--HG--
extra : moz-landing-system : lando
- Create new SharedSurfaceType called EGLSurfaceDMABUF
- Implement EGLSurfaceDMABUF by SharedSurfaceDMABUF which is backed by WaylandDMABufSurface.
It can be used by Wayland/EGL WebGL backend.
- It's disabled by default, can be enabled by widget.wayland_dmabuf_webgl.enabled pref.
Differential Revision: https://phabricator.services.mozilla.com/D60114
--HG--
extra : moz-landing-system : lando
No other items need to round their bounds/clips, and backdrop filters
should be no exception. They should trust scene building (and to a
lesser extent, frame building) to perform any necessary snapping. This
patch also removes the ToRoundedLayoutPoint/Rect methods as there are no
more users of the APIs, nor should there ever be.
Differential Revision: https://phabricator.services.mozilla.com/D61618
--HG--
extra : moz-landing-system : lando
addUpdateRect needs to be called after beginFrame, otherwise it doesn't do anything.
Differential Revision: https://phabricator.services.mozilla.com/D59155
--HG--
extra : moz-landing-system : lando
The CARenderer documentation does not provide any guidance on how to use CARenderer with different resolutions.
In the initial implementation I simply tried the following: Make a device-pixel sized framebuffer, call glViewport with the device pixel size, and then call glOrtho with the "point" size. And this seemed to work.
However, it doesn't always work. When hooking up profiler screenshots, I noticed that in some cases, some layers would just not be rendered. Sometimes I even saw layers show up in wrong places.
After this patch, these problems no longer appear.
Differential Revision: https://phabricator.services.mozilla.com/D59154
--HG--
extra : moz-landing-system : lando
In bug 1574493, we moved most snapping to scene building and a minority
to frame building. No snapping is done in the shader. However there was
some left over code that still tried to replicate the past behaviour and
this caused wobbling during the rendering. This patch removes the extra
snapping on the CPU side and trusts scene/frame building to do the job.
Differential Revision: https://phabricator.services.mozilla.com/D61590
--HG--
extra : moz-landing-system : lando
Webrender positions sticky items relative to the viewport rect set on
their ancestor scroll frame, which it expects to be in local
space. The viewport should be set to what gecko calls the scroll
frame's "scroll port" (relative to its reference frame).
Previously we were setting this to be `composition bounds /
resolution`, which gives the correct results at the initial zoom
level, but causes sticky items to jump around when the zoom
changes. This occurs because the composition bounds of the RCD-RSF do
not change as the zoom changes, and instead remain equal to the
widget's size.
The layout viewport remains at the correct size when zoomed, but
unfortunately doesn't have the correct origin. And FrameMetrics does
not provide the constant "initial zoom" value we require to obtain the
desired viewport rect from the composition bounds. To fix this we
therefore must query the scroll port and offset directly from the
scrollable frame, meaning the value remains correct even as the zoom
changes.
Differential Revision: https://phabricator.services.mozilla.com/D60970
--HG--
extra : moz-landing-system : lando
There's two potential cases handled by this patch:
(1) A scrollbar container followed by another scrollbar container.
In this case, we need to ensure these are placed into separate
clusters, even though the cluster flags otherwise match, to
ensure that slice creation will see the two clusters.
(2) If a fixed position scroll root trails a scrollbar container.
In this case, ensure that a scrollbar contains marks the
cluster flags to create a slice straight after the scrollbar,
to avoid other primitives with the same scroll root sneaking
into the scrollbar container.
Differential Revision: https://phabricator.services.mozilla.com/D61519
--HG--
extra : moz-landing-system : lando
This patch is generated via:
1. Manually modify gfx/2d/Types.h
2. Run the following script and clang-format.
3. Add brackets for the for loop in nsCSSRendering.cpp.
```
function rename() {
echo "Renaming $1 to $2"
rg -l "$1" | xargs sed -i -E -e s/"$1"/"$2"/g
}
rename "NS_FOR_CSS_HALF_CORNERS\(i\)" "for (const auto i : mozilla::AllPhysicalHalfCorners())"
rename "NS_FOR_CSS_HALF_CORNERS\(corner\)" "for (const auto corner : mozilla::AllPhysicalHalfCorners())"
```
Differential Revision: https://phabricator.services.mozilla.com/D61252
--HG--
extra : moz-landing-system : lando
This patch is generated via:
1. Manually modify gfx/2d/Types.h
2. Run the following script and clang-format.
```
function rename() {
echo "Renaming $1 to $2"
rg -l "$1" | xargs sed -i -E -e s/"$1"/"$2"/g
}
rename "NS_FOR_CSS_FULL_CORNERS\(i\)" "for (const auto i : mozilla::AllPhysicalCorners())"
rename "NS_FOR_CSS_FULL_CORNERS\(corner\)" "for (const auto corner : mozilla::AllPhysicalCorners())"
```
Differential Revision: https://phabricator.services.mozilla.com/D61251
--HG--
extra : moz-landing-system : lando
This patch is generated via:
1. Manually modify gfx/2d/Types.h
2. Run the following script and clang-format.
```
function rename() {
echo "Renaming $1 to $2"
rg -l "$1" | xargs sed -i -E -e s/"$1"/"$2"/g
}
rename "NS_FOR_CSS_SIDES\(side\)" "for (const auto side : mozilla::AllPhysicalSides())"
rename "NS_FOR_CSS_SIDES\(s\)" "for (const auto s : mozilla::AllPhysicalSides())"
rename "NS_FOR_CSS_SIDES\(i\)" "for (const auto i : mozilla::AllPhysicalSides())"
rename "NS_FOR_CSS_SIDES\(ix\)" "for (const auto ix : mozilla::AllPhysicalSides())"
```
Differential Revision: https://phabricator.services.mozilla.com/D61250
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : rebase_source : 8dcd8455c664067dd25f583c944d611a35c25e79
extra : source : dfb21632ea198c1acdc6a34ee08113d516f666d5
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
--HG--
extra : rebase_source : 093d572a7a35bddc6e070fc08d511f7f164a4d89
extra : source : 3549dd471446c291864822736f4587c81741cd56
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
We replace SetWidthIfLength and SetOffsetIfLength with ComputeDecorationLine{Thickness,Offset} functions,
and consolidate more of the computation of the offset within this function to simplify callers.
Differential Revision: https://phabricator.services.mozilla.com/D61454
--HG--
extra : moz-landing-system : lando
For zoomable APZCs, we were correctly dividing the scroll offset by
the pinch zoom scale. This is effectively equal to multiplying by the
device pixel ratio then dividing by the zoom, converting the offset
from parent layer space to layout device space.
However, for non-zoomable APZCs, we were incorrectly assuming that the
pinch zoom scale equalled 1.0. This was causing us to send incorrectly
scaled async scroll offsets to webrender, resulting in content moving
too slowly or quickly whilst asynchronously panning, then suddenly
jumping as the synchronous scroll offset caught up.
This is fixed by ensuring we always divide the asynchronous scroll
offset by the pinch zoom scale, regardless of whether the APZC is
zoomable or not.
Differential Revision: https://phabricator.services.mozilla.com/D61315
--HG--
extra : moz-landing-system : lando
SourceSurfaceCapture can contain an underlying surface instead of a set
of drawing commands. The surface has its own valid state, and must be
checked by the parent in SourceSurfaceCapture::IsValid. If we don't,
then we may end up failing silently while drawing, and images will go
missing. The underlying surface can be invalidated by a device reset if
it is a SourceSurfaceD2D1, as an example.
Differential Revision: https://phabricator.services.mozilla.com/D61245
--HG--
extra : moz-landing-system : lando
EGL_KHR_swap_buffers_with_damage (or EGL_EXT_swap_buffers_with_damage)
is an EGL extension that allows the application to inform the display
server (system compositor) which areas of the window have changed.
This commit implements support for that extension in the layers compositor.
The layers compositor always renders the whole frame, so we're only getting
the benefit of not redrawing unchanged areas *in the system compositor*,
not actually doing partial invalidation/compositing,
but that makes the implementation simpler (no need to track buffer age).
Differential Revision: https://phabricator.services.mozilla.com/D51517
--HG--
extra : moz-landing-system : lando
Previously, we would wait until the following frame (for uncertain reasons
that date back to B2G), but this meant the layout and visual viewports would
be out of sync for a frame, causing APZ to misbehave.
Differential Revision: https://phabricator.services.mozilla.com/D61286
--HG--
extra : moz-landing-system : lando
Some updates and clarifications after Glenn's All Hands 2020 overview
talk.
Differential Revision: https://phabricator.services.mozilla.com/D61270
--HG--
extra : moz-landing-system : lando
There is nothing clipping related in there anymore.
Differential Revision: https://phabricator.services.mozilla.com/D61178
--HG--
rename : gfx/wr/webrender/src/clip_scroll_tree.rs => gfx/wr/webrender/src/spatial_tree.rs
extra : moz-landing-system : lando
Third iteration:
Fix broken scrolling (and incorrect positioning of quad tree lines) by
serializing the SpaceMapper(-transform) from take_context, and using it
to transform the primitive rects (instead of the previous translation
based on unclipped.origin);
Note: this is done at visualization time and not at export time to
distinguish actually moving elements from merely-scrolling ones.
Serialize the entire UpdateList, so we get the data (Keys) that's being
added; add it to the overview;
Move the static CSS code into tilecache_base.css; add this and the .js
file to the binary, write them as part of output (instead of manual
copy); clean up CSS a bit;
Differential Revision: https://phabricator.services.mozilla.com/D61049
--HG--
extra : source : 535ae1d4818a3f0af64d61846035135751352bd1
extra : histedit_source : bf9a8f830ec7db4c2d1fcb6deaaf72949d6b69ed
Third iteration:
Fix broken scrolling (and incorrect positioning of quad tree lines) by
serializing the SpaceMapper(-transform) from take_context, and using it
to transform the primitive rects (instead of the previous translation
based on unclipped.origin);
Note: this is done at visualization time and not at export time to
distinguish actually moving elements from merely-scrolling ones.
Serialize the entire UpdateList, so we get the data (Keys) that's being
added; add it to the overview;
Move the static CSS code into tilecache_base.css; add this and the .js
file to the binary, write them as part of output (instead of manual
copy); clean up CSS a bit;
Differential Revision: https://phabricator.services.mozilla.com/D61049
--HG--
extra : moz-landing-system : lando
We currenly only support the dynamic toolbar at bottom, so we apply the
`fixed margin offset` only if the sticky element is stuck at the bottom
of the root scroll container.
Differential Revision: https://phabricator.services.mozilla.com/D60066
--HG--
extra : moz-landing-system : lando
nsRect's special member functions are pretty vanilla aside from the MOZ_COUNT_{C,D}TORs, so the copy assignment doesn't need to do anything unusual, but let's state so explicitly to please the compiler.
Differential Revision: https://phabricator.services.mozilla.com/D60991
--HG--
extra : moz-landing-system : lando
Adds support for bind groups and compute pipelines
The end goal of this PR is to run the compute example.
Differential Revision: https://phabricator.services.mozilla.com/D60746
--HG--
extra : moz-landing-system : lando
Adds support for bind groups and compute pipelines
The end goal of this PR is to run the compute example.
Differential Revision: https://phabricator.services.mozilla.com/D60746
--HG--
extra : moz-landing-system : lando
Second part: trace the updates that are sent to the DataStore, and save
at least the Insert/Remove and ItemUID as part of the wr-capture.
(We could expand this with more info, eg. the actual Keys, later).
TileView then reads them back and generates a color coded report to
overlay with the page view. This helps to see the types and amounts of
interned primitives that lead to cache invalidations.
Differential Revision: https://phabricator.services.mozilla.com/D60619
--HG--
extra : moz-landing-system : lando
On pages with many render tasks (typically a lot of text shadows), we spend a lot of time moving RenderTask which is a fairly large struct into the render graph's buffer. This patch avoids it by using the VecHelper trick of allocaitng space before initializing the value. Some RenderTask::new_* methods which take the render task graph in parameter were modified to add the task and return the task ID to work around borrow-checking restriction.
Differential Revision: https://phabricator.services.mozilla.com/D60854
--HG--
extra : moz-landing-system : lando
Second part: trace the updates that are sent to the DataStore, and save
at least the Insert/Remove and ItemUID as part of the wr-capture.
(We could expand this with more info, eg. the actual Keys, later).
TileView then reads them back and generates a color coded report to
overlay with the page view. This helps to see the types and amounts of
interned primitives that lead to cache invalidations.
Differential Revision: https://phabricator.services.mozilla.com/D60619
--HG--
extra : moz-landing-system : lando
The computation of the repetition depends on the aspect ratio of the segment's uv rectangle, which was previously represented by the dx/dy variables in the shader. These were mistakenly computing the ratio of the normalized uvs within the primitive's total uv rect, which was incorrect since the normalization introduces a non-uniform scale.
This patch fixes it by taking the uv size in device pixels instead of the the normalized textel rect. dx and dy are also renamed into segment_uv_size which is a more informative name.
Differential Revision: https://phabricator.services.mozilla.com/D60768
--HG--
extra : moz-landing-system : lando
Unlike the border areas that only nead their own dimensions, the middle area of a border-image determines its repetition parameter based on the size of the borders. A new flag is provided for the brush_image shader to know whether to use the segment's own rect or look at the borders when computing the pattern's size.
Differential Revision: https://phabricator.services.mozilla.com/D59675
--HG--
extra : moz-landing-system : lando
border-image-repeat: Round is equivalent to Repeat with the pattern size adjusted to fill the area with a whole number of repetitions. This is done by adjusting the segment's stretch_size in the shader so that it fits a whole number of times in the segment's size.
Differential Revision: https://phabricator.services.mozilla.com/D59370
--HG--
extra : moz-landing-system : lando
This is done by using CreateDataSourceSurfaceWithStrideFromData to create a
DataSourceSurface and then OptimizeSourceSurface to record and optimize that.
This means that we now only have SourceSurfaceRecording using SurfaceType
RECORDING. We then rely on this to improve the test in OptimizeSourceSurface to
check that a SourceSurfaceRecording is for its recorder.
Differential Revision: https://phabricator.services.mozilla.com/D60736
--HG--
extra : moz-landing-system : lando
Second part: trace the updates that are sent to the DataStore, and save
at least the Insert/Remove and ItemUID as part of the wr-capture.
(We could expand this with more info, eg. the actual Keys, later).
TileView then reads them back and generates a color coded report to
overlay with the page view. This helps to see the types and amounts of
interned primitives that lead to cache invalidations.
Differential Revision: https://phabricator.services.mozilla.com/D60619
--HG--
extra : moz-landing-system : lando
Second part: trace the updates that are sent to the DataStore, and save
at least the Insert/Remove and ItemUID as part of the wr-capture.
(We could expand this with more info, eg. the actual Keys, later).
TileView then reads them back and generates a color coded report to
overlay with the page view. This helps to see the types and amounts of
interned primitives that lead to cache invalidations.
Differential Revision: https://phabricator.services.mozilla.com/D60619
--HG--
extra : moz-landing-system : lando
We generate ByteBuf by rust bindgen, so we can drop StyleVecU8.
One potential follow-up is that we can merge this together with WrVecU8.
Differential Revision: https://phabricator.services.mozilla.com/D60328
--HG--
rename : ipc/glue/ByteBuf.h => ipc/glue/ByteBufUtils.h
extra : moz-landing-system : lando
Though this may make us use more space when serializing
StyleTransform, but we don't have to do extra conversion on the compostior
side, and this makes us easier to maintain the Rust type.
Differential Revision: https://phabricator.services.mozilla.com/D60045
--HG--
extra : moz-landing-system : lando
The only drawback is: we resolve LengthPercentage value before passing
translate property through IPC, so its percentage part is redundant.
However, this makes us easier to maintain the Rust type.
Differential Revision: https://phabricator.services.mozilla.com/D60044
--HG--
extra : moz-landing-system : lando
This allows calling code to specify whether a primitive would prefer
to be promoted to a compositor surface and/or picture cache slice.
This is a performance hint that can be used for large external
primitives, such as videos and canvas elements.
Differential Revision: https://phabricator.services.mozilla.com/D60637
--HG--
extra : moz-landing-system : lando
We generate ByteBuf by rust bindgen, so we can drop StyleVecU8.
One potential follow-up is that we can merge this together with WrVecU8.
Differential Revision: https://phabricator.services.mozilla.com/D60328
--HG--
rename : ipc/glue/ByteBuf.h => ipc/glue/ByteBufUtils.h
extra : moz-landing-system : lando
Though this may make us use more space when serializing
StyleTransform, but we don't have to do extra conversion on the compostior
side, and this makes us easier to maintain the Rust type.
Differential Revision: https://phabricator.services.mozilla.com/D60045
--HG--
extra : moz-landing-system : lando
The only drawback is: we resolve LengthPercentage value before passing
translate property through IPC, so its percentage part is redundant.
However, this makes us easier to maintain the Rust type.
Differential Revision: https://phabricator.services.mozilla.com/D60044
--HG--
extra : moz-landing-system : lando
