colr-gradients-spec
colr-gradients-spec copied to clipboard
googlefonts
Blurs and filters
When we show people COLR they tend ask about blur. Filing an issue to speculate about both how we might support and whether we should.
Blur for drop shadow is an obvious application; doubtless others exist. This seems like the road to full blown filters; it's worth asking if we want to go there?
References:
- SVG https://www.w3.org/TR/SVG11/filters.html#feGaussianBlurElement
- Ex https://developer.mozilla.org/en-US/docs/Web/SVG/Element/filter#example
- Web https://www.w3.org/TR/filter-effects-1/
- Ex https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function#examples
This makes sense. At the same time, I'm a bit concerned about features that are missing in common graphics libraries. I know cairo never got the full filter facilities in it. Skia I think has. MS/Apple I don't know.
Looking at those, blur and drop-shadow look special / harder. The rest look possibly simple implementations through the belnding we already have.
features that are missing in common graphics libraries
+1 to this concern, definitely need to check on platform capability. If support is dodgy it might make sense to take two passes at COLR, first one to release the widely supported things and a second one to add additional capability via more Paint formats.
I suspect blur will prove useful in normal typographic fonts as a simple way to get a soft edge on high res output. I have actually wanted blur for decades, but got tired of mentioning it :)
In the dingtalk App, we have many emojis with shadows or blurs.
We are considering switching from PNG to SVG (COLRv1) and encountered some problems in the process. Since COLRv1 currently does not support shadows or filters, the SVG version lacks some details.
It would be best if this can be solved in COLRv1.
https://p-static.flipgrid.com/stickers/original/ec67991a45e348c3a805ada3d893bc5e.svg https://p-static.flipgrid.com/stickers/original/982c02e34c414a14815017032536c66b.svg
Microsoft has released a new emoji, it seems that these are PNG bitmaps, more and more emoji designs will not be satisfied with only gradients.
@PeterConstable Do you know what format the new emoji will use in Windows fonts?
Ulrike Rausch uses bitmaps in the LiebeHeidi Color font to simulate the appearance of a ballpoint pen.
I'm wondering if a Perlin noise filter (like SVG's feTurbulance) might be useful for creating such effects.
Just a thought, which I admit is.. amusing.
The example from @yisibl does not look so much like that using 2D effects (such as blur and shadows) and more like, what is really wanted is a 3D renderer with lighting; that is what the various effects are aiming to give.
Somewhat sadly, doing the 3D lighting would be much easier to implement a GPU renderer that runs it all in one-pass instead of relying on blur and shadows (which are really just modulated blurs).
Might just be easier to provide a something to compute a normal map along with a position of a light. By better, I mean how to render it with a GPU.
https://raphlinus.github.io/graphics/2020/04/21/blurred-rounded-rects.html, @raphlinus noted distance fields fed curves might be an interesting option to explore
I really think that the direction of adding shadows is a direction backwards; the look that such effect is to do a lighting computation; much better to just have something to do a lighting computation instead of adding layers upon layers of stuff that just sort of looks like it where those layers are actually much more expensive to render.
Yeah, why stop at 2D graphics? Within the hour people will want fonts for AR/VR environments. Light sources can be set per glyph for single glyphs such as emoji, or the environment’s global light source can be used for whole words and longer texts.
More use case ideas via a discussion with @bfgeek https://heredragonsabound.blogspot.com/2020/02/creating-pencil-effect-in-svg.html - Creating Pencil effects using filters.
Why not just cry uncle and allow for the embedding of WGSL shaders to specify the material of a fill or stroke?
Why not just cry uncle and allow for the embedding of WGSL shaders to specify the material of a fill or stroke?
Because we also have to implement what we spec. :))
https://github.com/microsoft/fluentui-emoji makes extensive use of blurs and filters, some of which are not currently supported in COLRv1. It would be nice if we could build it in COLRv2.
Why not just cry uncle and allow for the embedding of WGSL shaders to specify the material of a fill or stroke?
We would want all the major implementations to be on board before pushing for such a change.
The issue with much of the layer approach for glyphs is that what one ends up seeing is layers stacked on top of layers with loads of Gaussian blur and blending (and not just source over blending to boot) when the goal for the vast majority of these is just emulate lighting. The old vs new emoji posted in this issue/thread by [yisibl] emphasises this to an extreme.
As a side note, I came across a design document that looked really good, had no images and took forever to render because of the massive amount of layers with blur. It was a nightmare to render.
The direction of adding blurs and more and more layers I think will lead to such cases.
The solution is to just allow a glyph to have some kind of shading attached to it so that one does not end up with layers upon layers of stuff. Given that this specification is spear headed by Google and Skia is the first implementor, SkSL may be attractive, or perhaps "something" to provide lighting and shadow and an implementation can do their own shaders...
@krogovin My example is definitely not drawn in 3D software, it is drawn in Adobe illustrator, it is just a simulation of 3D effect. The exported SVG contains the SVG <filter>
That is exactly my point; to simulate the light effects requires several layers of blurs and hand tuning as well where as a lighting computation will not only be faster to render, will also have far more dynamic opportunities.
Microsoft publicly released three Figma files of their emoji. They make heavy use inner-shadow. I hope that is something COLRv2 can support. https://www.figma.com/community/file/1138254942249677742 https://www.figma.com/community/file/1138258900298544048 https://www.figma.com/community/file/1138260689105864626
Roughly 15 years ago, I implemented more than 2 thirds of the rendering routines of SVG Filter primitives in Inkscape. I remember that some drawings would have very poor performance due to the heavy usage of stacked layers of filters. Of course, my implementation was not necessarily the most optimized one, but still some users really overused filtering layers in order to produce very realistic images.
In addition to the performance issue, I was also concerned about usability. Not every user is comfortable dealing with such low level building blocks as the SVG filter primitives, so a higher level abstraction was created in Inkscape, with a collection of ready-made filter effects:
While this is nice, there's still a large number of filtering layers under the hood and it made me consider alternatives to improve performance. Back then I thought that a scripting language such as javascript could have an API to customize processing of pixel buffers so that users could provide their own custom filter effects, and that would allow one to optimize the implementation of specific effects, reducing any redundant heavy processing. Nowadays, though, I think this would perhaps be a task for wasm.
