Closed
Bug 522866
Opened 15 years ago
Closed 12 years ago
SVG feTile does not clamp the filter effects region to the filter primitive subregion
Categories
(Core :: SVG, defect)
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
Reporter | ||
Comment 1•15 years ago
|
||
The example of feTile with empty output. See in batik how it should look like.
Comment 2•15 years ago
|
||
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•15 years ago
|
||
Reporter | ||
Comment 4•15 years ago
|
||
(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.
Reporter | ||
Comment 5•15 years ago
|
||
... but maybe it's related to bug 521207 and just a duplication?
Comment 6•15 years ago
|
||
(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•15 years ago
|
||
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.
Updated•15 years ago
|
Comment 8•15 years ago
|
||
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
Updated•15 years ago
|
Status: NEW → UNCONFIRMED
Ever confirmed: false
Updated•15 years ago
|
Summary: SVG feTile gives empty output → SVG feTile does not clamp the filter effects region to the filter primitive subregion
Reporter | ||
Comment 9•12 years ago
|
||
Need to look at this again and bring it to the SVG WG.
Comment 10•12 years ago
|
||
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•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
Excellent.
You need to log in
before you can comment on or make changes to this bug.
Description
•