Skia sounds as awful as something I'd expect out of Google...
Conversation
Replying to
They made it because Cairo has terrible performance and varying output across platforms. I'd expect that Cairo has bigger security problems too, but doesn't get nearly as much attention because it's not exposed in two of the major browsers as the 2D canvas implementation.
3
2
Cairo was used exclusively by Firefox until 52. Performance is acceptable even on very old and embedded hardware. Dunno what you are talking about.
1
1
Cairo performance for canvas and elsewhere was atrocious. It was a massive bottleneck and made rendering very CPU bound. Going from 5-10 fps to 60-120 fps for 2D games, etc. is a big deal. A large part of the issue is Cairo's API. Read Mozilla's posts.
robert.ocallahan.org/2011/09/graphi
1
Most users aren't running games in the browser but viewing websites. Switch away from Cairo was about competing with (and deprecating) Flash and about letting sites get orders of magnitude more resource-hungry (GPU-dependent), not about making performance acceptable.
1
1
Performance was unacceptable simply for rendering and scrolling web pages consisting entirely of CSS, text and images without any JavaScript. There are also many applications based on Canvas including obvious cases like Google Maps but also lots of examples that are less obvious.
2
That's also after Mozilla put in lots of work to develop improvements and accelerated backends for Cairo. Firefox performance can still be sluggish on demanding web pages with complex HTML/CSS. Still often has lots of dropped frames / jank with popular sites on weaker hardware.
1
And sure, most sites consume orders of magnitude more resources than they should need to deliver the same experience (with exceptions for web applications with real use cases for complex rendering). That's just the reality of the web, and people won't use Firefox if it's slow.
1
HTML, CSS and the DOM is incredibly complex and inefficient. Rendering it efficiently is extremely difficult. Sites also keep piling on more and more bloat / complexity. If Firefox can't keep up with that, it's just going to drop in usage share even more than it already does.
1
Making IonMonkey (or whatever they call it now) more performant, and making Stylo more concurrent, would pay far more dividends than keeping up with Skia CVEs and having to deal with the fallout of merging major Skia versions in every few cycles.
But I'm going to bed now. 💤🐱🦊
1
1
That doesn't make much sense. Speeding up those components isn't going to achieve the same thing. Having significantly faster JavaScript or speeding up the higher level CSS layout doesn't replace it. Skia is also only one backend, and each of them is full of vulnerabilities.
This Tweet is from a suspended account. Learn more
I'm not a web developer and CSS is one of the last things I want to do in my free time, sorry. I don't really understand why you're asking me. Did you just search for CSS and this is where you ended up?
1
A project having more discovered vulnerabilities also hardly means that it's less secure. An undisclosed vulnerability is still there. Far more researchers fuzzing, auditing and hardening a project isn't a bad thing, and they get it for free for components shared with Chromium.
1
Quote Tweet
Replying to @DanielMicay and @RichFelker
It's part of what Mozilla's Servo project has the potential to replace, similarly to how it replaced the Firefox CSS engine with one written in Rust (Stylo). Those components handle a very complex problem and consume untrusted input so memory unsafe languages are a big liability.