 Welcome to This Supercharged. Now, normally when we do our videos, we get lots of comments. We get lots of questions on Twitter, loads of things that kind of come into us. And so we thought, why not? Let's actually take a step back and answer some of those questions. How are SVGs rendered? They seem quite slow. Are they GPU accelerated? If so, in what ways? I have actually no idea. Cool, I do. So they're actually DOM elements. Not only the SVG, but every child is an actual DOM element or the rectangle. Right, so you've got to be careful because if you move them around, they're going to trigger layout. But the layout operation will stop at the SVG route. It's one of the times we actually have what we call a layout boundary where the layout actually is not document-scoped. It's going to be scoped to the SVG element. Would you look at that? The other thing is a transform. Normally we promote this thing to its own layer and then transform it around. That doesn't work in SVG context in Chrome. I'm not sure about other browsers. But in Chrome, we don't promote anything to its own layer when you actually add, like, WillChange or Translate Z0. So it's always a repaint? It's always a repaint. So you've got to be cautious with that. To be fair, I actually expected that for an SVG because I think, for some reason, I think of more than Canvas-like than anything else. Right, right. But hopefully, hopefully some point that optimization might land, I don't know, though. And then are the GPU accelerated? They can be if you've got GPU rasterization switched on. In fact, one of the best ways to improve SVG performance today on mobile is to make sure that you've got GPU rasterization, at least for Chrome, and the way to get that. If you just Google for, I think it is actually Magic Viewport Chromium, possibly. Or, I think, Ganesh or GPU rasterization Chrome, one of those will get you into the world that you need to be in. Next question, is it possible to disable, I don't know why they put, I mean, in quotes. Anyway, is it possible to disable web animations on very, very, very, very, very slow devices? It has to be at least five. And they put three tortoise emojis afterwards. I think I know if that person is getting it. They're going for slow, going for fully slow devices. I can't think of a way to adapt your animations, really. I think what you could do, possibly the performance observer that is in the works at the very least right now, could eventually help you do this. My first intuition when I read this question was that maybe you can kind of abuse request idle callback because that will only be called if your web page is not too busy. And if that is being called, you could use it to enable your web animations. Go the other way around, have them disabled by default and basically enhance your web page with the animations provided it is not under too much of a load. Yeah, the problem I had with that is that you're now main thread. So if you're animating with JavaScript, right? All your animations are coming from the main thread, which is fine. So you can then test for main thread availability with request idle callback or request animation frame or both. But if you've got something that's like a CSS animation that is done with, say, a transition and you're just using the compositor thread and it's just going to keep going even if the main thread is janked up, then you can't use that technique because it's going to be like, well, I can't do any animations right now. And the problem I have is that even with the frame timing API, it's still only main thread availability. So it's kind of going to benefit anybody who's animating JavaScript, but it's not going to benefit anybody who's animating just purely with, say, CSS or something like that. Overall though, the thing I wanted to kind of ask myself was is it the right decision to disable the animations in the first place, right? So I was like, if your UX can stand not having the animation, it feels like you don't need the animation, right? Animations just shouldn't be for the sake of. I think usually they serve a point. And if they don't serve a point, then you might as well skip them because it's about being a little bit mindful about the user's resources. Right, right. So I was like, but I get it's a sliding scale and somebody might be like, hey, it's an added bonus if your device can take it or whatever. As I say, I don't think you can do it reliably today and I don't know of anything in the works that's just like, this is a cast iron way of saying this device should be good to go. But I think you're right. Request that on callback, probably the closest we're gonna get. Well, there you go. So those are the questions that you asked and we would invite you to ask more questions in the comments below. Twitter, I'm at Aero Twist. At Dussurma. That's like, that's like Dussurma but in German, which I learned. I'd forgotten all my German until. I taught him. He did. He did. So ask your questions, ping us on Twitter and we will catch you next time.