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

Clip chain refactor for local picture raster support. #2951

Merged
merged 2 commits into from Aug 10, 2018

Conversation

Projects
None yet
4 participants
@gw3583
Contributor

gw3583 commented Aug 6, 2018

There's a large number of related changes in this
patch. The overall goal is to make clip chain handling
not depend on screen rectangle generation. This
will make it much easier to implement local space
picture rasterization for perspective elements. In
addition to that, we unify how user / hierarchical and
primitive clip chain nodes are handled.

Clip chain instances are built on demand now, as
required by primitives. Right now, none of the
clip chain information is cached between primitives.
In general, now that the calculations are done in
local space, they are much faster - however we can
easily start to cache the common clip-chain state
(per raster coordinate system) if it ever shows up
in a profile. Additionally, since we only build
clip chains on demand, and clip chains for non-
visible primitives are not built, which is a
decent saving on many pages.

Remove ClipNode altogether. Instead, during flattening
we map directly from a ClipId to a ClipChainId
as appropriate. Clip chains are now created during
flattening and the links remain constant. It's only
during construction of a clip chain instance that we
include and exclude parts of the specified clip
chain. This unifies how we handle user defined clip
chains and legacy hierarchical clip chains. At the
same time, unify how the optional primitive specific
complex clip is handled with clip chains. Now, if
a primitive has a complex clip, it's added as a
normal clip chain node, and linked to the parent
clip chain that this primitive would otherwise
be attached to.

Primitive runs now only depend on the spatial node.
This results in far fewer primitive run breaks.

ClipWorkItems are now stored as a single contiguous
array in the ClipStore. To achieve this they are
stored as an index buffer, and a clip node range
is simply an (index, count). These are a lot
cheaper to pass to clip masks, and also require
fewer heap allocations.

Port hit testing to use the same clip chain data
structures that the main clip code uses, now that
the hierarchical and user defined clip chains are
handled in a uniform way.

Remove the need for Arc in clip chain code, since
clip chains are now stored in a contiguous index
buffer style structure.


This change is Reviewable

@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 6, 2018

Contributor

This still needs some more work, specifically:

  • Several test failures on a try run.
  • More code comments / documentation.
  • Code tidy up.

Anecdotally it seems to be quite a bit faster on the sites I've tested against than previously, although I haven't done detailed performance numbers yet.

It's probably not quite ready for review yet, but if anyone wants to start taking a look at it, go for it 👍

Contributor

gw3583 commented Aug 6, 2018

This still needs some more work, specifically:

  • Several test failures on a try run.
  • More code comments / documentation.
  • Code tidy up.

Anecdotally it seems to be quite a bit faster on the sites I've tested against than previously, although I haven't done detailed performance numbers yet.

It's probably not quite ready for review yet, but if anyone wants to start taking a look at it, go for it 👍

@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 6, 2018

Contributor

If anyone has any general comments on the approach taken, and anything obvious missing, please let me know :)

Contributor

gw3583 commented Aug 6, 2018

If anyone has any general comments on the approach taken, and anything obvious missing, please let me know :)

@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 7, 2018

Contributor

