Starting implementation on W3C Filter Effects
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification. https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe. Here's the tracking bugzilla: https://bugs.webkit.org/show_bug.cgi?id=68469 It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name. The implementation plan that I have in mind is: - start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?) Dean
I was actually considering removing ENABLE(FILTERS) since it seemed to be on everywhere. It would probably be better for us to remove it first and this feature to exist under its own define (if it even needs a define?). If you'll want folks to be able to turn this off w/o affecting their existing shipping configurations, you'd need a new define. But I'm also not sure anyone will need to turn it off. I leave that up to you. :) -eric On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson <dino@apple.com> wrote:
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.
Here's the tracking bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=68469
It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name.
The implementation plan that I have in mind is:
- start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix
In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?)
Dean
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On 23/09/2011, at 4:38 AM, Eric Seidel wrote:
I was actually considering removing ENABLE(FILTERS) since it seemed to be on everywhere.
Sorry to bring bad news, but Apple currently turns off ENABLE(FILTERS) on desktop and iOS.
It would probably be better for us to remove it first and this feature to exist under its own define (if it even needs a define?).
If you'll want folks to be able to turn this off w/o affecting their existing shipping configurations, you'd need a new define. But I'm also not sure anyone will need to turn it off. I leave that up to you. :)
I don't mind either way. I'll take this message as a suggestion to add a new define, at least for the moment. Dean
-eric
On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson <dino@apple.com> wrote:
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.
Here's the tracking bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=68469
It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name.
The implementation plan that I have in mind is:
- start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix
In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?)
Dean
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Thu, Sep 22, 2011 at 11:44 AM, Dean Jackson <dino@apple.com> wrote:
On 23/09/2011, at 4:38 AM, Eric Seidel wrote:
I was actually considering removing ENABLE(FILTERS) since it seemed to be on everywhere.
Sorry to bring bad news, but Apple currently turns off ENABLE(FILTERS) on desktop and iOS.
In that case, please disregard my previous message. I was misinformed. :) Adam
It would probably be better for us to remove it first and this feature to exist under its own define (if it even needs a define?).
If you'll want folks to be able to turn this off w/o affecting their existing shipping configurations, you'd need a new define. But I'm also not sure anyone will need to turn it off. I leave that up to you. :)
I don't mind either way. I'll take this message as a suggestion to add a new define, at least for the moment.
Dean
-eric
On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson <dino@apple.com> wrote:
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.
Here's the tracking bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=68469
It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name.
The implementation plan that I have in mind is:
- start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix
In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?)
Dean
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Thu, Sep 22, 2011 at 11:44 AM, Dean Jackson <dino@apple.com> wrote:
On 23/09/2011, at 4:38 AM, Eric Seidel wrote:
I was actually considering removing ENABLE(FILTERS) since it seemed to be on everywhere.
Sorry to bring bad news, but Apple currently turns off ENABLE(FILTERS) on desktop and iOS.
I guess I'm misinformed. Oops. We should probably fix the defaults: http://trac.webkit.org/browser/trunk/Tools/Scripts/build-webkit#L184 This makes me think they're enabled for Mac, but not windows? http://trac.webkit.org/browser/trunk/Source/WebCore/Configurations/FeatureDe... In either case, this seems like excellent prompting to clean up ENABLE_FILTERS and add something new for these CSS_FILTERS.
It would probably be better for us to remove it first and this feature to exist under its own define (if it even needs a define?).
If you'll want folks to be able to turn this off w/o affecting their existing shipping configurations, you'd need a new define. But I'm also not sure anyone will need to turn it off. I leave that up to you. :)
I don't mind either way. I'll take this message as a suggestion to add a new define, at least for the moment.
Dean
-eric
On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson <dino@apple.com> wrote:
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.
Here's the tracking bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=68469
It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name.
The implementation plan that I have in mind is:
- start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix
In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?)
Dean
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
The settings in TOT are the settings for nightly builds. They don't necessarily make it clear what Apple does for releases. There are features like this one that we’ve been turning off on release branches. -- Darin
Dean, do you want to reuse the existing filter code, or do you plan to write another filter implementation just for CSS? Would be interesting if we would need to nest CSS_FILTERS and FILTERS, or if they could get enabled independent of each other. Like previous comments mention, Apple still does not enable SVG Filters for Safari or Safari mobile. Once you reuse some code and enable CSS_ENABLE, it would force FILTERS to get enabled as well. Cheers Dirk Am 22.09.2011 um 22:06 schrieb Darin Adler:
The settings in TOT are the settings for nightly builds. They don't necessarily make it clear what Apple does for releases. There are features like this one that we’ve been turning off on release branches.
-- Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hey Dirk, On 23/09/2011, at 6:24 AM, Dirk Schulze wrote:
Dean, do you want to reuse the existing filter code, or do you plan to write another filter implementation just for CSS? Would be interesting if we would need to nest CSS_FILTERS and FILTERS, or if they could get enabled independent of each other.
I plan to use the existing filter code. It's nicely neutral of SVG. This would mean that CSS_FILTERS does require FILTERS, but I could also change the #ifs to use ||. BTW - the Filter Effects specification (ENABLE_CSS_FILTERS) does support "What was previously known as SVG Filters" (ENABLE_FILTERS), so there is a dependency. When hardware acceleration comes we'll obviously begin diverging. As you mentioned elsewhere, buried in the depths of SVN is a Core Image-based version.
Like previous comments mention, Apple still does not enable SVG Filters for Safari or Safari mobile. Once you reuse some code and enable CSS_ENABLE, it would force FILTERS to get enabled as well.
That's right. This new specification is mostly adding some new syntax and exposing filters to HTML/CSS. Dean
Interesting. It is unfortunate that we currently have no easy way to tell which ports are shipping with which defines enabled. I didn't think to check the settings on the branch. Thank you for the clarification. -eric On Thu, Sep 22, 2011 at 1:06 PM, Darin Adler <darin@apple.com> wrote:
The settings in TOT are the settings for nightly builds. They don't necessarily make it clear what Apple does for releases. There are features like this one that we’ve been turning off on release branches.
-- Darin
Maybe the best course of action is to remove ENABLE(FILTERS) by always enabling the code and then have the CSS API for filters developed behind ENABLE(CSS_FILTERS)? Adam On Thu, Sep 22, 2011 at 11:38 AM, Eric Seidel <eric@webkit.org> wrote:
I was actually considering removing ENABLE(FILTERS) since it seemed to be on everywhere. It would probably be better for us to remove it first and this feature to exist under its own define (if it even needs a define?).
If you'll want folks to be able to turn this off w/o affecting their existing shipping configurations, you'd need a new define. But I'm also not sure anyone will need to turn it off. I leave that up to you. :)
-eric
On Thu, Sep 22, 2011 at 11:30 AM, Dean Jackson <dino@apple.com> wrote:
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.
Here's the tracking bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=68469
It will be protected by the existing ENABLE(FILTERS), unless someone has a good reason why this should be a new enabled feature name.
The implementation plan that I have in mind is:
- start with '-webkit-filter' only for HTML elements that supports something similar to the existing 'filter' - implement more of the spec, including the shorthands - expose '-webkit-filter' to SVG, but only if the existing 'filter' property is not set - wait for the spec to progress, then drop the prefix
In parallel we'll also be looking at animation of these effects, plus hardware acceleration (open questions to how: OpenCL? Graphics3D? Core Image where available?)
Dean
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On 22/09/2011, at 11:30 AM, Dean Jackson wrote:
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.
A followup: we're going to start work on the CSS Shaders proposal [1] soon. Adobe have published their implementation which was specific to Chromium, and we'll be working with them to split it into small patches that can land in the coming weeks. A good introduction to the technology is [2]. This will be done behind the ENABLE_CSS_FILTERS macro, but also with the guards for ENABLE_WEBGL since the implementation (and security) requirements are so similar. Dean [1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html [2] www.adobe.com/devnet/html5/articles/css-shaders.html
On 24/10/2011, at 9:02 PM, Dean Jackson wrote:
On 22/09/2011, at 11:30 AM, Dean Jackson wrote:
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.
A followup: we're going to start work on the CSS Shaders proposal [1] soon. Adobe have published their implementation which was specific to Chromium, and we'll be working with them to split it into small patches that can land in the coming weeks. A good introduction to the technology is [2].
This will be done behind the ENABLE_CSS_FILTERS macro, but also with the guards for ENABLE_WEBGL since the implementation (and security) requirements are so similar.
As requested by Adam, this is now ENABLE_CSS_SHADERS and landed yesterday: http://trac.webkit.org/changeset/99118 Dean
Dean, could you implement the filters on top of shaders if the target has WEBGL acceleration? Doing animated filters in software will be slow unless you spend a significant amount of time on coding SSE or NEON instructions. Rik On Mon, Oct 24, 2011 at 9:02 PM, Dean Jackson <dino@apple.com> wrote:
On 22/09/2011, at 11:30 AM, Dean Jackson wrote:
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.
A followup: we're going to start work on the CSS Shaders proposal [1] soon. Adobe have published their implementation which was specific to Chromium, and we'll be working with them to split it into small patches that can land in the coming weeks. A good introduction to the technology is [2].
This will be done behind the ENABLE_CSS_FILTERS macro, but also with the guards for ENABLE_WEBGL since the implementation (and security) requirements are so similar.
Dean
[1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html [2] www.adobe.com/devnet/html5/articles/css-shaders.html
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
In my experience, implementing filters leads to writing them multiple times for various targets. I suggest starting with the lowest common denominator before targeting platforms like webgl. I understand that Google is working on an in-software webgl implementation (angle is just a conversion lib); at some point LLVM may have sufficient semantics-- it's certainly been attempted (there's a polyhedron article somewhere on the site). Anyway, my two cents. Best of luck! -Charles On Nov 3, 2011, at 5:02 PM, Rik Cabanier <cabanier@gmail.com> wrote:
Dean,
could you implement the filters on top of shaders if the target has WEBGL acceleration? Doing animated filters in software will be slow unless you spend a significant amount of time on coding SSE or NEON instructions.
Rik
On Mon, Oct 24, 2011 at 9:02 PM, Dean Jackson <dino@apple.com> wrote:
On 22/09/2011, at 11:30 AM, Dean Jackson wrote:
Dirk (known in these parts as krit) reminded me that I had not emailed webkit-dev about the plans to start an implementation of W3C's new Filter Effects specification.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html
The quick summary is that this exposes the 'filter' property from SVG to everything in CSS, and adds some shorthands for common effects so people don't have to write XML in order to do something like a blur or sepia effect. The spec has received a fair amount of input from the CSS and SVG working groups, and particularly from Apple, Google, Mozilla, Opera and Adobe.
A followup: we're going to start work on the CSS Shaders proposal [1] soon. Adobe have published their implementation which was specific to Chromium, and we'll be working with them to split it into small patches that can land in the coming weeks. A good introduction to the technology is [2].
This will be done behind the ENABLE_CSS_FILTERS macro, but also with the guards for ENABLE_WEBGL since the implementation (and security) requirements are so similar.
Dean
[1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html [2] www.adobe.com/devnet/html5/articles/css-shaders.html
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Nov 3, 2011, at 7:00 PM, Charles Pritchard wrote:
In my experience, implementing filters leads to writing them multiple times for various targets.
I suggest starting with the lowest common denominator before targeting platforms like webgl. I understand that Google is working on an in-software webgl implementation (angle is just a conversion lib); at some point LLVM may have sufficient semantics-- it's certainly been attempted (there's a polyhedron article somewhere on the site).
You're saying you believe Google is developing a version of WebGL that runs completely in the CPU? I haven't heard of such a thing and I would be surprised if it were true. Running a GLSL shader in software is possible, in fact OSX has a software renderer that does just that. And while it can get a few fps with a simple shader, it's not practical for serious realtime 3D graphics. The initial WebKit implementation of CSS filters will use the filter code already in the SVG implementation. This does use vector optimizations on some platforms for some shaders. So it will be fully CPU based. From there several options exist for hardware acceleration, some platform specific and others more generic, based on WebGL or some other GPU based acceleration. In https://bugs.webkit.org/show_bug.cgi?id=68479 I plan on adding some filter infrastructure at the GraphicsLayer level to make it simpler to implement layer-based hardware accelerated filters. ----- ~Chris cmarrin@apple.com
On 11/4/11 7:23 AM, Chris Marrin wrote:
On Nov 3, 2011, at 7:00 PM, Charles Pritchard wrote:
In my experience, implementing filters leads to writing them multiple times for various targets.
I suggest starting with the lowest common denominator before targeting platforms like webgl. I understand that Google is working on an in-software webgl implementation (angle is just a conversion lib); at some point LLVM may have sufficient semantics-- it's certainly been attempted (there's a polyhedron article somewhere on the site).
You're saying you believe Google is developing a version of WebGL that runs completely in the CPU? I haven't heard of such a thing and I would be surprised if it were true. Running a GLSL shader in software is possible, in fact OSX has a software renderer that does just that. And while it can get a few fps with a simple shader, it's not practical for serious realtime 3D graphics.
http://code.google.com/p/chromium/issues/detail?id=91445 "a software fallback is in the works" Similarly, here's WebGL implemented in Canvas 2d and ECMAScript: http://code.google.com/p/cwebgl/ It's certainly the case that CPU rendering will not be practical for "serious realtime 3D graphics". There's absolutely a divide between computers that have sufficient GPUs and ones that do not.
The initial WebKit implementation of CSS filters will use the filter code already in the SVG implementation. This does use vector optimizations on some platforms for some shaders. So it will be fully CPU based. From there several options exist for hardware acceleration, some platform specific and others more generic, based on WebGL or some other GPU based acceleration. I'm a bit behind on the bleeding edge: Is there work / a foundation for running these rendering process across multiple cores?
In https://bugs.webkit.org/show_bug.cgi?id=68479 I plan on adding some filter infrastructure at the GraphicsLayer level to make it simpler to implement layer-based hardware accelerated filters.
Much appreciated. -Charles
participants (8)
-
Adam Barth
-
Charles Pritchard
-
Chris Marrin
-
Darin Adler
-
Dean Jackson
-
Dirk Schulze
-
Eric Seidel
-
Rik Cabanier