[HN Gopher] Introducing the layer based SVG engine
___________________________________________________________________
Introducing the layer based SVG engine
Author : bpierre
Score : 225 points
Date : 2021-11-01 14:31 UTC (8 hours ago)
(HTM) web link (blogs.igalia.com)
(TXT) w3m dump (blogs.igalia.com)
| nicoburns wrote:
| This sounds great, a lot of chart/graph libraries are SVG based
| and rendering performance is a common bottleneck for these
| libraries. Hopefully this will help.
| orestis wrote:
| Huh, we have a Thermomix at home and the UI is not terribly laggy
| but could certainly stand to be improved. No idea how and why
| they use SVG for the current UI, perhaps it's for upcoming
| features?
| hoten wrote:
| The article mentions they hold back on SVG a bit, but with
| these engine changes I assume they won't have to.
| danpeddle wrote:
| Upgrading existing customers was probably part of their
| reason for doing the work.
| Piribedil wrote:
| Am I missing something to think it is insane a kitchen appliance
| manufacturer fund such core dev work instead of Apple ?
| danShumway wrote:
| On the surface, it is kind of wild, but I want to suggest that
| it's in some ways beneficial for work like this to be supported
| directly by the companies that benefit from them (including
| core dev work and engine improvements).
|
| There are downsides to only having Google/Apple/Mozilla
| participating in this process, and it's that (regardless of
| whether you think they have good or bad intentions) they are
| extremely insular.
|
| There are dangers to this as well of course. We don't want
| things getting derailed or worsened just because it makes life
| more convenient for some company somewhere. But in general I
| suspect it's good for more stakeholders to be getting their
| hands dirty engaging with both the standards processes and the
| minutia of actual browser development. They had a problem, they
| gave money to developers to fix it, and it got fixed with
| approval from upstream. In terms of Open Source, a pretty clear
| success story to me. We should encourage this.
| nzimmermann86 wrote:
| Agreed - Igalia encourages companies to work upstream, it's
| part of the idea that we stand for.
|
| A patch like the layer based SVG engine is imposssible to
| maintain by a single company - e.g. Vorwerk, downstream, for
| an extended period of time. You want to be able to follow
| upstream (e.g. for security updates), and that's hard when
| you change a piece of the core engine with your own stuff.
|
| To suceed, you _need_ to work upstream :-)
| skywal_l wrote:
| Yep, never thought my passion for computers and cooking would
| collide on hacker news this way!
| marcellus23 wrote:
| Uh, why? Isn't that the whole point of open-source? Apple
| webkit engineers have been supportive from what it sounds like,
| it's not like they're against this patch.
| azinman2 wrote:
| Because it's for a company that makes a high end blending
| appliance. The sponsor is what makes this odd. I don't see
| Cuisinart or KitchenAid sponsoring much other open source
| code.
| ghostly_s wrote:
| Well, Apple's devices presumably don't have any trouble
| rendering SVG on CPU. As explained in the intro, the
| embedded CPUs on the blenders do. The unusual part here is
| that they decided to fix it instead of just falling back to
| a less featureful UI framework, which I'd say demonstrates
| an unusual commitment to quality user experience (or if you
| want to be cynical, flashy user experience).
| Piribedil wrote:
| Thanks for your comment : that makes more sense now.
|
| I had the assumption that efficient SVG rendering in
| Safari was critical and a UX bottleneck to work on from
| an Apple perspective, but maybe Apple hardware makes it
| moot.
| nzimmermann86 wrote:
| It's not the hardware per se. CoreGraphics on macOS/iOS
| utilizes the GPU for painting, which is much faster than
| software rendering. Cairo, used for the Linux GTK/WPE
| ports, is software based, and thus much slower, when
| painting large scenes.
|
| Therefore for embedded devices using WebKit/Linux GTK/WPE
| ports we see a huge improvment with the layer based
| engine. Also macOS/iOS benefits though -- animations are
| even faster, and you don't easily run into problems, when
| animating parts of a complex document. It's shown in the
| video linked in the article at the end: > 20% frame
| rendering time improvement on an already quite efficient
| rendering pipeline (Safari / macOS using CoreGraphics on
| M1 machine).
| Pulcinella wrote:
| I believe CoreGraphics is CPU based. CoreAnimation
| utilizes the GPU.
| havkd wrote:
| You clearly don't know how expensive a Thermomix is...
| chris37879 wrote:
| You are, the very first line of the article explains why they
| care. They make extensive use of the SVG api and it would
| benefit them to have this feature.
|
| It's no different to Valve hiring CodeWeavers to implement new
| things in the Linux kernel to advance their efforts with
| Proton. Steam isn't in the kernel development space, but it
| behooves them to improve the kernel with features that are
| useful to more than just themselves, since features that are
| _only_ useful to them are likely to be rejected.
| Vinnl wrote:
| The first line (of the fourth paragraph, but still) does
| indicate that they make use of the SVG API, but what's
| baffling is not that they use it, but that apparently there's
| enough return on investment for them to be sponsoring this.
|
| Is there no alternative for what they're using it for? How
| much extra money does this use bring in? Who managed to
| convince management to do this and how did they do it?
|
| (I also imagine it's not so much a critical note as it is a
| "wow, I'd really like to understand the economics of this".
| It is for me.)
| [deleted]
| Semaphor wrote:
| It's interesting to see Vorwerk described as a kitchen
| appliance company. I had heard of the Thermomix, but didn't
| know it was made by them (or even German). I've mainly known
| them for their vacuums.
| [deleted]
| Octoth0rpe wrote:
| > I've mainly known them for their vacuums.
|
| So they mostly suck is what I hear you saying
| alexashka wrote:
| The number of people who want to do useful work that isn't sexy
| is vanishingly small, so I'm completely unsurprised that great,
| useful work comes from random places.
|
| That's actually how progress gets made - by people doing
| thankless work in obscurity. Then opportunists usually take
| that effort, make it fit an existing industry and charge
| whatever the market will bear.
|
| It'd all be fine if the middlemen didn't then proceed to claim
| greatness, insight and ingenuity, but they do (because then
| older middlemen give them money to replicate their success).
|
| This social structure is quite bad because it makes people
| think the middlemen are capable of creating value through their
| 'insight', without people who did unsexy, hard, thankless work
| prior.
|
| Anyhoo :)
| willis936 wrote:
| I can't think of many things flashier/sexier than high
| performance vector graphics. We live in a world with 8K
| displays. Pushing the envelope of attractive (2D) graphics is
| done in vector land.
| solarkraft wrote:
| Yes! You're missing the most important aspect of open source
| projects. Anyone can contribute a feature they care about
| (within limits). Apple (apparently) doesn't care that much
| about SVG performance, Vorwerk does, so they paid for it.
|
| This is why companies like Google and Microsoft are big
| contributors to Linux: They add features they care about.
|
| As for why companies care about upstreaming: It's not even
| because they're so kind (though FOSS contributions are good
| marketing) - it just tends to be easier than maintaining a
| private fork.
| wombatmobile wrote:
| > Yes! You're missing the most important aspect of open
| source projects. Anyone can contribute a feature they care
| about (within limits).
|
| The biggest limit is resources. SVG is too big to be
| implemented by a lone wolf working for love alone, and too
| diverse in application for a tech company to embrace for the
| length of time and breadth of focus required.
|
| This is a welcome development that validates the W3C model in
| a positive, constructive way.
|
| TBL would be pleased I imagine.
| kingcharles wrote:
| It does baffle me that Apple, who will benefit from this,
| couldn't spare the development funds themselves, considering
| they are worth more than God himself.
|
| Apple has allegedly spent billions on the development of a car,
| yet could not spend what was probably $100K of consultancy to
| fix this issue.
| wombatmobile wrote:
| Millions actually, over years if you consider life cycle and
| dependencies.
|
| Still, FAANGS have trillions, so why not, you might wonder,
| splash a drop here or there?
|
| The reason in practice is that to get any significant dev
| adopted in a FAANG is a competitive process with career
| advancement at stake.
|
| Only so many projects can level up year after year, because
| there are limited eyes and ears at each successive level that
| approve funding.
| rezmason wrote:
| "So what computer graphics work are you the most proud of?"
|
| "I contributed some highly impactful performance improvements
| for a blender."
|
| "For Blender?"
|
| "No, for a blender."
| wombatmobile wrote:
| > Am I missing something to think it is insane a kitchen
| appliance manufacturer fund such core dev work
|
| It's a great development and the key to open standards success.
| Not, of course, that a _kitchen appliance manufacturer_ stepped
| up, but that _any_ outsider was interested and willing to
| contribute to a general computing tech stack.
|
| For a thousand flowers to bloom, the bird must leave the nest.
| tester89 wrote:
| This reminds me how we got film which was better able to
| represent people of color because (as one reason, I don't hink
| it was entirely this) of wood and chocolate manufactures
| wanting film which better showed the colors of their products.
| dncornholio wrote:
| We are speaking about the most rich company in the world. You'd
| think they'd have the resources to fix their shit. Vorwerk
| probably got fed up with it too and decided to fix it
| themselfs.
|
| This is not a good look for Apple IMO. I completely dropped iOS
| support for an app I made because it used SVG's and clogged up
| every iPhone. It's a serious issue.
| shadowgovt wrote:
| One person's "fix their shit" is another person's "feature
| bloat."
|
| I assume Apple didn't implement this change in-house because
| they don't need higher-performance SVG rendering.
| otterley wrote:
| You assume, incorrectly, that having money and other
| resources means you can snap your fingers and immediately
| hire the right person with the right skills to solve any
| arbitrary problem you might have.
|
| The world just doesn't work that way. There's a shortage of
| talent out there, and they often don't want to work for the
| richest players.
| daenney wrote:
| Not just "you might have" but "other companies using OSS
| software whose development you financially support might
| have".
|
| If faster SVG graphics were an impediment to Apple's
| business it would likely have been prioritised and fixed by
| them.
| hnmullany wrote:
| Yes it is insane. Apple's SVG development team is practically
| non-existent.
| The_rationalist wrote:
| How does it compare with chromium/layoutNG? It's saddening than
| those human resources keep being wasted on the pathetic
| abandonware that is webkit
| tambourine_man wrote:
| How is SVG drawing done in Chrome and Firefox? Do they offer
| hardware acceleration?
|
| How fast would hardware accelerated SVG be compared to Canvas?
| pier25 wrote:
| Chrome uses Skia which AFAIK is GPU accelerated. Not sure about
| the SVG part though.
|
| https://skia.org/
|
| https://en.wikipedia.org/wiki/Skia_Graphics_Engine
| hnmullany wrote:
| Yes a bunch of SVG ops have been offloaded to Skia GPU
| rendering.
| rjsw wrote:
| Firefox uses librsvg [1], don't have a feel for how well
| accelerated it is.
|
| [1]
| https://wiki.gnome.org/action/show/Projects/LibRsvg?action=s...
| notriddle wrote:
| No it does not. Firefox/Gecko implements SVG on top of the
| same framework as their HTML engine. So do WebKit and Blink,
| and even EdgeHTML and Presto had their own SVG
| implementations back when they were actively developed.
|
| Web standards effectively mandate the SVG and HTML
| implementations be implemented on top of the same DOM,
| because when you embed an SVG inside an HTML document, you're
| allowed to use CSS selectors like `html div svg path {
| stroke: blue }` and JavaScript that treats SVG elements as
| being part of the HTML document.
|
| librsvg's API isn't nearly rich enough to allow this. It just
| takes a blob of bytes and turns it into Cairo draw commands.
| Gecko doesn't even use Cairo any more, it uses Skia. librsvg
| does have a DOM, but it's intentionally not exposed as part
| of the API, so that the DOM can be refactored at will without
| breaking anything.
| Jasper_ wrote:
| I'd actually be very surprised if Firefox uses librsvg,
| considering that librsvg doesn't support much of the
| interactivity and animations that Firefox supports in SVGs.
|
| Looking roughly at the source code [0], it seems it has its
| own SVG engine.
|
| [0] https://github.com/mozilla/gecko-
| dev/tree/master/layout/svg https://github.com/mozilla/gecko-
| dev/tree/master/dom/svg
| shadowgovt wrote:
| Does this mean the Gecko engine won't be able to render SVG at a
| performance level matching WebKit?
|
| I wonder if this is something Mozilla will need to address, or if
| the use cases are small enough that it's not worth the cost.
| muizelaar wrote:
| Gecko has had layerization of SVG for a long time.
| Eric_WVGG wrote:
| I was knocking around in SwiftUI last weekend and disappointed to
| learn that there's still no native support for SVGs -- you're
| either stuck converting SVG to NSBezierPath, or taking your
| chances with 3rd-party libraries that come with a laundry list of
| caveats.
|
| The documents don't mention if their engine is suitable for
| "dropping in" to the Cocoa/CocoaTouch/NSwhatever system, but
| gosh, that would be a heck of a treat...
| kccqzy wrote:
| Doesn't sound like so. But I imagine it's always possible to
| use WKWebView to use the new engine once it lands.
| viktorcode wrote:
| You can use SVGs as vector images though. Before that only PDFs
| were supported for that role.
| isodev wrote:
| Neat! Also happy to read about a healthy example of OSS. WebKit
| is awesome and so are all the folks who contribute!
| solarkraft wrote:
| Kind of wild that "completely redesign the SVG engine" was found
| to be the most economical option (I also wonder what it cost
| them).
|
| Alternatives could've been switching engines, the animation
| approach, the UI toolkit or throwing more hardware at it.
|
| At the scale they operate it makes sense, I guess. They likely
| already have a large code base on their current technology, lots
| of devices already sold and more powerful hardware might cut into
| margins by half a percent.
| harrygeez wrote:
| I had the same thought. Personally I find it kind of funny that
| the company behind Thermomix is sponsoring this effort.
| Pulcinella wrote:
| So if I am understanding it correct, the hardware acceleration is
| GPU accelerated compositing, transforms, etc.
|
| I hope someday someone will crack GPU accelerated vector path
| rendering.
| TheRealNGenius wrote:
| I tried to google search it, but couldn't find anything. What
| is GPU accelerated vector path rendering? Does this entail some
| fancy processing to accelerate rendering of SVG paths?
| zackangelo wrote:
| Have you checked out the Pathfinder library?
|
| https://github.com/servo/pathfinder
| jancsika wrote:
| > I hope someday someone will crack GPU accelerated vector path
| rendering.
|
| Wasn't raphlinus doing work on that?
|
| @dang-- is there a bot on here that can shoot out the relevant
| post/comment/etc.?
| aaaaaaaaaaab wrote:
| https://developer.nvidia.com/gpugems/gpugems3/part-iv-image-...
| amelius wrote:
| > A WebKit version that unlocks hardware-acceleration for SVG is
| a game-changer, allowing to use SVG across the whole user-
| interface.
|
| How can you show video in SVG?
|
| What if you decided to build your entire UI in SVG, and then
| someone asks to add video? Would you have to rewrite your entire
| UI using a different approach?
| nickpow43 wrote:
| I suppose you could use a <foreignObject> for that.
| dgreensp wrote:
| Is the code in question used by browsers like Chrome, or bypassed
| in favor of Skia?
| Hendrikto wrote:
| Chrome uses Blink. WebKit is used in KDE and Safari.
| kitsunesoba wrote:
| WebKit is also used by GNOME Web/Epiphany and more embedded
| applications than can possibly be counted. It fits a lot of
| places that Blink doesn't because it's built to be highly
| embeddable (more than Blink is anyway) and has bindings for
| every language imaginable.
| robocat wrote:
| I noticed that none of the cross-platform frameworks listed
| here https://xpda.net/ use WebKit.
|
| I am guessing many commercial users of WebKit can be
| guessed by looking at the list of Committers (of which
| Igalia has quite a few): https://webkit.org/team/
| onion2k wrote:
| SVG has no support for z-index in the spec. SVG renderers draw
| everything from the back to the front reading the elements as
| they appear in the doc tree - if you want put something on top of
| something else you have to move it down the document.
|
| In my previous role I worked on a React app that was essentially
| just a big SVG editor for lawyers to make legal step diagrams
| (complex maps of legal structures that define how they change
| over time). Our solution to the z-index issue was to make
| extensive use of React portals to things lower down the doc tree
| when they were in focus. It worked really well, but I would have
| _killed_ for proper z-index support. It would have greatly
| simplified my code.
|
| I don't really care about the GPU acceleration; adding layers to
| SVGs is an amazing change on its own. Kudos to the team behind
| this. I hope it gets adopted everywhere.
| eyelidlessness wrote:
| > Our solution to the z-index issue was to make extensive use
| of React portals to things lower down the doc tree when they
| were in focus.
|
| I'm curious why you went with portals? Seems to me you could
| use the normal render cycle to control order (keyed if you
| intend to just reorder siblings).
|
| > I don't really care about the GPU acceleration; adding layers
| to SVGs is an amazing change on its own.
|
| I may be mistaken but in my reading of the article, my
| understanding is that SVG layers are only about acceleration,
| and don't change the stacking semantics of SVG elements. But
| maybe I missed something.
| onion2k wrote:
| _I'm curious why you went with portals_
|
| We had to move things to the front of the SVG no matter where
| they were in the document. If it was just siblings it'd have
| been much easier.
|
| Also, these are _complex_ SVGs. On a large diagram there can
| be 50,000 elements in the SVG. Portals made it simpler.
| progers7 wrote:
| This article is just about acceleration and stacking is not
| introduced. WebKit's architecture ties together the concepts
| of stacking and acceleration. A positive effect is that it
| will be quite easy to support stacking in SVG with this work.
|
| A negative of joining the concepts of stacking and
| acceleration is that it is difficult to get acceleration
| without introducing paint order bugs where the accelerated
| content starts painting above non-accelerated content.
| btbuildem wrote:
| The lack of z-index in SVG is such a drag. I'm working on a
| (relatively simple) project - think Figma in terms of
| interactions - and the hackery is inevitable and immediate when
| trying to deal with this. A hybrid approach of multiple SVG
| objects in a HTML tree seems to be working so far, but it's far
| from pretty.
| nzimmermann86 wrote:
| It was in earlier SVG2 drafts, but was dropped due to the
| lack of implementation, see here:
| https://www.w3.org/TR/2015/WD-
| SVG2-20150915/render.html#ZInd...
| moron4hire wrote:
| It's been a while since I've done any SVG, but it seems like
| you could just create a grouping element for each layer and not
| put any graphical elements in the doc root.
| zestyping wrote:
| This is a digression, but I'm really curious what you mean by a
| "legal step diagram". It sounds like a fascinating concept, but
| all I could find on Google were process flowcharts. Can you
| point me at more info on these? Thanks!
| onion2k wrote:
| Step diagrams are what lawyers call flow charts, but with a
| design convention language that's a bit like UML, and with
| _tons_ of meta data attached to each element. There 's also a
| time dimension as you can step through to see each stage of a
| legal process.
|
| I understand what they are as a dev but I'm not a lawyer so I
| can't point you to anything more unfortunately.
| theaussiestew wrote:
| Was this company called Checkbox?
| tannhaeuser wrote:
| AFAIK, SVG2 was supposed to bring that in line with HTML (or
| rather, CSS' z-index).
| ksec wrote:
| Is SVG2 actually coming or is it in Limbo?
| nzimmermann86 wrote:
| It totally depends on the implementors, if no one
| implements it, it won't come. If nobody does the first
| implementation, no other vendor will follow - it's as easy
| as this.
|
| For WebKit/SVG, features as z-index are easy to implement
| in the layer based SVG engine - it's currently disabled,
| but only because it's lacking dedicated tests: I'd still
| need to write new reftests covering that.
| phrz wrote:
| dupe https://news.ycombinator.com/item?id=29043848
| gigatexal wrote:
| Imagine you could go back in time to Flash web devs and show them
| what you can do now...
| pier25 wrote:
| Is this sarcasm? :)
|
| Flash had GPU acceleration 10 years ago.
| spicybright wrote:
| For real. No one would be impressed by that.
|
| I can't help thinking a majority of comments like GP never
| actually used flash or was active on the internet during it's
| height.
|
| Flash devs from 10 yeasr ago would only be impressed by how
| many new APIs to talk to the host OS there are.
|
| Flash had a lot like a file API, local storage, and webcam
| support. But there's definitely a ton more now.
| kitsunesoba wrote:
| It came at a steep cost, though. As cool as the various
| things built with flash were, my GPU and CPU staying spun up
| and turning my computer into an oven because of a flash
| banner ad in a tab open somewhere wasn't.
| pier25 wrote:
| I agree, but let's not forget GPUs have improved
| considerably in the past decade.
| douglee650 wrote:
| I think the point being made here is what can be done in the
| browser only, sans extensions
| waveymaus wrote:
| this is as wholesome content as HN will ever get.
| jancsika wrote:
| It would be funny if this ends up improving playback on that
| Fisher Price music box thingy. :)
|
| (Joke being that the music box which replaced simple moving parts
| with a bunch of circuitry might even have a version of Electron
| running somewhere in its guts...)
| streamofdigits wrote:
| Imagine what kind of vector visualization we would have if the
| meta-man would create 10000 positions to work on GPU accelerated
| SVG 3.
|
| There must be a law that says that the most interesting
| technology can never win because that would make the universe too
| nice.
| flakiness wrote:
| Didn't notice but Zimmermann, the author, has been back to WebKit
| land ! He's a super-long-time contributor of the project [1] and
| I got my code reviewed from him more than a decade ago. Glad he's
| back.
|
| I'd also Appreciate Igalia sponsoring people like him who are
| enthusiastic to these open source projects. [1]
| https://blogs.igalia.com/nzimmermann/posts/2019-11-24-back-in-
| town/
| ognarb wrote:
| Oh nice. Iirc he was one of the guy behing ksvg, the svg engine
| for KHtml.
| nzimmermann86 wrote:
| Now I'm curios who you are :-)
| flakiness wrote:
| It was such a long time ago but the Trac search worked pretty
| well :-) Thanks you at that time and thanks for the long-
| lasting great work!
|
| https://trac.webkit.org/changeset/54556/webkit
___________________________________________________________________
(page generated 2021-11-01 23:00 UTC)