1102014 - feImage with missing image resource should render transparent black

Status: NEW

(Core :: Graphics, defect)

Description

[Max Vujovic]

The spec [1] was recently updated to say:
"A href reference that is an empty image (zero width or zero height), that fails to download, is non-existent, or that cannot be displayed (e.g. because it is not in a supported image format) fills the filter primitive subregion with transparent black."

[1]: http://dev.w3.org/fxtf/filters/#feImageElement

Comment 1

[Max Vujovic]

Attachment: Patch (WIP)

This patch makes a missing image resource explicitly render transparent black in the filter primitive subregion. Before, we used PrimitiveType::Empty, which ended up as a 0x0 sized transparent black flood FilterNode.

Running the patch through the try bots before review.

Comment 2

[Max Vujovic]

Comment on attachment 8525714 [details] [diff] [review]
Patch (WIP)

Setting r?.

Try looked good:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=842d8f2ec150

Comment 3

[Markus Stange [:mstange]]

I'm currently dealing with a similar problem in bug 1092634 and I think your patch is the wrong way to go about it. In FilterNodeSoftware, I'd like the output surface to be as tight as possible without unneeded transparency at the edges. If a FilterNodeSoftware subclass shows different behavior depending on whether its input comes with transparent padding around it, then that's a bug in how that filter node deals with input.
I'll need to add a comment about that assumption somewhere to FilterNodeSoftware.h.

Comment 4

[Max Vujovic]

(In reply to Markus Stange [:mstange] from comment #3)
> I'm currently dealing with a similar problem in bug 1092634 and I think your
> patch is the wrong way to go about it. In FilterNodeSoftware, I'd like the
> output surface to be as tight as possible without unneeded transparency at
> the edges. If a FilterNodeSoftware subclass shows different behavior
> depending on whether its input comes with transparent padding around it,
> then that's a bug in how that filter node deals with input.
> I'll need to add a comment about that assumption somewhere to
> FilterNodeSoftware.h.

Ok, that makes sense. I like that your patch doesn't inflate layers with transparency unless the next filter primitive needs it.

I ran my tests in this patch against your patch in bug 1092634, and they both work properly (as I would expect). I'm thinking I throw out the bit of code in this patch and just land the tests after bug 1092634 lands.