Intent to Deprecate: -webkit-canvas and Document.getCSSCanvasContext

[Chris Harrelson]

Primary eng (and PM) emails

chri...@chromium.org

Summary

-webkit-canvas is a non-standard CSS property that allows one to use a canvas to draw the background of an element. See here for documentation on the original launch of this feature and an indication of how it can be used.

Motivation

The CSS Houdini effort aims to provide a much better way to implement the same thing, via the Custom Paint feature. In addition, -webkit-canvas is non-standard, and many common use cases found are better implemented as SVG (see these examples of internal Chrome usage, for example).

Compatibility Risk

Low. It is a WebKit/Blink-specific feature.

Alternative implementation suggestion for web developers

Use SVG for static images. For dynamic ones, use transparency with a real canvas element behind the element.

Usage information from UseCounter

Current usage is about ~0.05%. Some of this usage comes from Chrome internal UIs for bookmarks, the (old?) ChromeOS file manager, and one or two more obscure cases. It may even constitute the majority of use, which would explain it going down over time since the above use cases are for older-generation Chrome UIs that are being phased out.

Entry on chromestatus.com, crbug.com, or MDN

crbug.com/475655

Requesting approval to remove too?

Ideally yes, but only if we can prove that most usage is from Chrome UI.

[Elliott Sprehn]

lgtm, we should fix the internal usage and see what it does to the metrics. I didn't think internal UI was counted in use counters...

[Chris Harrelson]

On Mon, Apr 20, 2015 at 3:50 PM, Elliott Sprehn <esp...@chromium.org> wrote:

lgtm, we should fix the internal usage and see what it does to the metrics. I didn't think internal UI was counted in use counters...

I actually don't know if it is, but assume so. Does anyone know?

[Justin Novosad]

FYI, this API regressed recently and it caused important stuff to fail. See crbug.com/477830

Before considering deprecation we need to take a closer look at how websites are using this. Presumably, they have workarounds or polyfills for non-WK/blink browsers. Do we know if those fallbacks work well in Chrome?  Do we currently have a good alternative to propose for developpers currently using this? If not, should we wait for the Custom Paint feature to ship before deprecating this?

[Shane Stephens]

Also worth noting: this functionality (though not the API) is currently being standardized in CSS Images 4 (http://drafts.csswg.org/css-images-4):

<style>

.thingToPaintCanvasInto {

  background-image: element(#id-of-out-of-dom-canvas);

}

</style>

<script>

var canvas = document.createElement('canvas');

CSS.elementSources.set("id-of-out-of-dom-canvas", canvas);

</script>

etc.

Cheers,

    -Shane

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Shane Stephens]

Wrong link, sorry - use http://dev.w3.org/csswg/css-images-4/.

Cheers,

    -Shane

[Justin Novosad]

The element() notation is almost a drop-in replacement for -webkit-canvas (and more). Once that ships, this deprecation is a no brainer IMHO.

Chris, is this feature getting in the way of slimming paint?

[Dirk Schulze]

I saw -webkit-canvas() in use for slides or buttons. For slides I saw demos where WebGL was used to animate the background. The animation was not semantic and therefore shouldn’t be an element IMO.

Providing an alternative with element() first sounds like a good idea to me.

Greetings,

Dirk

[Philip Jägenstedt]

LGTM to deprecate. Even if we wait for element() before removing -webkit-canvas and getCSSCanvasContext(), deprecating it early has the potential to drive down usage a little. (This rarely happens, but sometimes usage drops for mysterious reasons, and the influence of deprecation cannot be excluded.)

Making very sure that the use counters aren't hit for internal UI sounds like a good idea. At first glance, I'd expect that both use counters would be hit for internal usage, unless there's some high-level code that suppresses all use counters for internal pages.

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Justin Novosad]

Another thing to consider: Because this feature is supported on both Android and iOS webviews, I would bet it has a lot more usage in mobile webview apps (including PhoneGap, Cordova, etc.) compared to the open web. Webview apps also use canvases a lot more frequently than websites do. Because web code in packaged apps typically runs in a webview rather than Chrome, it falls outside of the scope of usage statistics collection. Of all the selection biases that exist in our stats collection, this may be the most problematic one because webview apps may have completely different feature usage patterns since they are not constrained by browser compatibility issues the way web sites are.

We learned a lesson about this couple weeks ago with the removal of the "darker" compositing mode. Measured usage on the open web was dismal, but the feature removal made hundreds of Android apps unusable when the webview implementation was swapped from under them. We were lucky to catch this in the last days of beta. Fixing installed apps is not as fast as fixing server-side code because even if the developer fixes the issue quickly, it takes a many weeks before the vast majority of users have downloaded and installed the application update. Anyways, this is not a concern as far as deprecation is concerned, just something to keep in mind when it is time for removal. The biggest mistake we made in that case was to rely on web usage stats to justify removing without deprecating first (my bad).  Because canvases are so heavily used in webview apps, and we have no usage stats for them, I think that not only should deprecation be mandatory, but we should observe longer than normal deprecation windows for canvas features, and any-other type of feature that is used heavily in packaged apps.  Running in the dark is dangerous.

   -Justin

