Eliminate usage of CreateSamplingRestrictedDrawable
Categories
(Core :: Graphics, defect, P3)
Tracking
()
People
(Reporter: jrmuizel, Assigned: mchang)
References
(Blocks 1 open bug)
Details
(Whiteboard: gfx-noted)
Attachments
(8 files, 4 obsolete files)
(deleted),
patch
|
mchang
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
jrmuizel
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/zip
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
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.
Reporter | ||
Updated•10 years ago
|
Reporter | ||
Updated•10 years ago
|
Assignee | ||
Updated•10 years ago
|
Assignee | ||
Updated•10 years ago
|
Reporter | ||
Comment 1•10 years ago
|
||
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
Reporter | ||
Comment 3•10 years ago
|
||
Comment on attachment 8594051 [details] [diff] [review] Disable CreateSamplingRestrictedDrawable on OS X This is beautiful!
Assignee | ||
Updated•10 years ago
|
Assignee | ||
Comment 4•10 years ago
|
||
Successful reftest try push - https://treeherder.mozilla.org/#/jobs?repo=try&revision=27fc708c1f0f
Assignee | ||
Comment 6•10 years ago
|
||
Carrying r+, updated with some nits to pass try. https://hg.mozilla.org/integration/mozilla-inbound/rev/2d97da8feb72
Reporter | ||
Comment 8•10 years ago
|
||
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.
Assignee | ||
Comment 9•10 years ago
|
||
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.
Assignee | ||
Comment 10•10 years ago
|
||
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
Assignee | ||
Updated•10 years ago
|
Assignee | ||
Comment 11•10 years ago
|
||
Will file a part 3 with the correct reftest.list changes after a successful try.
Reporter | ||
Comment 12•10 years ago
|
||
(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.
Reporter | ||
Comment 13•10 years ago
|
||
(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?
Reporter | ||
Comment 14•10 years ago
|
||
(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.
Reporter | ||
Comment 15•10 years ago
|
||
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.
Reporter | ||
Comment 16•10 years ago
|
||
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.
Assignee | ||
Comment 17•10 years ago
|
||
Reftest changes needed with deletion of CSRD. https://treeherder.mozilla.org/#/jobs?repo=try&revision=210609ebf9da
Reporter | ||
Comment 18•10 years ago
|
||
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...
Assignee | ||
Comment 19•10 years ago
|
||
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.
Reporter | ||
Comment 20•10 years ago
|
||
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.
Assignee | ||
Comment 21•10 years ago
|
||
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.
Reporter | ||
Comment 22•9 years ago
|
||
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.
Assignee | ||
Comment 23•9 years ago
|
||
This causes pain on twitter.com - http://people.mozilla.org/~bgirard/cleopatra/#report=aac43f5d7ff7308364255be3e019401a0728cf3a
Assignee | ||
Comment 24•9 years ago
|
||
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.
Comment 26•9 years ago
|
||
Uhm, in the CSRD case you don't actually include the creation of the CSRD in your timings.
Assignee | ||
Comment 27•9 years ago
|
||
(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.
Assignee | ||
Comment 29•9 years ago
|
||
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
Comment 30•9 years ago
|
||
(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.
Comment 31•9 years ago
|
||
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?
Reporter | ||
Comment 32•9 years ago
|
||
(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.
Assignee | ||
Comment 33•9 years ago
|
||
(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?
Comment 34•9 years ago
|
||
(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.
Assignee | ||
Comment 35•9 years ago
|
||
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.
Reporter | ||
Comment 36•9 years ago
|
||
(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.
Assignee | ||
Comment 37•9 years ago
|
||
Looks like this is pretty slow on Windows while scrolling twitter.com: http://people.mozilla.org/~bgirard/cleopatra/#report=8582a7273520ae3b7e5b22d49adc4fed67a1e133
Reporter | ||
Comment 38•9 years ago
|
||
(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.
Assignee | ||
Comment 39•9 years ago
|
||
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.
Assignee | ||
Comment 40•9 years ago
|
||
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.
Assignee | ||
Comment 41•9 years ago
|
||
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.
Assignee | ||
Comment 42•9 years ago
|
||
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.
Assignee | ||
Comment 43•9 years ago
|
||
Assignee | ||
Comment 44•9 years ago
|
||
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?
Reporter | ||
Comment 45•9 years ago
|
||
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
Assignee | ||
Comment 46•9 years ago
|
||
Stop using CSRD w/ d2d. Successful Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=61df022663ae
Reporter | ||
Updated•9 years ago
|
Assignee | ||
Comment 47•9 years ago
|
||
Please check in attachment 8643067 [details] [diff] [review].
Comment 48•9 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/db744be4dc3d
We can probably simplify/remove CSRD completely now that we're without CG and Cairo?
Assignee | ||
Comment 51•8 years ago
|
||
(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.
Assignee | ||
Updated•7 years ago
|
Updated•7 years ago
|
Comment 52•6 years ago
|
||
The leave-open keyword is there and there is no activity for 6 months. :davidb, maybe it's time to close this bug?
Comment 54•5 years ago
|
||
The leave-open keyword is there and there is no activity for 6 months.
:jbonisteel, maybe it's time to close this bug?
Comment 56•5 years ago
|
||
The leave-open keyword is there and there is no activity for 6 months.
:jbonisteel, maybe it's time to close this bug?
Comment 58•4 years ago
|
||
The leave-open keyword is there and there is no activity for 6 months.
:jbonisteel, maybe it's time to close this bug?
Updated•4 years ago
|
Comment 59•4 years ago
|
||
The leave-open keyword is there and there is no activity for 6 months.
:jimm, maybe it's time to close this bug?
Updated•4 years ago
|
Comment 60•3 years ago
|
||
The leave-open keyword is there and there is no activity for 6 months.
:jimm, maybe it's time to close this bug?
Comment 62•3 years ago
|
||
The leave-open keyword is there and there is no activity for 6 months.
:jimm, maybe it's time to close this bug?
Updated•3 years ago
|
Comment 64•2 years ago
|
||
Since this was disabled by 1746662, I would consider it "eliminated" per the title. Closed.
Updated•2 years ago
|
Description
•