Re: [whatwg] Support filters in Canvas

[Ian Kilpatrick]

Having an opaque handle (CanvasFilter) would be great for Houdini paint.

This would mean that when we plumb in a property of CSS type
 the TypedOM can have an opaque handle to that
filter. I.e.

registerPaint('x', class {
  paint(ctx, styleMap) {
const filter = styleMap.get('--my-filter').filter;
// ...
ctx.filter = filter; // \o/
ctx.filter = 'url(#thing)'; // would fail for Houdini paint.
  }
});

It would make a lot of sense as wouldn't have to deal with paint time
resolving of url(), when happens when filter changes, etc.

This is similar to what we'd like to do with text (assigning an already
resolved FontFace or similar).

Ian

On Fri, Feb 26, 2016 at 8:20 AM, Justin Novosad  wrote:

> On Fri, Feb 26, 2016 at 10:40 AM, Anne van Kesteren 
> wrote:
>
> > On Fri, Feb 26, 2016 at 4:34 PM, Ali Juma  wrote:
> > > The current canvas filters proposal [1] allows using SVG reference
> > filters
> > > defined in external documents (e.g. “url(file.svg#filter)”). Since the
> > > external document needs to be loaded before the filter can be applied,
> > > there’s a delay between setting the context’s filter attribute to such
> a
> > > filter and actually having the filter apply to drawing operations.
> >
> > Perhaps we could support assigning an SVG filter directly (as an
> > object)? Developers would be responsible to load them if they're
> > external. Adding yet another network API that's a thin layer on top of
> > some CSS syntax seems a little hackish. I'd prefer if we exposed
> > filters at a lower level somehow.
> >
>
> Just thought of a way to solve this problem without new API. You can load
> the svg file as xml using XHR, and therefore guarantee the resource's
> continued availability thereafter. In order to make the filter node
> reachable for setting it as a canvas filter using the url() syntax, I think
> you'd have to pull it in to your HTML with something like:
> someLocalElement.innerHTML = new
> XMLSerializer().serializeToString(svgObtainedViaXHR.documentElement);
> I know this is gross (parse->serialize->re-parse), but I'm just saying
> there is a way (I think).
>
>
>
> > --
> > https://annevankesteren.nl/
> >
>

Re: [whatwg] Support filters in Canvas

[Justin Novosad]

On Fri, Feb 26, 2016 at 10:40 AM, Anne van Kesteren 
wrote:

> On Fri, Feb 26, 2016 at 4:34 PM, Ali Juma  wrote:
> > The current canvas filters proposal [1] allows using SVG reference
> filters
> > defined in external documents (e.g. “url(file.svg#filter)”). Since the
> > external document needs to be loaded before the filter can be applied,
> > there’s a delay between setting the context’s filter attribute to such a
> > filter and actually having the filter apply to drawing operations.
>
> Perhaps we could support assigning an SVG filter directly (as an
> object)? Developers would be responsible to load them if they're
> external. Adding yet another network API that's a thin layer on top of
> some CSS syntax seems a little hackish. I'd prefer if we exposed
> filters at a lower level somehow.
>

Just thought of a way to solve this problem without new API. You can load
the svg file as xml using XHR, and therefore guarantee the resource's
continued availability thereafter. In order to make the filter node
reachable for setting it as a canvas filter using the url() syntax, I think
you'd have to pull it in to your HTML with something like:
someLocalElement.innerHTML = new
XMLSerializer().serializeToString(svgObtainedViaXHR.documentElement);
I know this is gross (parse->serialize->re-parse), but I'm just saying
there is a way (I think).



> --
> https://annevankesteren.nl/
>

Re: [whatwg] Support filters in Canvas

[Domenic Denicola]

From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Anne van 
Kesteren

> Perhaps we could support assigning an SVG filter directly (as an object)? 
> Developers would be responsible to load them if they're external. Adding yet 
> another network API that's a thin layer on top of some CSS syntax seems a 
> little hackish. I'd prefer if we exposed filters at a lower level somehow.

I tend to agree. I don't like that the filter property is now sometimes a 
string, sometimes a CanvasFilter.

Maybe something like `setFilter((DOMString or CanvasFilter) filter)` with the 
readonly `filter` property returning a CanvasFilter all the time? This would 
involve fleshing out CanvasFilter a bit. Strawman:

const filter1 = new CanvasFilter("contrast(50%) blur(3px)");

// filter1 looks like { value: "contrast(50%) blur(3px)", loadedFrom: null }

CanvasFilter.load("file.svg#blur").then(filter2 => {
  // filter2 looks like { value: null, loadedFrom: "file.svg#blur" }

  ctx.setFilter(filter1);
  ctx.strokeText("Canvas", 50, 500);
  
  assert(ctx.filter === filter1);
  
  ctx.setFilter(filter2);
  ctx.strokeText("Filters", 50, 100);
  
  assert(ctx.filter === filter2);
  
  ctx.setFilter(filter3);
  ctx.strokeText("SVG", 50, 200);
});

This doesn't really solve Anne's concerns about a new networking API, but I am 
not sure how to do that given that fragments are involved (which are not a 
networking concept, really). Maaaybe you could do something like

fetch("file.svg").then(res => res.blob()).then(blob => {
  const filter2 = CanvasFilter.fromSVG(blob, "#blur");
  // ...
});

---

Alternately, is it possible to generically represent a loaded SVG filter as a 
string? Browsing the linked thread it seems unlikely as it may involve further 
external resource fetches etc. But that would help some design space.

Re: [whatwg] Support filters in Canvas

[Anne van Kesteren]

On Fri, Feb 26, 2016 at 4:34 PM, Ali Juma  wrote:
> The current canvas filters proposal [1] allows using SVG reference filters
> defined in external documents (e.g. “url(file.svg#filter)”). Since the
> external document needs to be loaded before the filter can be applied,
> there’s a delay between setting the context’s filter attribute to such a
> filter and actually having the filter apply to drawing operations.

Perhaps we could support assigning an SVG filter directly (as an
object)? Developers would be responsible to load them if they're
external. Adding yet another network API that's a thin layer on top of
some CSS syntax seems a little hackish. I'd prefer if we exposed
filters at a lower level somehow.


-- 
https://annevankesteren.nl/

Re: [whatwg] Support filters in Canvas

[Ali Juma]

The current canvas filters proposal [1] allows using SVG reference filters
defined in external documents (e.g. “url(file.svg#filter)”). Since the
external document needs to be loaded before the filter can be applied,
there’s a delay between setting the context’s filter attribute to such a
filter and actually having the filter apply to drawing operations. So
authors can’t predict when the filter will start getting applied. For
example:

var canvas = document.getElementById(“canvas”);
var ctx = canvas.getContext(“2d”);
ctx.filter = “url(file.svg#blur)”
ctx.font = “48px serif”
ctx.strokeText(“Hello world”, 50, 100);

Unless file.svg happens to already be loaded, it won’t be loaded in time
for the call to strokeText. After some unpredictable delay, the document
will finish loading and the filter will start being applied to future draw
operations.

Another problem is switching between filters defined in separate documents
within the same animation frame. Continuing the previous example:

ctx.filter = “url(file2.svg#dropShadow)”
ctx.strokeText(“Hello again”, 50, 200);
ctx.filter = “url(file.svg#blur)”
ctx.strokeText(“Canvas”, 50, 300);

As soon as the filter property’s value is changed, documents that the
previous value referred to may get unloaded. So after switching back to
“url(file.svg#blur)” there might be another delay before the filter is
useable again.

To address these problems, I’d like to propose adding a createFilter
method. This takes a string (a filter value) and returns a promise. If the
filter fails to load, the promise is rejected. Otherwise, once the filter
finishes loading, the promise resolves to a CanvasFilter instance that acts
as an opaque handle to the filter. The filter is guaranteed to remain
loaded as long as the handle has references. A CanvasFilter can be directly
used as a filter attribute value. That is, the filter attribute is now
defined as:
  attribute (DOMString or CanvasFilter) filter;

For example:
var filters = [];
var promises = [];
promises[0] = ctx.createFilter(“url(file.svg#blur)”);
promises[1] = ctx.createFilter(“url(file2.svg#dropShadow)”);
Promise.all(promises).then(function(values) {
  filters = values;
  // Filters can now be used without any delay.
  ctx.filter = filters[0];
  ctx.strokeText(“Canvas”, 50, 400);
  ctx.filter = filters[1];
  ctx.strokeText(“Filters”, 50, 100);
  ctx.filter = filters[0];
  ctx.strokeText(“SVG”, 50, 200);
});
…
// Once we no longer need these filters, release them.
filters = [];


Ali

[1]
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0110.html

Re: [whatwg] Support filters in Canvas

[Mark Callow]

On 30/09/2014 02:20, Markus Stange wrote:
 Hi,

 I'd like to revive this discussion.

 On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:

 I would suggest a filter attribute that takes a list of filter operations
 similar to the CSS Image filter function[1]. Similar to shadows[2], each
 drawing operation would be filtered. The API looks like this:

 partial interface CanvasRenderingContext2D {
 attribute DOMString filter;
 }

 A filter DOMString could looks like: “contrast(50%) blur(3px)”

What happened to the effort to create CSS filters programmable in GLSL?
Wasn't that effort addressing canvas filters too? Programmable filters
seem more desirable than a fixed set. Last I heard the CSS filters
effort was exploring ways to limit filter operations to those that would
not allow, for example, the visited state of links to be determined. I
think allowing operations only on same-origin data solves those types of
issues for canvas.

Regards

-Mark

-- 
注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合
が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情
報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし
たら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and
privileged information from HI Corporation. If you are not the intended
recipient, any disclosure, photocopying, distribution or use of the
contents of the received information is prohibited. If you have received
this e-mail in error, please notify the sender immediately and
permanently delete this message and all related copies.G

Re: [whatwg] Support filters in Canvas

[Dirk Schulze]

On Oct 1, 2014, at 12:28 PM, Mark Callow callow.m...@artspark.co.jp wrote:

 
 On 30/09/2014 02:20, Markus Stange wrote:
 Hi,
 
 I'd like to revive this discussion.
 
 On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze 
 dschu...@adobe.com
  wrote:
 
 
 I would suggest a filter attribute that takes a list of filter operations
 similar to the CSS Image filter function[1]. Similar to shadows[2], each
 drawing operation would be filtered. The API looks like this:
 
 partial interface CanvasRenderingContext2D {
 attribute DOMString filter;
 }
 
 A filter DOMString could looks like: “contrast(50%) blur(3px)”
 
 
 What happened to the effort to create CSS filters programmable in GLSL? 
 Wasn't that effort addressing canvas filters too? Programmable filters seem 
 more desirable than a fixed set. Last I heard the CSS filters effort was 
 exploring ways to limit filter operations to those that would not allow, for 
 example, the visited state of links to be determined. I think allowing 
 operations only on same-origin data solves those types of issues for canvas.

CSS Shaders are the programmable GLSL filters you mean. Some browser vendors 
expressed their strong objection to this feature. We’ll explore the feature at 
a later time. As you said, there were limitations in CSS Shaders that disallow 
any direct pixel access. This makes it impossible to use CSS Shaders for many 
use cases. Most of the short hand filters could not be done with CSS Shaders 
for instance. However, shaders can still be used in WebGL on content without 
privacy implications.

Greetings,
Dirk

 
 Regards
 
 -Mark
 
 -- 
 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 
 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.
 NOTE: This electronic mail message may contain confidential and privileged 
 information from HI Corporation. If you are not the intended recipient, any 
 disclosure, photocopying, distribution or use of the contents of the received 
 information is prohibited. If you have received this e-mail in error, please 
 notify the sender immediately and permanently delete this message and all 
 related copies.G
 

Re: [whatwg] Support filters in Canvas

[Dirk Schulze]

On Sep 30, 2014, at 6:45 AM, Rik Cabanier caban...@gmail.com wrote:

 On Mon, Sep 29, 2014 at 8:52 PM, Robert O'Callahan rob...@ocallahan.org
 wrote:
 
 On Mon, Sep 29, 2014 at 2:12 PM, Rik Cabanier caban...@gmail.com wrote:
 
 Can we limit it to just the set of CSS filter shorthands for now?
 I think other UA's are further behind in their implementation of
 integrating SVG filters in their rendering pipeline.
 
 
 How about we put CSS + SVG filters into the one spec draft for now, and
 split them up into two drafts if we actually get to the point where vendors
 want to ship one and not the other? It seems premature to create both HTML
 Canvas Filters Level 1 and HTML Canvas Filters Level 2 at the same time.
 
 
 Are you proposing that this is developed as a separate spec and not as an
 addition to the canvas specification?

I think it should be part of the canvas spec. I agree with Robert that it can 
be added to the spec initially. If it turns out that SVG Filters in canvas are 
to hard for implementations initially, then we can postpone it later.

Greetings,
Dirk

Re: [whatwg] Support filters in Canvas

[Robert O'Callahan]

On Tue, Sep 30, 2014 at 12:45 AM, Rik Cabanier caban...@gmail.com wrote:

 Are you proposing that this is developed as a separate spec and not as an
 addition to the canvas specification?


No, not really.

I want to make sure that we have a pathway to standardize SVG filter
support in canvas. If we restrict the canvas spec to features for which
multiple implementations are imminent, and SVG filters aren't such a
feature, then we'll need another way to record and discuss proposals for
SVG filters in canvas.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

Re: [whatwg] Support filters in Canvas

[Dirk Schulze]

Hi Markus,

Thanks for coming back with you implementation details. I think most of the 
suggestions make sense overall but I’ll look at them in more detail, especially 
regarding filter regions. Just a question to SVG filter references inline for 
now.


On Sep 29, 2014, at 7:20 PM, Markus Stange msta...@themasta.com wrote:

 Hi,
 
 I'd like to revive this discussion.
 
 On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:
 
 I would suggest a filter attribute that takes a list of filter operations
 similar to the CSS Image filter function[1]. Similar to shadows[2], each
 drawing operation would be filtered. The API looks like this:
 
 partial interface CanvasRenderingContext2D {
attribute DOMString filter;
 }
 
 A filter DOMString could looks like: “contrast(50%) blur(3px)”
 
 This approach sounds good to me, and it's what I've implemented for
 Firefox in bug 927892 [1]. The Firefox implementation is behind the
 preference canvas.filters.enabled which is currently off by default.
 
 Filter functions include a reference to a filter element and a
 specification of SVG filters[4]. I am unsure if a reference do an element
 within a document can cause problems. If it does, we would just not support
 SVG filter references.
 
 I've included support for SVG filters in the Firefox implementation.
 It's a bit of work and it increases the number of edge cases we need
 to specify, but I think it's worth it.
 
 Here's a more fleshed-out proposal that attempts to define the edge
 cases I've encountered during development.
 
 The ctx.filter property should behave like the ctx.font property in some 
 senses:
 - It's part of the state of the context and honors ctx.save() and
 ctx.restore().
 - Setting an invalid value is ignored silently.
 - Both inherit and initial are invalid values, as with font.
 - Setting a valid value sets the current state's filter to that
 value, and the getter will now return this value, possibly
 reserialized.
 Question: Do we want the getter to return the serialized form of the
 filter? I don't really mind either way, and I'm not sure in what cases
 the results would differ. I guess extraneous whitespace between
 individual filter functions would be cleaned up, and 0 length values
 would get set to 0px. Anything else?
 - Resetting the state to no filtering is done using ctx.filter =
 none. Values such as , null, or undefined are invalid and will be
 ignored and not unset the filter.
 Question: Is this what we want?
 
 Filter rendering should work similarly to shadow rendering:
 - It happens on every drawing operation, with the input to the filter
 being what that operation would have rendered regularly.
 - The transform of the context is applied during rendering of the
 input. The actual filtering is not be subject to the transform and
 happens in device space. This means that e.g. a drop-shadow(0px 10px
 black) filter always offsets the shadow towards the bottom, regardless
 of the transform.
 - The results in the canvas pixel buffer will be the same regardless
 of the CSS size of the canvas in the page, and regardless of whether
 the canvas element is in the page at all or just a detached DOM node.
 - The global composite operation is respected when compositing the
 filtered results into the canvas contents. The filter input drawing
 operation is always rendered with over into a conceptual transparent
 temporary surface.
 - The same applies for global alpha.
 
 Interaction with shadow:
 - If both a filter and a shadow are set on the canvas, filtering will
 happen first, with the shadow being applied to the filtered results.
 In that case the global composite operation will be respected when
 compositing the result with shadow into the canvas.
 - As a consequence of the other statements, this is true: If a valid
 filter is used, appending  drop-shadow(shadowOffsetXpx
 shadowOffsetYpx shadowBlurpx shadowColor) to the filter will
 have the same results as using the shadow properties, even if there is
 a transform on the context.
 
 Units:
 - The CSS px unit refers to one canvas pixel, independent of the CSS
 size of the canvas on the page. That is, a drop-shadow(0 10px black)
 filter will have the same results in the canvas-internal pixel buffer,
 regardless of whether that canvas is specified using canvas
 width=100 height=100 style=width: 100px; height: 100px; or
 canvas width=100 height=100 style=width: 20px; height: 20px;.
 - Lengths in non-px units refer to the number of canvas pixels you
 get if you convert the length to CSS px and interpret that number as
 canvas pixels.
 
 Font size relative units:
 - Lengths in em are relative to the font size of the canvas context
 as specified by ctx.font.
 - The same applies for lengths in ex; and those use the x-height of
 the font that's specified in ctx.font.
 
 SVG filter specific considerations:
 - Relative URLs in SVG filter reference url() functions are relative
 to the canvas element (i.e. the base URL of the owner 

Re: [whatwg] Support filters in Canvas

[Rik Cabanier]

On Mon, Sep 29, 2014 at 10:20 AM, Markus Stange msta...@themasta.com
wrote:

 Hi,

 I'd like to revive this discussion.

 On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:

  I would suggest a filter attribute that takes a list of filter operations
  similar to the CSS Image filter function[1]. Similar to shadows[2], each
  drawing operation would be filtered. The API looks like this:
 
  partial interface CanvasRenderingContext2D {
  attribute DOMString filter;
  }
 
  A filter DOMString could looks like: “contrast(50%) blur(3px)”

 This approach sounds good to me, and it's what I've implemented for
 Firefox in bug 927892 [1]. The Firefox implementation is behind the
 preference canvas.filters.enabled which is currently off by default.

  Filter functions include a reference to a filter element and a
  specification of SVG filters[4]. I am unsure if a reference do an element
  within a document can cause problems. If it does, we would just not
 support
  SVG filter references.

 I've included support for SVG filters in the Firefox implementation.
 It's a bit of work and it increases the number of edge cases we need
 to specify, but I think it's worth it.


Can we limit it to just the set of CSS filter shorthands for now?
I think other UA's are further behind in their implementation of
integrating SVG filters in their rendering pipeline.


 Here's a more fleshed-out proposal that attempts to define the edge
 cases I've encountered during development.

 The ctx.filter property should behave like the ctx.font property in some
 senses:
  - It's part of the state of the context and honors ctx.save() and
 ctx.restore().
  - Setting an invalid value is ignored silently.
  - Both inherit and initial are invalid values, as with font.
  - Setting a valid value sets the current state's filter to that
 value, and the getter will now return this value, possibly
 reserialized.
 Question: Do we want the getter to return the serialized form of the
 filter?


Since it's an attribute, it would be strange if it returns a different
string. It should return the same value that it was set to.


 I don't really mind either way, and I'm not sure in what cases
 the results would differ. I guess extraneous whitespace between
 individual filter functions would be cleaned up, and 0 length values
 would get set to 0px. Anything else?
 - Resetting the state to no filtering is done using ctx.filter =
 none. Values such as , null, or undefined are invalid and will be
 ignored and not unset the filter.
 Question: Is this what we want?

 Filter rendering should work similarly to shadow rendering:
  - It happens on every drawing operation, with the input to the filter
 being what that operation would have rendered regularly.
  - The transform of the context is applied during rendering of the
 input. The actual filtering is not be subject to the transform and
 happens in device space. This means that e.g. a drop-shadow(0px 10px
 black) filter always offsets the shadow towards the bottom, regardless
 of the transform.
  - The results in the canvas pixel buffer will be the same regardless
 of the CSS size of the canvas in the page, and regardless of whether
 the canvas element is in the page at all or just a detached DOM node.
  - The global composite operation is respected when compositing the
 filtered results into the canvas contents. The filter input drawing
 operation is always rendered with over into a conceptual transparent
 temporary surface.
  - The same applies for global alpha.

 Interaction with shadow:
  - If both a filter and a shadow are set on the canvas, filtering will
 happen first, with the shadow being applied to the filtered results.
 In that case the global composite operation will be respected when
 compositing the result with shadow into the canvas.
  - As a consequence of the other statements, this is true: If a valid
 filter is used, appending  drop-shadow(shadowOffsetXpx
 shadowOffsetYpx shadowBlurpx shadowColor) to the filter will
 have the same results as using the shadow properties, even if there is
 a transform on the context.


Since you can do a shadow with the filter attribute, maybe we can specify
that the shadow attribute is ignored?


 Units:
  - The CSS px unit refers to one canvas pixel, independent of the CSS
 size of the canvas on the page. That is, a drop-shadow(0 10px black)
 filter will have the same results in the canvas-internal pixel buffer,
 regardless of whether that canvas is specified using canvas
 width=100 height=100 style=width: 100px; height: 100px; or
 canvas width=100 height=100 style=width: 20px; height: 20px;.
  - Lengths in non-px units refer to the number of canvas pixels you
 get if you convert the length to CSS px and interpret that number as
 canvas pixels.

 Font size relative units:
  - Lengths in em are relative to the font size of the canvas context
 as specified by ctx.font.
  - The same applies for lengths in ex; and those use the x-height of
 

Re: [whatwg] Support filters in Canvas

[Markus Stange]

On Mon, Sep 29, 2014 at 8:09 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Sep 29, 2014, at 7:20 PM, Markus Stange msta...@themasta.com wrote:
 - For a feImage primitive, if the required image hasn't finished
 loading at the time of drawing, this feImage primitive renders
 transparent black.

 I think there is more than the asynch consideration. CSS does not have 
 setting for cross origin content. While it is planned, it simply isn’t there 
 yet. That means SVG filters can be loaded from pretty much any origin. I 
 wonder if this should taint the canvas. Have you though about this?

Good point! I hadn't thought about this. I don't see much point in
disallowing the use of cross-origin filters (who would put sensitive
data inside a filter?), but it certainly would be bad if one could
paint images from a different domain into the canvas using feImage
and then read the pixels. So cross-domain feImage loads should
certainly taint the canvas.

Markus

Re: [whatwg] Support filters in Canvas

[Markus Stange]

On Mon, Sep 29, 2014 at 8:12 PM, Rik Cabanier caban...@gmail.com wrote:


 On Mon, Sep 29, 2014 at 10:20 AM, Markus Stange msta...@themasta.com
 wrote:

 Hi,

 I'd like to revive this discussion.

 On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:

  I would suggest a filter attribute that takes a list of filter
  operations
  similar to the CSS Image filter function[1]. Similar to shadows[2], each
  drawing operation would be filtered. The API looks like this:
 
  partial interface CanvasRenderingContext2D {
  attribute DOMString filter;
  }
 
  A filter DOMString could looks like: “contrast(50%) blur(3px)”

 This approach sounds good to me, and it's what I've implemented for
 Firefox in bug 927892 [1]. The Firefox implementation is behind the
 preference canvas.filters.enabled which is currently off by default.

  Filter functions include a reference to a filter element and a
  specification of SVG filters[4]. I am unsure if a reference do an
  element
  within a document can cause problems. If it does, we would just not
  support
  SVG filter references.

 I've included support for SVG filters in the Firefox implementation.
 It's a bit of work and it increases the number of edge cases we need
 to specify, but I think it's worth it.


 Can we limit it to just the set of CSS filter shorthands for now?
 I think other UA's are further behind in their implementation of integrating
 SVG filters in their rendering pipeline.

Sure. In Firefox I can put CSS and SVG filters for canvas behind
different prefs so that we can enable the CSS part without exposing
the SVG part.



 Here's a more fleshed-out proposal that attempts to define the edge
 cases I've encountered during development.

 The ctx.filter property should behave like the ctx.font property in some
 senses:
  - It's part of the state of the context and honors ctx.save() and
 ctx.restore().
  - Setting an invalid value is ignored silently.
  - Both inherit and initial are invalid values, as with font.
  - Setting a valid value sets the current state's filter to that
 value, and the getter will now return this value, possibly
 reserialized.
 Question: Do we want the getter to return the serialized form of the
 filter?


 Since it's an attribute, it would be strange if it returns a different
 string. It should return the same value that it was set to.

I agree, returning the exact value that was assigned would be less
surprising. I brought this up because the font attribute does
something like this: Its getter returns a serialized value that
doesn't contain the line-height part, and also leaves out some
subproperty values that have default values.

 Interaction with shadow:
  - If both a filter and a shadow are set on the canvas, filtering will
 happen first, with the shadow being applied to the filtered results.
 In that case the global composite operation will be respected when
 compositing the result with shadow into the canvas.
  - As a consequence of the other statements, this is true: If a valid
 filter is used, appending  drop-shadow(shadowOffsetXpx
 shadowOffsetYpx shadowBlurpx shadowColor) to the filter will
 have the same results as using the shadow properties, even if there is
 a transform on the context.


 Since you can do a shadow with the filter attribute, maybe we can specify
 that the shadow attribute is ignored?

Hmm, we could do that but I don't really see the benefits. I think
it's more surprising to users when shadows stop working as soon as
they set a filter than if they just keep working.

Markus

Re: [whatwg] Support filters in Canvas

[Robert O'Callahan]

On Mon, Sep 29, 2014 at 2:12 PM, Rik Cabanier caban...@gmail.com wrote:

 Can we limit it to just the set of CSS filter shorthands for now?
 I think other UA's are further behind in their implementation of
 integrating SVG filters in their rendering pipeline.


How about we put CSS + SVG filters into the one spec draft for now, and
split them up into two drafts if we actually get to the point where vendors
want to ship one and not the other? It seems premature to create both HTML
Canvas Filters Level 1 and HTML Canvas Filters Level 2 at the same time.

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

Re: [whatwg] Support filters in Canvas

[Rik Cabanier]

On Mon, Sep 29, 2014 at 8:52 PM, Robert O'Callahan rob...@ocallahan.org
wrote:

 On Mon, Sep 29, 2014 at 2:12 PM, Rik Cabanier caban...@gmail.com wrote:

 Can we limit it to just the set of CSS filter shorthands for now?
 I think other UA's are further behind in their implementation of
 integrating SVG filters in their rendering pipeline.


 How about we put CSS + SVG filters into the one spec draft for now, and
 split them up into two drafts if we actually get to the point where vendors
 want to ship one and not the other? It seems premature to create both HTML
 Canvas Filters Level 1 and HTML Canvas Filters Level 2 at the same time.


Are you proposing that this is developed as a separate spec and not as an
addition to the canvas specification?

Re: [whatwg] Support filters in Canvas

[Rik Cabanier]

On Sat, Mar 15, 2014 at 12:03 AM, Dirk Schulze dschu...@adobe.com wrote:

 Hi,

 Apologize if it was already discussed but I couldn't find a mail to this
 topic.


Yes, this was brought up a couple of times.
Last exchange was in Sept of 2012 (!):
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037432.html


 In one of the early drafts of Filter Effects we had filter operation
 support for HTML Canvas. We deferred it and IMO it makes more sense to have
 it as part of the Canvas specification text.

 I would suggest a filter attribute that takes a list of filter operations
 similar to the CSS Image filter function[1]. Similar to shadows[2], each
 drawing operation would be filtered. The API looks like this:

 partial interface CanvasRenderingContext2D {
 attribute DOMString filter;
 }

 A filter DOMString could looks like: contrast(50%) blur(3px)

 With the combination of grouping in canvas[3] it would be possible to
 group drawing operations and filter them together.

 Filter functions include a reference to a filter element and a
 specification of SVG filters[4]. I am unsure if a reference do an element
 within a document can cause problems. If it does, we would just not support
 SVG filter references.


Yes, I'd prefer if we supported just the CSS filter shorthands for now.