[Eric Bidelman]

I'd really like to see an implementation of element() before we replace -webkit-canvas(). As stated on the bug, there are some large sites, including Google's own that are using it. As Justin said, it's possible there are many more in the webview world. 

If there's a better API replacement in the pipeline, it would be nice to give developers that API before removing a feature. Otherwise we put them in limbo.

[Rik Cabanier]

On Tue, Apr 21, 2015 at 7:44 AM, Justin Novosad <ju...@chromium.org> wrote:

Another thing to consider: Because this feature is supported on both Android and iOS webviews, I would bet it has a lot more usage in mobile webview apps (including PhoneGap, Cordova, etc.) compared to the open web. Webview apps also use canvases a lot more frequently than websites do. Because web code in packaged apps typically runs in a webview rather than Chrome, it falls outside of the scope of usage statistics collection. Of all the selection biases that exist in our stats collection, this may be the most problematic one because webview apps may have completely different feature usage patterns since they are not constrained by browser compatibility issues the way web sites are.

We learned a lesson about this couple weeks ago with the removal of the "darker" compositing mode. Measured usage on the open web was dismal, but the feature removal made hundreds of Android apps unusable when the webview implementation was swapped from under them. We were lucky to catch this in the last days of beta. Fixing installed apps is not as fast as fixing server-side code because even if the developer fixes the issue quickly, it takes a many weeks before the vast majority of users have downloaded and installed the application update. Anyways, this is not a concern as far as deprecation is concerned, just something to keep in mind when it is time for removal. The biggest mistake we made in that case was to rely on web usage stats to justify removing without deprecating first (my bad).  Because canvases are so heavily used in webview apps, and we have no usage stats for them, I think that not only should deprecation be mandatory, but we should observe longer than normal deprecation windows for canvas features, and any-other type of feature that is used heavily in packaged apps.  Running in the dark is dangerous.

Is there a way to measure what APIs apps are using? If not, maybe this should be added to android (or could it be part of the app submission process?)

[Mikhail Naganov]

That's a very important point, thanks for bringing this up!

We can't do much for iOS WebView, as it is based on WebKit, not Blink, so it can be safely taken off the table.

As for Android WebView, the technical culprit right now is that UMA stats sending code is in the chrome layer of Chromium, while WebView only uses the content layer + components. Thus, the first thing that needs to be done is to componentize it. We also need to consider privacy issues, as WebView works in third-party apps.

Currently, beta-testing with upcoming WebView apks is the only viable option.

[PhistucK]

Is it possible to ask the Google Play and Chrome Web Store teams to scan the existing APKs and CRXs (extract all of the files, grep for webkit-canvas)?

This, along with an internal Google index search will give us a pretty good indication (it is not an absolute one, since the content may be served from an online source) of the actual state of affairs, I reckon.

☆PhistucK

[Chris Harrelson]

Re: why deprecate this now? Is it blocking Slimming Paint?

It is not blocking Slimming Paint. My motivation to remove support for it now is that it is:

(a) non-standard (enough said)

(b) currently a unique type of code path (leading to bugs like crbug.com/474905)

(c) will be replaced with a different mechanism, and

(d) appears to have low enough usage to try to kill it.

Re sites using it: I'd appreciate any examples anyone can provide, in order to understand all the use cases. However, failing finding very compelling use cases, I don't see a good argument to not remove the feature. And yes, we do need to look closely at WebView usage to see if it is significant.

I'm currently looking into the https://www.icloud.com/#photos use case.

[Mikhail Naganov]

> Is it possible to ask the Google Play and Chrome Web Store teams to scan the existing APKs and CRXs (extract all of the files, grep for webkit-canvas)?

We are working on this (for Google Play), so we should be able to provide such evaluations in near future.

[一丝冰凉]

 element() +1

[Chris Harrelson]

icloud.com uses -webkit-canvas to draw a blurred canvas on the photos homepage, and also the icon for the calendar app in the main menu at icloud.com. In both cases, one can just use <canvas> instead, proof being that the site works fine in Firefox.

I would like to proceed with this deprecation (but not removal) now, and we'll see how it goes (LGTMs technically not needed for a deprecation).

[theinn...@gmail.com]

Was this removed from android webview??, because i have noticed my cordova web apps are now failing saying that document.getCSSCanvasContext is not a function

Rick

[Torne (Richard Coles)]

Yes, this was removed from all Chromium platforms (including WebView) in M48

[desert...@gmail.com]

Could someone post a link to a JS Fiddle that replicates this deprecated behavior? I cannot find anyway to do it, and stackoverflow can't either (without toDataURL which we all know doesn't work for animation): https://stackoverflow.com/questions/3397334/use-canvas-as-a-css-background#_=_

[Chris Harrelson]

On Wed, Mar 29, 2017 at 3:54 PM, <desert...@gmail.com> wrote:

Could someone post a link to a JS Fiddle that replicates this deprecated behavior? I cannot find anyway to do it, and stackoverflow can't either (without toDataURL which we all know doesn't work for animation): https://stackoverflow.com/questions/3397334/use-canvas-as-a-css-background#_=_

Hi,

Could you use a <canvas> element directly where you used to have an element with a CSS Canvas applied to it?

Regards,

Chris

 

On Monday, April 20, 2015 at 3:34:34 PM UTC-7, Chris Harrelson wrote:

Primary eng (and PM) emails

chri...@chromium.org

Summary

-webkit-canvas is a non-standard CSS property that allows one to use a canvas to draw the background of an element. See here for documentation on the original launch of this feature and an indication of how it can be used.

Motivation

The CSS Houdini effort aims to provide a much better way to implement the same thing, via the Custom Paint feature. In addition, -webkit-canvas is non-standard, and many common use cases found are better implemented as SVG (see these examples of internal Chrome usage, for example).

Compatibility Risk

Low. It is a WebKit/Blink-specific feature.

Alternative implementation suggestion for web developers

Use SVG for static images. For dynamic ones, use transparency with a real canvas element behind the element.

Usage information from UseCounter

Current usage is about ~0.05%. Some of this usage comes from Chrome internal UIs for bookmarks, the (old?) ChromeOS file manager, and one or two more obscure cases. It may even constitute the majority of use, which would explain it going down over time since the above use cases are for older-generation Chrome UIs that are being phased out.

Entry on chromestatus.com, crbug.com, or MDN

crbug.com/475655

Requesting approval to remove too?

Ideally yes, but only if we can prove that most usage is from Chrome UI.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[lennart....@gmail.com]

This has to be the dumbest thing ever.

This feature alone made it possible to write high-speed platform games, by separating the background from the foreground.

Transparent elements are so slow that doing parallax scrolling + tile-map is pretty much useless on anything but a desktop PC.

Some times i wonder, are the developers just randomly exploring or do they have a strategy to make HTML/JS the powerful media platform it could be?

This was such an elegant solution -- yet you removed it. Just way to go..

[Chris Harrelson]

Thank you for your feedback, but please be aware of our code of conduct, and in particular, please make sure to keep conversations respectful and constructive.

Could you please file a bug at crbug.com/new with the use case you are describing, and as much information as you have about why the currently shipped solutions are slow? That will help us understand your use-case better.

Regards,

Chris

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/226a77bb-ba9a-489e-8474-812149c4fb12%40chromium.org.

[Daniel Bratell]

(Seconding what Chris said)

This was 3 years ago but I want to double check that we still have the problem that the use counters are under-representing features used on sites where you spend a lot of time without loading new pages? Like games.

If so then we need to be extra careful when interpreting usage umbers for features that might typically be used by such web applications.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw--3GmST_8GM8p71CXkjcAMyxF4CaX9Re-Q%2BOysYF88yQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[bug...@gmail.com]

We have a web application with a lot of small canvasses with animating graphics

We noticed that it is a lot faster to have a single canvas, instead of multiple ones, even when the same amount of graphics painted. 

For example, drawing 40x40 rectangles in a 640px canvas can be done easily at 60 frames per second on my PC using Chrome 73.

https://codepen.io/Ziriax/full/pYYXMQ

However, drawing 1 rectangle in 40x40 canvasses each 16px, performance drops to 3 frames per second, that is almost 20 times slower! 

https://codepen.io/Ziriax/full/Rddzxa

In our application the small canvasses are interspersed with other DOM elements and SVG, so we can't easily just paint everything to a single canvas.

Now that `--webkit-canvas` is missing, I guess the web API doesn't provide anything anymore to handle this case efficiently? 

If the browser would virtualize each canvas, then there shouldn't be much difference between 40x40 rects in one canvas or 1 rect in 40x40 canvasses, but it seems each canvas becomes a separate hardware GPU render-target, and no draw calls are getting batched anymore?

[Philip Jägenstedt]

Hi Peter,

Have you tried the CSS Painting API, CSS.paintWorklet? Perhaps the performance of that will be better than lots of little canvases?

Also, given that -webkit-canvas was never supported in Firefox, do you have a codepath that supports Firefox?

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6aef53b7-2ac3-47b1-96cf-88884710e07d%40chromium.org.

[bug...@gmail.com]

Hi Philip,

Thanks for the fast response, appreciated!

We haven't tried the CSS Painting API yet, that certainly looks promising (I need to figure out how to pass custom data to the painting API).

Firefox always has CSS element (very similar to Microsoft's WPF VisualBrush), I guess that would work.

But our application (called ViKiD, a STEM app for schools funded by the Flemish government), is initially only going to work on Chrome anyway, tackling other platforms after our initial beta-release. 

Many years ago when researching if we could use the web for this graphics intense app, I found the `--webkit-canvas` extension, and that was the perfect tool for the job. I hope the CSS painting API can help us out here, otherwise we will need nasty trickery, and something like NoesisGUI with WASM might be better in the end.

Thanks again,

Peter