Closed Bug 1137938 Opened 9 years ago Closed 6 years ago

Nested svg clipPath fails

Categories

(Core :: Graphics, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: andershol, Unassigned)

Details

(Whiteboard: gfx-noted)

Attachments

(1 file)

682 bytes, image/svg+xml
Details
Attached image 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
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
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
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.
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
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)
Flags: needinfo?(jwatt)
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(jwatt)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: