[mysteryDate]

Well, there's this and the fact that browser implementers all need to come to consensus over what features to add and that's an extremely difficult process to move forward. There also is one big browser implementer who doesn't really want the "playful web" to exist and would prefer that everyone live inside of apps.

Edit: To be clear, we all work together and mostly get along. It's a long and arduous process to reach consensus and not everyone's incentives are aligned and this can be frustrating.

[robertoandred]

Your post implies that Google cares about browser consensus. For example, "This feature has been in Firefox for a while and we're finally making it part of the canvas spec." Google DOES NOT decide what the spec is. "You" don't make something part of the spec.

The Chrome team's hubris is insulting to the web.

[dmitriid]

> There also is one big browser implementer who doesn't really _want_ the "playful web" to exist and would prefer that everyone live inside of apps.

No. There's one humongous browser implementer who couldn't care less about consensus or what other browser vendors think. This vendors ships literally hundreds of new APIs every year and pretends they are now standards that everyone else must implement.

Too bad developers believe them.

BTW, it only took only 8 minutes for my countdown to reach zero: https://news.ycombinator.com/item?id=30555034

[robertoandred]

Don't you know? The "playful web" means websites getting access to your USB devices or being able to keep your screen from sleeping/locking!

[dmitriid]

Someone linked "Request for position" on these APIs: https://github.com/mozilla/standards-positions/issues/519#is...

Here's Mozilla's response:

--- start quote ---

4x4 transforms:

There are a bunch of implementation concerns here (and mentioned on that issue) with regards to availability on various native 2d backends... Needs more investigation

SVG filter interface:

We would really rather people use WebGL if you want fast/efficient filters. (I made a number of comments on that issue) As is, we're generally against this one for the time being

--- end quote ---

There's literally zero response on that from @mysteryDate who is now gaslighting Safari in the comment above, and presenting these API additions as fait accompli.

Honestly, at this point any time I see any public Chrome person write anything I immediately assume it's a distortion of reality at best and a blatant lie at worst. And this is always the case.

But sure. "Safari is the bad guy".

[mysteryDate]

There was a ton of work across browser vendors to make this a part of spec:

https://html.spec.whatwg.org/multipage/canvas.html#the-canva...

It's all there. It's all official. That github page was just one part of reaching consensus. There's also TAG review:

https://github.com/w3ctag/design-reviews/issues/627

FWIW Mozilla and Safari signed off on all of these changes at some point in time somewhere, hence why it's allowed to be part of spec. There were some changes that were not allowed to be part of the new API because one of those two said no (like perspective transforms, conic curves).

For jdashg's concerns on that thread, 4x4 matrices were cancelled, and you can follow up with much more debate from all parties on roundRect and filters:

http://github.com/whatwg/html/pull/6763 https://github.com/whatwg/html/pull/6765

This is certainly not decided by fiat. Working to find consensus across browser implementers is just a ton of work.

[dmitriid]

> It's all there. It's all official.

> FWIW Mozilla and Safari signed off on all of these changes at some point in time

That's a relief then. Too often these days "it's official it's in the spec" as presented by Chrome is anything but.

> This is certainly not decided by fiat.

There are too many cases when it's decided unilaterally by Chrome.

[rikroots]

> We would really rather people use WebGL if you want fast/efficient filters.

This one made me laugh. Yes, WebGL excels at pixel manipulations but it is possible to write fast and efficient filters to work in the 2D canvas environment.

For a case-in-point, I struggled for a long time to find a decent, fast implementation of a gaussian blur filter for my canvas library. Then I stumbled upon a JS implementation[1] based on some very clever work done by Intel devs which blew all my previous attempts out of the water - so of course I stole it (even though I still don't understand the approach they take)[2].

> "Safari is the bad guy"

As much as Safari often brings me to despair, I do like the work they've recently done to add color space support in CSS. They haven't yet pushed the functionality over to the canvas element, but I live in hope. For now, I have to emulate the calculations to get them working for my library[3].

[1] - https://github.com/nodeca/glur/blob/master/index.js

[2] - https://scrawl-v8.rikweb.org.uk/docs/source/factory/filterEn...

[3] - https://scrawl-v8.rikweb.org.uk/demo/canvas-059.html

[mysteryDate]

Oh yeah! Safari is definitely doing great for colorspaces and we have some work to do to catch up. Very good point.

[DonHopkins]

Cool, interesting links to code -- thank you! I chased down Intel's paper the code linked to describing how it works on archive.org.

https://web.archive.org/web/20110317025924/https://software....

It's not just about using SIMD instructions (they help), and laying out memory to optimize cache performance (which also helps), but most importantly that Gaussian blur is a "separable filter" that you can break up into a horizontal and vertical pass, each of which require a lot fewer memory references (on the order of just two times the number of pixels times the kernel size, instead of the number of pixels times the kernel size squared):

IIR Gaussian Blur Filter Implementation using Intel® Advanced Vector Extensions

>This white paper proposes an implementation for the Infinite Impulse Response (IIR) Gaussian blur filter [1] [2] [3] using Intel® Advanced Vector Extensions (Intel® AVX) instructions. [...]

>The IIR Gaussian blur filter applies equation (1) on each pixel through two sequential passes: The horizontal pass: This pass processes the input image left-to-right (row-wise), then right-to-left. The output of the left-to-right pass is added to the right-to-left pass.

>The vertical pass: Usually, the vertical pass processes the output from the horizontal pass top-to-bottom (column-wise), and then bottom-to-top. Accessing the input column-wise leads to a lot of cache blocks and impacts the performance of the filter. To avoid this, the horizontal pass transposes the output before writing to the output buffer. It makes the vertical pass similar to the horizontal pass and processes the intermediate output left-to-right, then right-to-left. The vertical pass again transposes the final output before writing the blurred image.

https://bartwronski.com/2020/02/03/separate-your-filters-svd...

>Separate your filters! Separability, SVD and low-rank approximation of 2D image processing filters Posted on February 3, 2020 by bartwronski

>In this blog post, I explore concepts around separable convolutional image filters: how can we check if a 2D filter (like convolution, blur, sharpening, feature detector) is separable, and how to compute separable approximations to any arbitrary 2D filter represented in a numerical / matrix form. I’m not covering any genuinely new research, but think it’s a really cool, fun, visual, interesting, and very practical topic, while being mostly unknown in the computer graphics community.

https://en.wikipedia.org/wiki/Gaussian_blur#Mathematics

>In addition to being circularly symmetric, the Gaussian blur can be applied to a two-dimensional image as two independent one-dimensional calculations, and so is termed a separable filter. That is, the effect of applying the two-dimensional matrix can also be achieved by applying a series of single-dimensional Gaussian matrices in the horizontal direction, then repeating the process in the vertical direction. In computational terms, this is a useful property, since the calculation can be performed in O(w_kernel w_image h_image) + O(h_kernel w_image h_image) time (where h is height and w is width; see Big O notation), as opposed to O(w_kernel h_kernel w_image h_image) for a non-separable kernel.