522866 - SVG feTile does not clamp the filter effects region to the filter primitive subregion

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Dirk Schulze]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de-de) AppleWebKit/531.2+ (KHTML, like Gecko) Safari/531.2+
Build Identifier: FF 3.5.3

Not sure how I should discribe the problem other than that you should see a pattern with white and black rects with different size.
Currently the output is blank.

Reproducible: Always

Comment 1

[Dirk Schulze]

Attachment: feTile with empty output in FF

The example of feTile with empty output. See in batik how it should look like.

Comment 2

[Robert Longson [:longsonr]]

This is the same as your other example in bug 522394 i.e. the tile is partially outside the filter surface.

tile x, y = (-10, -10) width, height = (50, 50)

surface x,y = (0, 0) width, height = (100, 100)

Comment 3

[Robert Longson [:longsonr]]

Attachment: what batik draws

Comment 4

[Dirk Schulze]

(In reply to comment #2)
> This is the same as your other example in bug 522394 i.e. the tile is partially
> outside the filter surface.
> 
> tile x, y = (-10, -10) width, height = (50, 50)
> 
> surface x,y = (0, 0) width, height = (100, 100)

No, I don't think that this is related to this bug. Let me explain why. In bug 522394 I used a huge filterRect, bigger then that what FF handles. Thats why it uses filterRes to get the problem solved.
This time the filterRect has the size 100x100.
In this case, if the tile is outsite of filter boundaries, it needs to be clipped to this boundaries.
This works in FF for examples like that:

<filter>
<feFood flood-color="green"/>
<feOffset dx="50" dy="50"/>
<feOffset dx="-25" dy="-25"/>
</filter>

It should also work for feTile.

Comment 5

[Dirk Schulze]

... but maybe it's related to bug 521207 and just a duplication?

Comment 6

[Robert Longson [:longsonr]]

(In reply to comment #4)
> No, I don't think that this is related to this bug. Let me explain why. In bug
> 522394 I used a huge filterRect, bigger then that what FF handles. Thats why it

I did write the feTile code in firefox FWIW :-)

Comment 7

[Robert Longson [:longsonr]]

On the other hand I did give the wrong bug number :-( and you are correct that I meant that it's the same as bug 521207.

Comment 8

[Robert Longson [:longsonr]]

No longer empty but on the other hand not the same as Batik/Safari. Is the same as Opera however. Requires we3 decision to progress (see bug 521207 for more details)

Comment 9

[Dirk Schulze]

Need to look at this again and bring it to the SVG WG.

Comment 10

[O S K Chaitanya]

Attachment: how it looks on firefox 19 (for Ubuntu)

The current Nightly's render of the first attachment looks exactly like batik's render (second attachment)

I had tested a lot of edge cases while working on a patch for an optimisation for feTile. In that process I had covered various versions of the case mentioned in this bug (tile partially outside the filter surface). So, looking at this bug I felt that it should look like batik's render with my changes. I can confirm that with the release version of firefox (19 for Ubuntu) the first attachment renders differently than the current Nightly and that the current Nightly renders exactly like the second attachment (batik's render). I have attached what it looks like on Firefox 19 (for Ubuntu).

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to O S K Chaitanya from comment #10)
> The current Nightly's render of the first attachment looks exactly like
> batik's render (second attachment)

Yeah, this appears to be WORKSFORME now. (at least, the testcase (attachment 406864 [details]) now renders the same as the screenshot of batik (attachment 406872 [details]))

osk, do you happen to know which bug changed the behavior here?  If so, we can probably mark this as depending on that bug and resolve this.

Comment 12

[O S K Chaitanya]

The patch for bug#389814 fixed this. However, for the sake of accuracy I must point out that the bugs are unrelated. It is just that while making that patch, I had tested a lot of cases and made them work and this happens to be among them.

Comment 13

[Robert Longson [:longsonr]]

Excellent.