I added some poorly drawn ASCII diagrams to try and describe how the data structures fit together (a65f564#diff-97cd013eed8f4591bd7659faf4352fd2R23).

I have fixed the test failues in wrench, and most of the test failures in gecko try.

Tomorrow I will try to resolve the remaining failures in gecko try, which are mostly 3d transform related.

Contributor

gw3583 commented Aug 7, 2018

I added some poorly drawn ASCII diagrams to try and describe how the data structures fit together (a65f564#diff-97cd013eed8f4591bd7659faf4352fd2R23).

I have fixed the test failues in wrench, and most of the test failures in gecko try.

Tomorrow I will try to resolve the remaining failures in gecko try, which are mostly 3d transform related.

There's a large number of related changes in this
patch. The overall goal is to make clip chain handling
not depend on screen rectangle generation. This
will make it much easier to implement local space
picture rasterization for perspective elements. In
addition to that, we unify how user / hierarchical and
primitive clip chain nodes are handled.

Clip chain instances are built on demand now, as
required by primitives. Right now, none of the
clip chain information is cached between primitives.
In general, now that the calculations are done in
local space, they are much faster - however we can
easily start to cache the common clip-chain state
(per raster coordinate system) if it ever shows up
in a profile. Additionally, since we only build
clip chains on demand, and clip chains for non-
visible primitives are not built, which is a
decent saving on many pages.

Remove ClipNode altogether. Instead, during flattening
we map directly from a ClipId to a ClipChainId
as appropriate. Clip chains are now created during
flattening and the links remain constant. It's only
during construction of a clip chain instance that we
include and exclude parts of the specified clip
chain. This unifies how we handle user defined clip
chains and legacy hierarchical clip chains. At the
same time, unify how the optional primitive specific
complex clip is handled with clip chains. Now, if
a primitive has a complex clip, it's added as a
normal clip chain node, and linked to the parent
clip chain that this primitive would otherwise
be attached to.

Primitive runs now only depend on the spatial node.
This results in far fewer primitive run breaks.

ClipWorkItems are now stored as a single contiguous
array in the ClipStore. To achieve this they are
stored as an index buffer, and a clip node range
is simply an (index, count). These are a lot
cheaper to pass to clip masks, and also require
fewer heap allocations.

Port hit testing to use the same clip chain data
structures that the main clip code uses, now that
the hierarchical and user defined clip chains are
handled in a uniform way.

Remove the need for Arc in clip chain code, since
clip chains are now stored in a contiguous index
buffer style structure.
@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 8, 2018

Contributor

Try run is looking very green now - just a few orange items with unrelated intermittents.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e084e4749dbb158bc76efcb504db8e10173b2e1d

r? @kvark
cc @mrobinson

Contributor

gw3583 commented Aug 8, 2018

Try run is looking very green now - just a few orange items with unrelated intermittents.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e084e4749dbb158bc76efcb504db8e10173b2e1d

r? @kvark
cc @mrobinson

@gw3583 gw3583 changed the title from [WIP] Clip chain refactor for local picture raster support. to Clip chain refactor for local picture raster support. Aug 8, 2018

@kvark

This is an amazing change. I like how the function signatures got lighter, and the forest of clip types is now easier to grasp.
Left my notes below. Major concern is naming.

Reviewed 14 of 14 files at r1.
Reviewable status: all files reviewed, 25 unresolved discussions (waiting on @gw3583)


webrender/src/clip.rs, line 29 at r1 (raw file):

 ClipStore - Main interface used by other modules.

 ClipSource - A single clip item (e.g. a rounded rect, or a box shadow).

maybe rename to ClipItem?
When I read source I imagine it being able to produce multiple things, hence the singular semantic of this is not obvious, and ClipSources causes confusion


webrender/src/clip.rs, line 48 at r1 (raw file):

       +----------------+

 ClipSourcesId - A clip sources id identifies a range of clip nodes. It is stored

maybe ClipItemRange, or even Range<ClipNodeIndex> or something like this?


webrender/src/clip.rs, line 92 at r1 (raw file):

// Result of comparing a clip node instance against a local rect.
#[derive(Debug)]
enum ClipKind {

sounds more like ClipResult


webrender/src/clip.rs, line 140 at r1 (raw file):

// node, a bounds error will occur.
impl ClipChainId {
    pub const NONE: Self = ClipChainId(u32::MAX);

we should eventually get rid of NONE and use Option<ClipChainId>, given that NonZeroU32 is stable now.


webrender/src/clip.rs, line 189 at r1 (raw file):

#[cfg_attr(feature = "capture", derive(Serialize))]
#[cfg_attr(feature = "replay", derive(Deserialize))]
pub struct ClipNodeRange {

why not just Range<ClipNodeInstanceIndex>? (not entirely clear what types are being indexed - and this should be made more clear by typedeffing this index type to a meaningful name


webrender/src/clip.rs, line 201 at r1 (raw file):

#[derive(Debug)]
enum ClipSpaceConversion {
    Local,

does this variant give us anything over Offset(0)?


webrender/src/clip.rs, line 225 at r1 (raw file):

    }

    fn transform_to_clip_space(&self, rect: &LayoutRect) -> Option<LayoutRect> {

this is confusing, given that "clip space" has a much different semantics in computer graphics
maybe transform_from_prim_space instead?


webrender/src/clip.rs, line 338 at r1 (raw file):

                }
            }
            _ => {}

nit: let's list those explicitly


webrender/src/clip.rs, line 356 at r1 (raw file):

    pub clips_range: ClipNodeRange,
    pub local_clip_rect: LayoutRect,
    pub has_clips_from_other_coordinate_systems: bool,

would it make sense to use ClipNodeFlags here?


webrender/src/clip.rs, line 401 at r1 (raw file):

                }
            })
            .collect();

this collection is not needed.


webrender/src/clip.rs, line 490 at r1 (raw file):

                    Some(ClipSpaceConversion::Offset(offset))
                } else {
                    // TODO(gw): We still have issues with clip nodes and primitives wher

typo "wher"


webrender/src/clip.rs, line 491 at r1 (raw file):

                } else {
                    // TODO(gw): We still have issues with clip nodes and primitives wher
                    //           there is perspective occurring. We intend to fix these

perspective transform?


webrender/src/clip.rs, line 524 at r1 (raw file):

                            if spatial_node_index == clip_node.spatial_node_index ||
                               ref_spatial_node.coordinate_system_id == clip_spatial_node.coordinate_system_id {

the second condition could shadow the first one (i.e the first one seems unnecessary)


webrender/src/clip.rs, line 528 at r1 (raw file):

                                    Some(new_local_clip_rect) => new_local_clip_rect,
                                    None => {
                                        return None

we'll need to route the chasing logic here (as a followup by me, presumably)


webrender/src/clip.rs, line 587 at r1 (raw file):

                        // building logic.
                        let flags = match node_info.conversion {
                            ClipSpaceConversion::Local => {

interesting, so Local is useful here


webrender/src/clip.rs, line 880 at r1 (raw file):

    // used to eliminate redundant clips, and reduce the size of
    // any clip mask that eventually gets drawn.
    fn get_local_clip_rect(&self) -> Option<LayoutRect> {

that function is so nice, can't get my eyes off it :)


webrender/src/clip.rs, line 904 at r1 (raw file):

                }

                match clip_rect.intersection(prim_rect) {

nit: could also contain the intersection with prim_rect itself instead of checking for contains_rect earlier?


webrender/src/clip.rs, line 918 at r1 (raw file):

                }

                match clip_rect.intersection(prim_rect) {

nit: might be tidier to do match (clip_mode, clip_rect.intersection(prim_rect))
just as an idea


webrender/src/clip.rs, line 932 at r1 (raw file):

                // TODO(gw): extract_inner_rect_safe is overly
                //           conservative for this code!
                let inner_clip_rect = extract_inner_rect_safe(clip_rect, radius);

iirc, it's fairly fast


webrender/src/display_list_flattener.rs, line 759 at r1 (raw file):

        clip_sources: Vec<ClipSource>,
        spatial_node_index: SpatialNodeIndex,
        default_clip_chain_id: ClipChainId,

shouldn't it be called parent_clip_chain_id?


webrender/src/display_list_flattener.rs, line 1284 at r1 (raw file):

        I: IntoIterator<Item = ComplexClipRegion>
    {
        // Add a new ClipNode - this is a ClipId that identifies a list of clip sources,

let me get this straight: so, add_clip_node returns a ClpChainId that is actually a ClipId that identifies xxxx
Either the comment or the signature need to be updated so that it's more clear


webrender/src/display_list_flattener.rs, line 1291 at r1 (raw file):

            .id_to_index_mapper
            .get_clip_chain_id(&parent_id);
        // Map the ClipId for the positioning node to a spatial node index.

uh, we need to completely split ClipId and positional information, eventually


webrender/src/display_list_flattener.rs, line 1295 at r1 (raw file):

        // Build the clip sources from the supplied region.
        // TODO(gw): We should fix this up to take advantage of the recent

I'll clean this up


webrender/src/hit_test.rs, line 78 at r1 (raw file):

enum HitTestRegion {
    Invalid,

does it make sense versus passing Result<HitTestRegion, SomeError> where appropriate?


webrender/src/hit_test.rs, line 152 at r1 (raw file):

        for clip_chain in &clip_store.clip_chain_nodes {
            self.clip_chains.push(clip_chain.clone());

nit: self.clip_chains.extend_from_slice(&clip_store.clip_chain_nodes)

@gw3583

Reviewable status: all files reviewed, 23 unresolved discussions (waiting on @kvark and @gw3583)


webrender/src/clip.rs, line 29 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

maybe rename to ClipItem?
When I read source I imagine it being able to produce multiple things, hence the singular semantic of this is not obvious, and ClipSources causes confusion

Done.


webrender/src/clip.rs, line 48 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

maybe ClipItemRange, or even Range<ClipNodeIndex> or something like this?

Done.


webrender/src/clip.rs, line 92 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

sounds more like ClipResult

Done.


webrender/src/clip.rs, line 140 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

we should eventually get rid of NONE and use Option<ClipChainId>, given that NonZeroU32 is stable now.

Agreed.


webrender/src/clip.rs, line 189 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

why not just Range<ClipNodeInstanceIndex>? (not entirely clear what types are being indexed - and this should be made more clear by typedeffing this index type to a meaningful name

I tried this locally - but it seems a bit unwieldy. The lack of is_empty() on stable and the way we use the count field here makes the code seem a bit tidier with a custom range, I think.


webrender/src/clip.rs, line 201 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

does this variant give us anything over Offset(0)?

A (perhaps small) performance optimization - no translate / offsetting required in these cases, which is probably quite a common use case.


webrender/src/clip.rs, line 225 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

this is confusing, given that "clip space" has a much different semantics in computer graphics
maybe transform_from_prim_space instead?

Done.


webrender/src/clip.rs, line 338 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

nit: let's list those explicitly

Done


webrender/src/clip.rs, line 356 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

would it make sense to use ClipNodeFlags here?

I hadn't for now, to minimize changes to the segmenting code in this patch. But it could make sense to do this as a follow up, yep.


webrender/src/clip.rs, line 401 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

this collection is not needed.

Done.


webrender/src/clip.rs, line 490 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

typo "wher"

Done.


webrender/src/clip.rs, line 491 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

perspective transform?

Done.


webrender/src/clip.rs, line 524 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

the second condition could shadow the first one (i.e the first one seems unnecessary)

Done.


webrender/src/clip.rs, line 528 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

we'll need to route the chasing logic here (as a followup by me, presumably)

Sure, if you're happy to do that 👍


webrender/src/clip.rs, line 587 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

interesting, so Local is useful here

Yep - because Local means that the offsets between the clip and the primitive cannot change due to scrolling.


webrender/src/clip.rs, line 880 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

that function is so nice, can't get my eyes off it :)

🥇


webrender/src/clip.rs, line 904 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

nit: could also contain the intersection with prim_rect itself instead of checking for contains_rect earlier?

Yea - I was thinking that since contains_rect is cheaper, and perhaps the common path, it might be slightly faster. But we should profile as a follow up and see which is actually more common.


webrender/src/clip.rs, line 918 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

nit: might be tidier to do match (clip_mode, clip_rect.intersection(prim_rect))
just as an idea

I think this would probably make sense if we do the contains_rect suggestion above, based on some profiling.


webrender/src/clip.rs, line 932 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

iirc, it's fairly fast

Yea, I expect it will be fine too.


webrender/src/display_list_flattener.rs, line 759 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

shouldn't it be called parent_clip_chain_id?

Done.


webrender/src/display_list_flattener.rs, line 1284 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

let me get this straight: so, add_clip_node returns a ClpChainId that is actually a ClipId that identifies xxxx
Either the comment or the signature need to be updated so that it's more clear

Yea - Martin and I had discussed that we would like to tidy up the public API here and make it explicit, but we agreed to leave this for now, until there's a better time for Gecko to make those API changes.


webrender/src/display_list_flattener.rs, line 1291 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

uh, we need to completely split ClipId and positional information, eventually

Yep - see above comment :)


webrender/src/display_list_flattener.rs, line 1295 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

I'll clean this up

👍


webrender/src/hit_test.rs, line 78 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

does it make sense versus passing Result<HitTestRegion, SomeError> where appropriate?

Perhaps, I don't think it matters too much either way.


webrender/src/hit_test.rs, line 152 at r1 (raw file):

Previously, kvark (Dzmitry Malyshau) wrote…

nit: self.clip_chains.extend_from_slice(&clip_store.clip_chain_nodes)

Done

@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 9, 2018

Contributor

@kvark Thanks for the review! Those naming suggestions are much better than I had 👍

Contributor

gw3583 commented Aug 9, 2018

@kvark Thanks for the review! Those naming suggestions are much better than I had 👍

@kvark

kvark approved these changes Aug 9, 2018

:lgtm_strong:

Reviewed 7 of 7 files at r2.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved

@kvark

This comment has been minimized.

Show comment
Hide comment
@kvark
Member

kvark commented Aug 9, 2018

@bors-servo

This comment has been minimized.

Show comment
Hide comment
@bors-servo

bors-servo Aug 9, 2018

Contributor

📌 Commit 6f0d49a has been approved by kvark

Contributor

bors-servo commented Aug 9, 2018

📌 Commit 6f0d49a has been approved by kvark

@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 9, 2018

Contributor

Once this lands we should be on the lookout for any regressions in number of clip masks we draw, or any hit-test issues. I wouldn't be surprised to have a few issues like that which need to be fixed up 😨

Contributor

gw3583 commented Aug 9, 2018

Once this lands we should be on the lookout for any regressions in number of clip masks we draw, or any hit-test issues. I wouldn't be surprised to have a few issues like that which need to be fixed up 😨

@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 10, 2018

Contributor

@bors-servo r=kvark

(is bors stuck?)

Contributor

gw3583 commented Aug 10, 2018

@bors-servo r=kvark

(is bors stuck?)

@bors-servo

This comment has been minimized.

Show comment
Hide comment
@bors-servo

bors-servo Aug 10, 2018

Contributor

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

  • There's another pull request that is currently being tested, blocking this pull request: #2919
Contributor

bors-servo commented Aug 10, 2018

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

  • There's another pull request that is currently being tested, blocking this pull request: #2919
@bors-servo

This comment has been minimized.

Show comment
Hide comment
@bors-servo

bors-servo Aug 10, 2018

Contributor

📌 Commit 6f0d49a has been approved by kvark

Contributor

bors-servo commented Aug 10, 2018

📌 Commit 6f0d49a has been approved by kvark

@bors-servo

This comment has been minimized.

Show comment
Hide comment
@bors-servo

bors-servo Aug 10, 2018

Contributor

⌛️ Testing commit 6f0d49a with merge bc53a83...

Contributor

bors-servo commented Aug 10, 2018

⌛️ Testing commit 6f0d49a with merge bc53a83...

bors-servo added a commit that referenced this pull request Aug 10, 2018

Auto merge of #2951 - gw3583:local-clips-prep2, r=kvark
Clip chain refactor for local picture raster support.

There's a large number of related changes in this
patch. The overall goal is to make clip chain handling
not depend on screen rectangle generation. This
will make it much easier to implement local space
picture rasterization for perspective elements. In
addition to that, we unify how user / hierarchical and
primitive clip chain nodes are handled.

Clip chain instances are built on demand now, as
required by primitives. Right now, none of the
clip chain information is cached between primitives.
In general, now that the calculations are done in
local space, they are much faster - however we can
easily start to cache the common clip-chain state
(per raster coordinate system) if it ever shows up
in a profile. Additionally, since we only build
clip chains on demand, and clip chains for non-
visible primitives are not built, which is a
decent saving on many pages.

Remove ClipNode altogether. Instead, during flattening
we map directly from a ClipId to a ClipChainId
as appropriate. Clip chains are now created during
flattening and the links remain constant. It's only
during construction of a clip chain instance that we
include and exclude parts of the specified clip
chain. This unifies how we handle user defined clip
chains and legacy hierarchical clip chains. At the
same time, unify how the optional primitive specific
complex clip is handled with clip chains. Now, if
a primitive has a complex clip, it's added as a
normal clip chain node, and linked to the parent
clip chain that this primitive would otherwise
be attached to.

Primitive runs now only depend on the spatial node.
This results in far fewer primitive run breaks.

ClipWorkItems are now stored as a single contiguous
array in the ClipStore. To achieve this they are
stored as an index buffer, and a clip node range
is simply an (index, count). These are a lot
cheaper to pass to clip masks, and also require
fewer heap allocations.

Port hit testing to use the same clip chain data
structures that the main clip code uses, now that
the hierarchical and user defined clip chains are
handled in a uniform way.

Remove the need for Arc in clip chain code, since
clip chains are now stored in a contiguous index
buffer style structure.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/2951)
<!-- Reviewable:end -->
@bors-servo

This comment has been minimized.

Show comment
Hide comment
@bors-servo

bors-servo Aug 10, 2018

Contributor

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: kvark
Pushing bc53a83 to master...

Contributor

bors-servo commented Aug 10, 2018

☀️ Test successful - status-appveyor, status-taskcluster
Approved by: kvark
Pushing bc53a83 to master...

@bors-servo bors-servo merged commit 6f0d49a into servo:master Aug 10, 2018

4 checks passed

Taskcluster (pull_request) TaskGroup: success
Details
code-review/reviewable 15 files reviewed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
homu Test successful
Details
@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 10, 2018

Contributor

Hmmm, on subsequent tries I'm seeing failures, but when I revert those back to this patch, I'm still seeing the same failures - but those same failures were not occurring on the try run above. 😕 Investigating now...

Contributor

gw3583 commented Aug 10, 2018

Hmmm, on subsequent tries I'm seeing failures, but when I revert those back to this patch, I'm still seeing the same failures - but those same failures were not occurring on the try run above. 😕 Investigating now...

@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 10, 2018

Contributor

Hmm, and it's actually a single test that is showing up in multiple places due to being run on each platform - transform-3d/1035611-1.html.

Contributor

gw3583 commented Aug 10, 2018

Hmm, and it's actually a single test that is showing up in multiple places due to being run on each platform - transform-3d/1035611-1.html.

@gw3583

This comment has been minimized.

Show comment
Hide comment
@gw3583

gw3583 Aug 10, 2018

Contributor

Oh, I think I see what has happened. Ugh.

  • #2947 fixed 1035611-1.html and made it pass.
  • This patch re-breaks that test.
  • My try run above was on m-c before the WR update landed, and so didn't have updated reftest annotations.

Investigating now to see why this patch breaks that test.

Contributor

gw3583 commented Aug 10, 2018

Oh, I think I see what has happened. Ugh.

  • #2947 fixed 1035611-1.html and made it pass.
  • This patch re-breaks that test.
  • My try run above was on m-c before the WR update landed, and so didn't have updated reftest annotations.

Investigating now to see why this patch breaks that test.

@gw3583 gw3583 deleted the gw3583:local-clips-prep2 branch Aug 10, 2018

@sotaroikeda

This comment has been minimized.

Show comment
Hide comment
@sotaroikeda

sotaroikeda Aug 20, 2018

Contributor

By Bug 1483610 Comment 5, the change might cause huge gecko performance regression.

Contributor

sotaroikeda commented Aug 20, 2018

By Bug 1483610 Comment 5, the change might cause huge gecko performance regression.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment