Closed Bug 1073209 Opened 10 years ago Closed 1 year ago

Eliminate usage of CreateSamplingRestrictedDrawable

Categories

(Core :: Graphics, defect, P3)

x86
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jrmuizel, Assigned: mchang)

References

(Blocks 1 open bug)

Details

(Whiteboard: gfx-noted)

Attachments

(8 files, 4 obsolete files)

9.91 KB, patch
mchang
: review+
Details | Diff | Splinter Review
4.82 KB, patch
jrmuizel
: review+
Details | Diff | Splinter Review
9.82 KB, patch
Details | Diff | Splinter Review
758.56 KB, application/zip
Details
6.50 KB, patch
Details | Diff | Splinter Review
44.35 KB, image/png
Details
14.38 KB, image/png
Details
11.67 KB, patch
jrmuizel
: review+
Details | Diff | Splinter Review
The plan is to add separate control for repeat in x and y directions and just leak when the destination is tiled in particular direction. This should give us behaviour that's at least as good as the other browsers and much faster.

- D2D and Skia both support separate repeat control.
- Cairo only supports repeat in both directions, so we'll probably just choose to leak. (This matches the behaviour of WebKit on Cairo)
- CoreGraphics doesn't support repeat at all. Our current implementation of repeat on top of drawImage will probably suffice because it doesn't ever leak.
Blocks: 902639, 970311
Depends on: 1074907
Assignee: nobody → mchang
Blocks: paint-fast
Status: NEW → ASSIGNED
Whiteboard: gfx-noted
Here are some tests at the bottom of this page that demonstrate the different behaviours:
http://people.mozilla.org/~jmuizelaar/implementation-tests/background-interpolation/test.html
Blocks: 1155249
No longer blocks: 902639
Attachment #8594051 - Flags: review?(jmuizelaar)
Comment on attachment 8594051 [details] [diff] [review]
Disable CreateSamplingRestrictedDrawable on OS X

This is beautiful!
Attachment #8594051 - Flags: review?(jmuizelaar) → review+
Attachment #8594051 - Attachment is patch: true
Carrying r+, updated with some nits to pass try.

https://hg.mozilla.org/integration/mozilla-inbound/rev/2d97da8feb72
Attachment #8594051 - Attachment is obsolete: true
Attachment #8594801 - Flags: review+
Depends on: 1156454
FWIW, since IE doesn't bother to restrict repeat sampling in only one axis and that mode is not supported in Cairo I don't think we should block this bug on adding support for one axis repeating.
Try with deleting CreateSamplingRestrictedDrawable across platforms - https://treeherder.mozilla.org/#/jobs?repo=try&revision=7ab49ce70ba5

I'll take a look at the reftest failures and changing reftests.list to get it green.
I think I have some kind of idea what's going on. We have 5 test cases that break with deleting CSRD everywhere. Reftest lost:

http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-7ab49ce70ba5/try-win64/try_win8_64_test-reftest-no-accel-bm119-tests1-windows-build470.txt.gz&only_show_unexpected=1

Each test:
== layout/reftests/backgrounds/background-size-zoom-repeat.html 

This is the original test with the blue/green columns and black borders between the columns. It looks like even though we don't use CSRD, the test will still fail with sampling between the repeated images, which has the same output as IE. I think this is because when we draw a repeated image [1], we still use linear interpolation D2D1_INTERPOLATION_MODE_LINEAR [2], which I think does bilinear sampling from both the X and Y axis. This results in the blurred gradient between blue / green during scaling. I think this is the expected result.

What I think I'm confused about though is when do we sampling versus using WRAP extend mode[3]. If we repeat with the wrap mode, I would've expected us to just paste the image without any sampling at the edges. So I think this must mean we scale and sample first, then repeat in WRAP mode?

== border-image/center-scaling-2.html
== border-image/center-scaling-3.html

These tests are kind of confusing. I don't really understand why we have the little gray spots on the outer edges of the black bars. A 27x27 border-image should contain a small pixel of gray from all 4 sides, top, right, left, and bottom as the original image is 81x81. The corners should not have any gray pieces from the border-image-slice. Since the artifacts only occur on the Y axis, the border-width scales the image from 27x27 to 54x54 due to the border-width, which does linear interpolation during drawing. So for example, on the left Y axis, I would expect sampling artifacts from scaling only on the right side of the left axis. I'm confused as to why there is a single gray spot on the left of the left Y axis and to the right of the right Y axis. Do you have any idea?

== reftest/tests/layout/reftests/bugs/446100-1e.html
== layout/reftests/image/background-image-zoom-2.html

I can't reproduce these locally. Any ideas why this would occur on try but not locally? I tried on both a Cairo and d2d 11 backend. Does it depend on the resolution of the attached display to choose sampling rects?

Thanks!

[1] https://dxr.mozilla.org/mozilla-central/source/gfx/2d/DrawTargetD2D1.cpp?from=DrawTargetD2D1.cpp&case=true#1317
[2] https://msdn.microsoft.com/en-us/library/windows/desktop/hh447004%28v=vs.85%29.aspx
[3] https://msdn.microsoft.com/en-us/library/windows/desktop/hh706314%28v=vs.85%29.aspx
Flags: needinfo?(jmuizelaar)
Will file a part 3 with the correct reftest.list changes after a successful try.
Attachment #8595669 - Flags: review?(jmuizelaar)
(In reply to Mason Chang [:mchang] from comment #10)
> I think I have some kind of idea what's going on. We have 5 test cases that
> break with deleting CSRD everywhere. Reftest lost:
> 
> http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/
> reftest-analyzer.xhtml#logurl=http://ftp.mozilla.org/pub/mozilla.org/firefox/
> try-builds/mchang@mozilla.com-7ab49ce70ba5/try-win64/try_win8_64_test-
> reftest-no-accel-bm119-tests1-windows-build470.txt.gz&only_show_unexpected=1
> 
> Each test:
> == layout/reftests/backgrounds/background-size-zoom-repeat.html 
> 
> This is the original test with the blue/green columns and black borders
> between the columns. It looks like even though we don't use CSRD, the test
> will still fail with sampling between the repeated images, which has the
> same output as IE. I think this is because when we draw a repeated image
> [1], we still use linear interpolation D2D1_INTERPOLATION_MODE_LINEAR [2],
> which I think does bilinear sampling from both the X and Y axis. This
> results in the blurred gradient between blue / green during scaling. I think
> this is the expected result.
> 
> What I think I'm confused about though is when do we sampling versus using
> WRAP extend mode[3]. If we repeat with the wrap mode, I would've expected us
> to just paste the image without any sampling at the edges. So I think this
> must mean we scale and sample first, then repeat in WRAP mode?

When bilinear sampling each destination pixel will map to a source point.
The source point than samples from the nearest 4 pixels. This is when the wrapping happens.
These samples are then interpolated between.

> 
> == border-image/center-scaling-2.html
> == border-image/center-scaling-3.html
> 
> These tests are kind of confusing. I don't really understand why we have the
> little gray spots on the outer edges of the black bars. A 27x27 border-image
> should contain a small pixel of gray from all 4 sides, top, right, left, and
> bottom as the original image is 81x81. The corners should not have any gray
> pieces from the border-image-slice. Since the artifacts only occur on the Y
> axis, the border-width scales the image from 27x27 to 54x54 due to the
> border-width, which does linear interpolation during drawing. So for
> example, on the left Y axis, I would expect sampling artifacts from scaling
> only on the right side of the left axis. I'm confused as to why there is a
> single gray spot on the left of the left Y axis and to the right of the
> right Y axis. Do you have any idea?

I'll look at this tomorrow.

> 
> == reftest/tests/layout/reftests/bugs/446100-1e.html
> == layout/reftests/image/background-image-zoom-2.html
> 
> I can't reproduce these locally. Any ideas why this would occur on try but
> not locally? I tried on both a Cairo and d2d 11 backend. Does it depend on
> the resolution of the attached display to choose sampling rects?

These test use the reftest-zoom feature. You may be able to reproduce if you adjust the zoom in the browser.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)
> > 
> > These tests are kind of confusing. I don't really understand why we have the
> > little gray spots on the outer edges of the black bars. A 27x27 border-image
> > should contain a small pixel of gray from all 4 sides, top, right, left, and
> > bottom as the original image is 81x81. The corners should not have any gray
> > pieces from the border-image-slice. Since the artifacts only occur on the Y
> > axis, the border-width scales the image from 27x27 to 54x54 due to the
> > border-width, which does linear interpolation during drawing. So for
> > example, on the left Y axis, I would expect sampling artifacts from scaling
> > only on the right side of the left axis. I'm confused as to why there is a
> > single gray spot on the left of the left Y axis and to the right of the
> > right Y axis. Do you have any idea?
>

The artifacts here seem like they are caused by us using repeat sampling when we wouldn't before. This is probably not great and we're going to have to come up with a justification as to why we can accept them. What does IE show on these cases?
Flags: needinfo?(jmuizelaar)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #13)

> The artifacts here seem like they are caused by us using repeat sampling
> when we wouldn't before. This is probably not great and we're going to have
> to come up with a justification as to why we can accept them. What does IE
> show on these cases?

IE seems to get this correct. Chrome seems to get it wrong.
So we figured out what IE does. It does a scaled draw to subset the source image, then it manually repeats the scaled source subset in device space with a quad for each repeat.

They have subsetting artifacts but those are less objectionable then repeating artifacts that we have.
Depends on: 1160264
Comment on attachment 8595669 [details] [diff] [review]
Part 2: Delete CreateSamplingRestrictedDrawable on all platforms

The artifacts that this gives us are present in Chrome as well. I filed bug 1160264 about doing better, but let's not wait.
Attachment #8595669 - Flags: review?(jmuizelaar) → review+
Comment on attachment 8601777 [details] [diff] [review]
Part 3: Change reftests to accomdate deletion of CreateSamplingRestrictedDrawable

Review of attachment 8601777 [details] [diff] [review]:
-----------------------------------------------------------------

As painful as it is it might be better to not change == to !=. I think we still want to consider the tests aspirational.

::: layout/reftests/border-image/reftest.list
@@ +17,5 @@
>  != different-h-v-2.html different-h-v-ref.html
>  != different-h-v-1.html different-h-v-2.html
>  == center-scaling-1.html center-scaling-1-ref.html
> +fails-if(Android||B2G||supportsRepeatResampling) == center-scaling-2.html center-scaling-2-ref.html # Android/B2G: very different scaling (blurriness) on some sides
> +fails-if(Android||B2G||supportsRepeatResampling) == center-scaling-3.html center-scaling-3-ref.html # Android/B2G: very different scaling (blurriness) on some sides

This can probably just be fails-if(supportsRepeatResampling). I'm pretty sure that's the reason Android and B2G fail

::: layout/reftests/bugs/reftest.list
@@ +816,5 @@
>  == 395130-2.html 395130-2-ref.html
>  skip-if((B2G&&browserIsRemote)||Mulet) == 395331-1.xml 395331-1-ref.xml # bug 974780 # Initial mulet triage: parity with B2G/B2G Desktop
>  == 395390-1.html 395390-1-ref.html
>  == 396286-1.html about:blank  # crash test
> +fuzzy-if(Android,6,140) == 397428-1.html 397428-1-ref.html # Bug 1073209 create resampling restricted drawable deleted

We're already skipping CSRD on Android so I'm confused why this would change.

::: layout/reftests/image-element/reftest.list
@@ +17,5 @@
>  == element-paint-background-size-02.html element-paint-background-size-02-ref.html
>  == element-paint-transform-repeated.html element-paint-transform-repeated-ref.html
>  fuzzy-if(d2d,255,24) == element-paint-transform-03.html element-paint-transform-03-ref.html
>  == element-paint-native-widget.html element-paint-native-widget-ref.html
> +fails-if(Android||B2G) != element-paint-subimage-sampling-restriction.html about:blank

Changing the condition here is probably the wrong thing to do...
Attachment #8601777 - Flags: review?(jmuizelaar) → review-
Depends on: 1162371
Recent try https://treeherder.mozilla.org/#/jobs?repo=try&revision=f89900d9044d

I think the b2g R6 reftest failures are an existing intermittent that we just happen to trigger without CSRD, same with Android. 

Also changed supportsRepeatResampling to be all platforms but OS X, Android, and B2G since Android and B2G shouldn't have gone through the CSRD path before.
Attachment #8601777 - Attachment is obsolete: true
Attachment #8602782 - Flags: review?(jmuizelaar)
Comment on attachment 8602782 [details] [diff] [review]
Part 3: Change reftests to accomdate deletion of CreateSamplingRestrictedDrawable

Review of attachment 8602782 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/tools/reftest/reftest.js
@@ +755,5 @@
>          gDumpedConditionSandbox = true;
>      }
>  
>      // Graphics features
> +    sandbox.supportsRepeatResampling = !sandbox.cocoaWidget && !sandbox.B2G && !sandbox.Android;

This is wrong. B2G and Andorid both support repeat sampling.
Attachment #8602782 - Flags: review?(jmuizelaar) → review-
Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a6d22b111f75

(In reply to Jeff Muizelaar [:jrmuizel] from comment #20)
> This is wrong. B2G and Andorid both support repeat sampling.

Hmm when I tried the test page from comment 1 without CSRD, the output looked the same as Mac, so I thought there wasn't any repeat resampling.
Attachment #8602782 - Attachment is obsolete: true
Attachment #8603435 - Flags: review?(jmuizelaar)
Depends on: 1164601
Comment on attachment 8603435 [details] [diff] [review]
Part 3: Change reftests to accomdate deletion of CreateSamplingRestrictedDrawable

CSRD got somewhat backed out. We need to re-evaluate.
Attachment #8603435 - Flags: review?(jmuizelaar)
Attached file Test case for CSRD
Using this test case to investigate the performance regressions reported by :tn.

Just some rough benchmarks. Loading this page w/o e10s on a macbook pro. Benchmarked by resetting the zoom with command-0. Zoom 1 means pushing command+ once to zoom in 1 size. Zoom 2 means pushing command + to zoom in again.

Out 1 means going back to the reset zoom, zooming out via command- once. Out 2 means zooming out one more level.

Default w/ CSRD as in master today:
Zoom 1: ~23 ms.
Zoom 2: ~20.5 ms
Out 1: ~24 ms
Out 2: ~29 ms

Deleting CSRD:
Zoom 1: ~26 ms - ~13% slower
Zoom 2: ~28 ms - ~33% slower
Out 1: ~26 ms - ~8% slower
Out 2: ~29 ms 

Deleting CSRD + Bug 1154311 - Use CGContextDrawTiledImage
Zoom 1: ~26 ms - 13% slower 
Zoom 2: ~31 ms - 51% slower
Out 1: ~24 ms - ~equal
Out 2: 31 ms - ~7% slower

Not really sure why, but seems like deleting CSRD does show a regression. Deleting CSRD + using CGContextDrawTiledImage is even slower. Investigating.
Also includes bug 1154311 and CSRD is commented out in this.
Uhm, in the CSRD case you don't actually include the creation of the CSRD in your timings.
(In reply to Markus Stange [:mstange] from comment #26)
> Uhm, in the CSRD case you don't actually include the creation of the CSRD in
> your timings.

That's just in the patch. I added the CSRD timings + drawable timings by hand for the measurements in comment 24.
Oh ok.
I dug into this a bit more. We FillRect through DrawTargetTiled, which calls DrawTargetCG::FillRect. Each call to FillRect, with CSRD, takes roughly ~0.4ms to draw the specific tile. With the default 256x256 default tile size, we call FillRect 63 times in a 15" retina macbook pro. So essentially, we spend a short amount of time, but many times over, to draw the background image. The CSRD path goes through [1].

Without CSRD, the time spent is actually an interesting curve. The first call is pretty expensive, up to 1 ms, which goes through [2]. Each successive call to DrawTargetCG::FillRect gets a little cheaper, eventually reducing down to ~0.3 ms. However, the total time spent is still more than with CSRD.

IIRC, Safari is able to draw the background image in one pass versus we break it up into tiles. The proper solution to this was to give images their own layer in bug 1121770.

Will repost with some numbers on Windows as well.

[1] https://dxr.mozilla.org/mozilla-central/source/gfx/2d/DrawTargetCG.cpp?from=DrawTargetCG.cpp&case=true#994
[2] https://dxr.mozilla.org/mozilla-central/source/gfx/2d/DrawTargetCG.cpp?from=DrawTargetCG.cpp&case=true#998
(In reply to Mason Chang [:mchang] from comment #29)
> The proper solution to this was to give images their
> own layer in bug 1121770.

I still disagree. We don't want to cause component alpha layers for all content on top of the background.
So, in summary, CSRD is faster because we're scaling only once, and without CSRD we're scaling for each tile we draw to. Right?
(In reply to Mason Chang [:mchang] from comment #29)
> IIRC, Safari is able to draw the background image in one pass versus we
> break it up into tiles. The proper solution to this was to give images their
> own layer in bug 1121770.

This doesn't match my understanding of what Safari does. Safari should just be use CGContextDrawTiledImage.
(In reply to Jeff Muizelaar [:jrmuizel] from comment #32)
> (In reply to Mason Chang [:mchang] from comment #29)
> > IIRC, Safari is able to draw the background image in one pass versus we
> > break it up into tiles. The proper solution to this was to give images their
> > own layer in bug 1121770.
> 
> This doesn't match my understanding of what Safari does. Safari should just
> be use CGContextDrawTiledImage.

I thought Safari had larger tiles and used CGContextDrawTiledImage to draw the whole background region in one pass either to the larger tile or to the actual background size. Or did I misunderstand that?
(In reply to Markus Stange [:mstange] from comment #31)
> So, in summary, CSRD is faster because we're scaling only once, and without
> CSRD we're scaling for each tile we draw to. Right?

This was wrong. With CSRD we also scale for every tile. The stuff inside the SRD isn't scaled.
I can't quite recreate this test case on Windows. CSRD isn't being invoked, neither is the gfxUtils::DrawPixelSnapped when zooming in / out. I can sometimes get 20+ ms if I refresh the page, but the numbers aren't very consistent. Most of the time, the time spent in gfxDrawable->Draw() on Windows is less than 1 ms.
(In reply to Mason Chang [:mchang] from comment #24)
> Created attachment 8631942 [details]
> Test case for CSRD
> 

We figured out what is happening here. When we don't use CSRD we end up going to down the repeat path in DrawTargetCG. This path is slower because it creates a cached copy of the tile, it seems like it may also create a mask to draw through. Ultimately, this means we're best suited to fix this by doing the work of bug 1155249. This means we can skip some of the badness that's going on in CoreGraphics.
Looks like this is pretty slow on Windows while scrolling twitter.com:

http://people.mozilla.org/~bgirard/cleopatra/#report=8582a7273520ae3b7e5b22d49adc4fed67a1e133
(In reply to Mason Chang [:mchang] from comment #37)
> Looks like this is pretty slow on Windows while scrolling twitter.com:
> 
> http://people.mozilla.org/~bgirard/cleopatra/
> #report=8582a7273520ae3b7e5b22d49adc4fed67a1e133

That profile shows a lot of texture creation (which is bad and should be fixed) but I don't see CreateSampingRestrictedDrawable.
CSRD failing on Windows

http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mchang@mozilla.com-ece78c843c07/try-win32-debug/try_xp-ix-debug_test-reftest-bm112-tests1-windows-build963.txt.gz&only_show_unexpected=1

center-scaling-2
center-scaling-3
// ok to accept these artifacts from comment 15 and 16

421885-1.xml - marked fail on OS X
446100-1a - marked fail on OS X
446100-1b - marked fail on OS X
446100-1c - marked fail on OS X
446100-1d - marked fail on OS X
446100-1e - New on Windows, not failing on OS X
446100-1g - marked fail on OS X
elementpaint-subimage-sampling-restriction - marked failing on OS X
background-image-zoom-2 - New on Windows, not failing on OS X

New ones on Windows are:
446100-1e
background-image-zoom-2 - IE has the same background artifacts. Chrome does something interesting. It shows the artifacts for a second, then they go away, like it's been repainted.

Investigating the two new ones on Windows.
Some perf measurements on our favorite test case. Zooming in, I don't see much of a difference on Windows 7 in terms of performance. Zooming out though:

Without CSRD Zooming out
Scale: 0.895522, 0.895522
Post CSRD drawable time: 0.010923

Scale: 0.999653, 0.999963
Post CSRD drawable time: 0.011264

Scale: 0.893023, 0.893300
Post CSRD drawable time: 0.023552

Scale: 0.833333, 0.833333
Post CSRD drawable time: 0.012629

Scale: 0.750000, 0.750000
Post CSRD drawable time: 0.012971

Scale: 0.600000, 0.600000
Post CSRD drawable time: 0.007851


With CSRD + Drawable + Zooming out
Shumway is registered
Scale: 0.895522, 0.895522
CSRD time: 0.616442
Post CSRD drawable time: 0.009216

Scale: 0.999653, 0.999963
CSRD time: 0.290472
Post CSRD drawable time: 0.010240

Scale: 0.893023, 0.893300
CSRD time: 0.229374
Post CSRD drawable time: 0.005461

Scale: 0.833333, 0.833333
CSRD time: 0.356007
Post CSRD drawable time: 0.006144

Scale: 0.750000, 0.750000
CSRD time: 31.293477
Post CSRD drawable time: 0.011605

Scale: 0.600000, 0.600000
CSRD time: 45.041226
Post CSRD drawable time: 1.011264

Go from 46 ms at the 0.6 scale mark to < 0.01 ms. Impressive gains.
Profile zooming out:

http://people.mozilla.org/~bgirard/cleopatra/#report=51afc551503fad6b5e1cae34137fe24966a30399

Looks like the expensive part is taking a snapshot of the draw target when we use CSRD as it incurs a flush.
I've been unable to reproduce any artifacts for the 446100-1e.html test case on 3 Windows 7 machine configurations: Two native, one with remote desktop. The only place I can reproduce artifacts is on Windows 8 running on Vmware Fusion on my mac. Stock nightly with CSRD does not have artifacts whereas Nightly w/o CSRD does. However, both Chrome and IE have artifacts in this configuration as well. Attached are the chrome artifacts. Nightly w/o CSRD is equivalent to Chrome artifacts, which is still different than what we're getting on try.
Attached patch Stop using CSRD on Windows (obsolete) — Splinter Review
Removes CSRD usage on Windows:

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=346cd68aa4ae

The two reftest failure cases are 446100-1e.html and background-image-zoom-2. For 446100-1e, I've been unable to reproduce this on an Intel HD 4600, Nvidia Quadro K600, and Intel HD 5000. I can only reproduce this on a VM and all browsers in this configuration show artifacts from comments 42 and 43.

For background-image-zoom2, IE always shows artifacts and Chrome looks like it does something like CSRD after the initial painting. Chrome shows artifacts, then after a second or two, they go away. 

We currently show these artifacts because with CSRD, we round out the needed rect to pixel aligned rects, whereas without CSRD, we paint the original rect which isn't pixel aligned when zoomed in, hence the artifacts. From comment 16, due to the perf improvements and only two new reftest failures, can we try landing this now?
Attachment #8641754 - Flags: review?(jmuizelaar)
Comment on attachment 8641754 [details] [diff] [review]
Stop using CSRD on Windows

Review of attachment 8641754 [details] [diff] [review]:
-----------------------------------------------------------------

Let's only switch this for D2D in this commit.

::: gfx/thebes/gfxUtils.cpp
@@ +399,5 @@
>   */
>  static gfxContext::GraphicsOperator
>  OptimalFillOperator()
>  {
> +    return gfxContext::OPERATOR_SOURCE;

I'd leave this part as is for now

::: layout/tools/reftest/reftest.js
@@ +764,5 @@
>          gDumpedConditionSandbox = true;
>      }
> +
> +    // Graphics features
> +    sandbox.supportsRepeatResampling = !sandbox.winWidget;

This doesn't make too much sense. The only place we don't supportRepeatResampling is CoreGraphics. The feature you want here is probably sandbox.usesRepeatResampling = sandbox.d2d
Attachment #8641754 - Flags: review?(jmuizelaar) → review-
Stop using CSRD w/ d2d.

Successful Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=61df022663ae
Attachment #8641754 - Attachment is obsolete: true
Attachment #8643067 - Flags: review?(jmuizelaar)
Attachment #8643067 - Flags: review?(jmuizelaar) → review+
Depends on: 1221840
We can probably simplify/remove CSRD completely now that we're without CG and Cairo?
Flags: needinfo?(mchang)
(In reply to Milan Sreckovic [:milan] from comment #50)
> We can probably simplify/remove CSRD completely now that we're without CG
> and Cairo?

Some reftest failures still. I'll take a look.
Flags: needinfo?(mchang)
Assignee: mchang → nobody
Status: ASSIGNED → NEW
The leave-open keyword is there and there is no activity for 6 months.
:davidb, maybe it's time to close this bug?
Flags: needinfo?(dbolter)
Nope. It's still relevant.
Flags: needinfo?(dbolter)

The leave-open keyword is there and there is no activity for 6 months.
:jbonisteel, maybe it's time to close this bug?

Flags: needinfo?(jbonisteel)

Nope.

Flags: needinfo?(jbonisteel)

The leave-open keyword is there and there is no activity for 6 months.
:jbonisteel, maybe it's time to close this bug?

Flags: needinfo?(jbonisteel)

Still nope.

Flags: needinfo?(jbonisteel)

The leave-open keyword is there and there is no activity for 6 months.
:jbonisteel, maybe it's time to close this bug?

Flags: needinfo?(jbonisteel)
Flags: needinfo?(jbonisteel)

The leave-open keyword is there and there is no activity for 6 months.
:jimm, maybe it's time to close this bug?

Flags: needinfo?(jmathies)
Severity: normal → N/A
Flags: needinfo?(jmathies)

The leave-open keyword is there and there is no activity for 6 months.
:jimm, maybe it's time to close this bug?

Flags: needinfo?(jmathies)

This is still in our backlog.

Flags: needinfo?(jmathies)

The leave-open keyword is there and there is no activity for 6 months.
:jimm, maybe it's time to close this bug?

Flags: needinfo?(jmathies)
Flags: needinfo?(jmathies)
Keywords: leave-open
Depends on: 1746662

Bob, is it safe to close this bug now?

Flags: needinfo?(bhood)

Since this was disabled by 1746662, I would consider it "eliminated" per the title. Closed.

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(bhood)
Resolution: --- → FIXED
Assignee: nobody → mchang
You need to log in before you can comment on or make changes to this bug.