Closed
Bug 1137938
Opened 9 years ago
Closed 6 years ago
Nested svg clipPath fails
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: andershol, Unassigned)
Details
(Whiteboard: gfx-noted)
Attachments
(1 file)
682 bytes,
image/svg+xml
|
Details |
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
Updated•9 years ago
|
Component: General → Graphics
Product: Firefox → Core
Version: Firefox 38 → unspecified
Comment 1•9 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•9 years ago
|
Component: Graphics → Graphics: Layers
Comment 3•9 years ago
|
||
(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)
Comment 4•9 years ago
|
||
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
Comment 7•9 years ago
|
||
setting gfx.content.azure.backends = cairo also fix the problem even if HWA enabled
Comment 8•9 years ago
|
||
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•9 years ago
|
Flags: needinfo?(jwatt)
Updated•6 years ago
|
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.
Description
•