915072 - SVG chained clipping path is calculated incorrectly for >2 subsequent clipping paths

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Vlad]

Attachment: chained_clippath.svg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.62 Safari/537.36

Steps to reproduce:

1. Open the attached file in Firefox

This minimal test file contains a green rectangle clipped with a simple rectangular clipping path (Clip_2). This clipping path is clipped with another clipping path (Clip_1), which coordinates are identical to the Clip_2, and once again, Clip_1 is clipped with Clip_0, with the same position and dimensions as Clip_1 and Clip_2:

  <clipPath id="Clip_0">
    <path d="M10 10 h200 v200 h-200 z"/>
  </clipPath>
  <clipPath clip-path="url(#Clip_0)" id="Clip_1">
    <path d="M10 10 h200 v200 h-200 z"/>
  </clipPath>
  <clipPath clip-path="url(#Clip_1)" id="Clip_2">
    <path d="M10 10 h200 v200 h-200 z"/>
  </clipPath>

This syntax should emulate clipping path intersection, and it works in IE and Chrome.
Note that the rectangle is visible if it is clipped with Clip_1, i.e if only two clipping paths are in clipping chain. It becomes invisible if 3 or more clipping path are added to the chain, although they should not modify the resulting clipping, as they are actually the same.


Actual results:

Nothing is displayed (blank white page)


Expected results:

A green rectangle should appear (as in Chrome and IE)

Comment 1

[Robert Longson [:longsonr]]

Works on nightly. No idea what fixed it though.

Comment 2

[Robert Longson [:longsonr]]

Unless of course it's only broken with hardware acceleration turned off. (I'm currently testing a nightly on a box that does not support hardware acceleration).

Comment 3

[Vlad]

Just retested with fresh nightly, still reproducing, with hardware acceleration on and off. Do I need to provide more information about my system or something?

Comment 4

[Robert Longson [:longsonr]]

So this works if HWA is off and fails if it's on.

Comment 5

[Robert Longson [:longsonr]]

Any idea what's going on Bas? Turning HWA off makes the green square appear for me.

Comment 6

[Vlad]

Yes, for me too (I've noticed that Nightly should be restarted after turning HWA off)

(In reply to Robert Longson from comment #5)
> Any idea what's going on Bas? Turning HWA off makes the green square appear
> for me.

Comment 7

[(mostly gone) XtC4UaLL [:xtc4uall]]

FWIW, it's reproducible back using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 ID:20110413222027 CSet: fca718600ca0 too, so not a recent Issue.

Comment 10

[Bas Schouten (:bas.schouten)]

(In reply to Robert Longson from comment #5)
> Any idea what's going on Bas? Turning HWA off makes the green square appear
> for me.

Could be a cairo clipping bug, or a bug in the Moz2D cairo implementation. Someone would have to take a look and analyze.

Comment 11

[Robert Longson [:longsonr]]

It's not cairo as it only affects HWA.

Comment 12

[Bas Schouten (:bas.schouten)]

(In reply to Robert Longson from comment #11)
> It's not cairo as it only affects HWA.

Hrm, another comment said this was present in 20100101.. unless I'm mistaking (which is possible, it's been so long!) we didn't even -have- hardware acceleration back then, or at least the code was all different? Or I misinterpreted the comment, in which case it's reproducible April 2011, where we might've had HWA :-).

Comment 13

[Alice0775 White]

Regression window with force enabled D2D
user_pref("gfx.font_rendering.directwrite.enabled",true);
user_pref("mozilla.widget.render-mode", 6);
user_pref("gfx.direct2d.force-enabled",true);

Good:
http://hg.mozilla.org/mozilla-central/rev/0e1c0b71bf13
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100225 Minefield/3.7a2pre ID:20100225230231
Bad:
http://hg.mozilla.org/mozilla-central/rev/475768f37b1a
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100226 Minefield/3.7a2pre ID:20100226035959
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e1c0b71bf13&tochange=475768f37b1a

Suspect:
475768f37b1a	Robert Longson — Bug 534612 - clipPath references with clipPath elements do not work correctly. r=roc

Comment 14

[Robert Longson [:longsonr]]

bug 534612 is what implemented multiple clip-path in clipPath support in the first place. Before that clip-path attributes on clipPath elements would be ignored so  

  <clipPath id="Clip_0">
    <path d="M10 10 h200 v200 h-200 z"/>
  </clipPath>
  <clipPath clip-path="url(#Clip_0)" id="Clip_1">
    <path d="M10 10 h200 v200 h-200 z"/>
  </clipPath>
  <clipPath clip-path="url(#Clip_1)" id="Clip_2">
    <path d="M10 10 h200 v200 h-200 z"/>
  </clipPath>

would be treated as

  <clipPath id="Clip_0">
    <path d="M10 10 h200 v200 h-200 z"/>
  </clipPath>
  <clipPath id="Clip_1">
    <path d="M10 10 h200 v200 h-200 z"/>
  </clipPath>
  <clipPath id="Clip_2">
    <path d="M10 10 h200 v200 h-200 z"/>
  </clipPath>

Comment 15

[Robert Longson [:longsonr]]

bug  534612 is platform independent and it works with HWA off so it's really not the cause of the d2d issue it's just that the preexisting bad d2d code wouldn't be invoked without it.

Comment 16

[u279076]

Does this still reproduce?

Comment 17

[Robert Longson [:longsonr]]

WFM these days.