Closed Bug 522866 Opened 15 years ago Closed 11 years ago

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

Categories

(Core :: SVG, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: krit, Unassigned)

References

Details

Attachments

(3 files)

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
The example of feTile with empty output. See in batik how it should look like.
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)
(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.
... but maybe it's related to bug 521207 and just a duplication?
(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 :-)
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.
Assignee: nobody → longsonr
Status: UNCONFIRMED → NEW
Depends on: 521207
Ever confirmed: true
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)
Assignee: longsonr → nobody
Status: NEW → UNCONFIRMED
Ever confirmed: false
Summary: SVG feTile gives empty output → SVG feTile does not clamp the filter effects region to the filter primitive subregion
Need to look at this again and bring it to the SVG WG.
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).
(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.
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.
Excellent.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Depends on: 389814
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: