RE: Filter Templates

This is interesting "maximum size dependent of the union of all input filter primitives".

I wonder though is it more developer choice and implementation detail? I certainly could see independent UA's clamping this union.  However, I raised the issue of max values on individual filters before and got reasonable feedback that we might put non-normative recommendations, but that we cannot and should not anticipate the future for hardware. Now I realize when they are being composed there seems to be a reasonable mathematic ceiling regardless (i.e. infinite), and so maybe a non-normative statement around the max union.

Also, this should also be a problem in SVG correct? And if so, have we seen it in the wild?

-----Original Message-----
From: Dirk Schulze [mailto:vbs85@gmx.de] 
Sent: Wednesday, January 26, 2011 12:52 AM
To: robert@ocallahan.org
Cc: Patrick Dengler; Tab Atkins Jr.; Brad Kemper; www-style list; public-fx@w3.org
Subject: Re: Filter Templates


Am 25.01.2011 um 23:34 schrieb Robert O'Callahan:

> I've said this before and I'll say it again: for performance, implementations already need to ignore the regions the author gave and compute their own minimal regions. So mx/my/mw/mh should be dropped from the spec. Furthermore, we should get rid of the -10%/-10%/120%/120% hack and say that by default the filter region is infinite. Easier for authors, easier for implementors.


I agree in general, but like I wrote before, you still have filter primitives that can get infinite large. We still need some kind of region definition for them, or make the maximum size dependent of the union of all input filter primitives. Some examples that could get infinite large are lightning effects or feComposite with 'arithmentic'.

Dirk

Received on Wednesday, 26 January 2011 16:24:47 UTC