Nested svg clipPath fails

RESOLVED WORKSFORME

Status

()

RESOLVED WORKSFORME
4 years ago
9 months ago

People

(Reporter: andershol, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: gfx-noted)

Attachments

(1 attachment)

682 bytes, image/svg+xml
Details
(Reporter)

Description

4 years ago
Created attachment 8570749 [details]
Test-case

Load the attached reduced test-case. I believe it should show a black triangle (the upper right half of a square) and Chrome/IE/Inkscape agree. In a current Firefox it shows nothing.

Oddly I think it worked about a week ago, but mozregression thinks it was much longer ago. If it is related to the Intel graphics driver bug, my machine might just have stated using the other gpu for some reason:

Last good revision: 768af8d8fad4 (2013-04-06)
First bad revision: be3be63607b0 (2013-04-07)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=768af8d8fad4&tochange=be3be63607b0
Component: General → Graphics
Product: Firefox → Core
Version: Firefox 38 → unspecified

Comment 1

4 years ago
I can reproduce the problem on Firefox4-Nightly39.0a1 with HWA enabled(AMD RADEON HD).
However, It works if HWA disabled.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

4 years ago
Component: Graphics → Graphics: Layers
Maybe :bas finds this familiar?
Flags: needinfo?(bas)
Whiteboard: gfx-noted
(In reply to Jeff Gilbert [:jgilbert] from comment #2)
> Maybe :bas finds this familiar?

Hrm no. And I also don't see anything in the push log that seems suspicious, how about you Jonathan?
Flags: needinfo?(bas) → needinfo?(jwatt)
I don't think we layerize SVG clip paths, but anyone who knows differently feel free to switch this back. This is likely a D2D issue.
Component: Graphics: Layers → Graphics
(Reporter)

Comment 5

4 years ago
Tried to manually narrow the range down based on the above pushlog (mozregression wouldn't build):

Last good:
8bcd935cbcfe Tom Schuster — Bug 854614 - Root xpc_qsUnwrapThis. r=terrence,bholley
First bad:
ea8f727040ce Yuan Pengfei — Bug 844031 - Fix Intel graphics driver detection. r=bjacob
http://hg.mozilla.org/mozilla-central/rev/ea8f727040ce

But if it only changes detection, it might just enable a bug already in there. If I follow the logic, by and'ing a clause more, the test is being made more restrictive, so mHasDriverVersionMismatch is true in less cases, so "aStatus = nsIGfxInfo::FEATURE_BLOCKED_DRIVER_VERSION" in less cases. This matches what I see if I look at the changed information from the Graphics section of the Troubleshooting Information page:

8bcd935cbcfe - good
Direct2D Enabled	Blocked for your graphics driver version.
DirectWrite Enabled	false (6.2.9200.16571)
GPU Accelerated Windows	0/1 Basic
AzureCanvasBackend	skia
AzureContentBackend	none

ea8f727040ce - bad
Direct2D Enabled	true
DirectWrite Enabled	true (6.2.9200.16571)
GPU Accelerated Windows	1/1 Direct3D 10
AzureCanvasBackend	direct2d
AzureContentBackend	direct2d

So I guess I should rerun the bisect with the driver force-enabled (gfx.direct2d.force-enabled=true from https://wiki.mozilla.org/Blocklisting/Blocked_Graphics_Drivers ) unless you'd rather just disable it.
(Reporter)

Comment 6

4 years ago
I did not find any version where it worked with D2D enabled. I did find versions where it also did not work with D2D disabled (I guess before the feature was implemented). Have this feature ever been implemented for this driver? (or have I "stepped over" it?)

Last good revision: efbf1fa4c70e (2011-01-20) (meaning that it did not work with nor without d2d)
First bad revision: 16bd82195df8 (2011-01-21) (meaning that it did work without d2d, but not with)
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=efbf1fa4c70e&tochange=16bd82195df8

Comment 7

3 years ago
setting gfx.content.azure.backends = cairo also fix the problem even if HWA enabled
The code flow is:

We apply the clip using nsSVGIntegrationUtils::PaintFramesWithEffects which realizes that it's got a complex clip (a clip that is itself clipped). To handle this it calls gfxContext::PushGroup before calling nsSVGClipPathFrame::ApplyClipOrPaintClipMask.

https://mxr.mozilla.org/mozilla-central/source/layout/svg/nsSVGIntegrationUtils.cpp?rev=ac4464790ec4&mark=569-571,573-573,582-582#568

ApplyClipOrPaintClipMask applies the clip path that is clipping the directly referenced clip path by recursing into nsSVGClipPathFrame::ApplyClipOrPaintClipMask for the second nsSVGClipPathFrame. There it applies the clip path by building a Path and applying it using gfxContext::Clip. On returning to the original ApplyClipOrPaintClipMask call the directly referenced clip path is painted by filling using PaintSVG:

https://mxr.mozilla.org/mozilla-central/source/layout/svg/nsSVGClipPathFrame.cpp?rev=133ec7304f22&mark=137-137#136

On returning to nsSVGIntegrationUtils::PaintFramesWithEffects the pushed group is popped using gfxContext::PopGroupToSurface then applied as a mask using gfxContext::Mask.
Flags: needinfo?(jwatt)

Updated

3 years ago
Flags: needinfo?(jwatt)

Updated

9 months ago
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Flags: needinfo?(jwatt)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.