 Right. Ooh. That was intimidating. They've got louder every time. I don't think the clacker will make it through. Take five. Canvas. Oh. Canvas with them pixels. With them pixels. Of course, Canvas has been around a while. Yeah, it's been. And I think it's actually still pretty underused, because sometimes when you have, like, effect, people, like, bend over backwards to implement it with DOM elements. Yeah, I do that. It's just simple because then I can use transitions and animations. It's not DOM. There's, like, some spinners. If I look at the spinner that you put in Scrooge, yeah, but I've got some. That could be Canvas. Yeah, okay. And it would be interesting to compare the performance, actually, for that. Yeah. And on the spinners I did on the HTTP 2.0 free app thing, they're a radio progress bar thing. Yes. They're a SVG. They're not Canvas. They're not Canvas. That's why we're talking about them. Well, I was just saying it was easier to do it in SVG. I can understand why people don't use Canvas. Okay. That's the end of this segment. To be fair, like, round things in Canvas, I find it frustrating because you only have ARC and never. Where's the circle command? And ARC's parameters are so unintuitive. It's, yes. Yes. It's irritating. But what I want to talk about is the newer Canvas stuff that's arriving. The newer Canvas stuff? Newer Canvas stuff. So what's in Chrome now? And I think of a browser as well. I think it's definitely in Firefox. It's off-screen Canvas. Yes. Off-screen Canvas. I mean, that's, it's the same Canvas. It's the same Canvas. Same API. Drawy bits. Yep. But actually, well, you go. What is new about it, Jake? I don't know. Tell me, please. Well, it's the same Canvas. It's got the same drawing bits, but it's off-screen. No, it's in a worker. And that's the nice bit. You can't construct it in a worker and use it to generate graphics and then send them over to the main thread, right? You send them over to the main thread, and so it's that you can do all your complicated work in a worker and then just send, you know, transfer the pixels across the screen. Does it also do WebGL? Well, this is the thing about the browser support is we support 2D and WebGL. I believe Firefox only supports WebGL. Only WebGL? Yeah. Interesting. It's part of their, like, you know, thing to do games was their main focus. So it was WebGL. I'm interested in it from doing things like image decoding off the main thread, which you should be able to just know in Canvas. Why would you be interested in that? I have no idea. I have no idea at all. I mean, to be fair, there is image decoding. Actually, there is image.decode now, which decodes an image off thread, which is good. Doesn't it give you the pixels? No, sure. But I'm saying like for, because I think Paul Lewis, a long while ago, wrote a blog post where he actually decoded images in a worker with Canvas to basically not block the main thread with the decoding, which used to be a thing, that decoding blocked the main thread. Now, browsers just decode in a different thread under the hood. But the second you want to get to the pixels or do some manipulation or maybe scale it to store less on disk or something, that becomes really handy. You're doing all the Canvas work. That's main thread based. So yeah, do it all in the worker and then just send the done image. So do you have to create an off-screen Canvas and then write piping to bring it on screen once it's done and send over image data? You can transfer the Canvas from the main thread to the worker and then just operate on it in the worker. Oh, that's just magically. Yeah. Oh, that's amazing. That would be good for games where you have the game logic probably running in a worker and you say like you draw on a Canvas and it gets synced to the main thread. That's interesting. It's one of the things that you would need for that. True. Yeah, you would need that. Which is very cool. I'm not sure how that works if you've got two monitors of different refresh rates. I guess it figures it out because it knows where the Canvas is. I mean, yeah, Chrome already figures out the resolution as well. Like you literally can move from high DPI to low DPI. It just works. Exactly. But the problem is it's a tab that knows that. Whereas if you're in a worker, you're not in the tab. But it's associated with. It is strongly associated with the tab. With the render. So it should work, I think. So that's the thing. I think it would be useful. I think it's a big puzzle piece, honestly. Well, and there's other cases it unlocks. Not just a performance case. It would be things like if you get a push notification in a service worker and you have like avatars cached. Yeah. But it's a group message. You could construct an icon. True. Made up of those. Yeah, or like badging. Like there's five new messages now. So you're going to change them. Exactly. And without having to go to the server and download that. Yeah, that's actually super useful. So that's one bit. And then you can also do like video transcoding potentially in a worker. Maybe. Oh, if you had all the streaming stuff and everything. Maybe. I mean Canvas technically is able to play videos in a way. You can take a video element and just decode everything. Yes, but we don't have a video element in a worker. And that's the missing piece. A lot of the media APIs are missing from workers right now. It's something they're looking at getting. And I think especially as we'll start to do more media stuff that isn't real-time based. Yeah. I think that's when it makes sense to start having that in a worker. Yeah, that's going to be really cool. Because right now a lot of the media streams are based around sort of WebRTC. So like it's all based on dropping frames if it's not real-time. Yeah. Whereas like video processing. Yeah, you'd want that in a worker. We have it with Audio Worklet where you can like do an audio, Web Audio API. Not Audio Worklet specifically. But Web Audio API where you can do an offline context to just generate audio. It would be cool to have the same thing for video. Exactly. Because if you could like generate videos. Like mini video editor. It would be so cool to build on the web. And you say there's encoders in the browser already for WebRTC. Why can't we access them for other stuff? That's cool. Another Canvas thing. Oh, that's another one. Yeah, this one is super experimental. Only in Chrome hind flag sort of stuff. That's sort of experimental. It is, they're looking at low latency Canvas. And this is an option you would pass into the Canvas when you're, I think it's when you're getting the context, the 2D context. Like what makes it low latency? It, okay. So in terms of web standards. What it does is it sits outside the event loop. So right now we can only paint at that particular point in an event loop. And if something else is blocking. Do you actually batch up the draw instructions? And then I guess partly they are actually on the GPU, but whatever, like we just actually the batch of draw calls. And then. Yes. And so it means that if you, like something has changed on the page, like the DOM painting is going to be synchronized with the Canvas painting, which is what you want in a lot of cases. Yeah. But it also can delay things going on to the Canvas. And yes, it's batching up all of these calls. Sometimes it's batching up the whole image, right? Yeah. Double buffering, right? Double buffering, yeah. You know in these terms better than I do. That's pretty much a gaming practice because when the GPU renders, like at first it draws, you know, the background, then the couple of polygons at the back. And so if you don't do bubble buffering. Bubble buffering. Bubble buffering, double buffering. And your GPU is forced to ship a frame because frame rate, you might have an incomplete picture. And then you get like this weird thing where you have tearing or you have like things building up over a frame, even if you don't want that. So that's you have a buffer where they already build images in and you build up the next frame in a separate buffer and then you swap them. So this is the first one. Oh. The one with the tearing. So you end up with just one set of bytes representing the image content of that Canvas. How cool. And so if you're, you know, if you weren't using request animation frame properly or you've got half of your thing drawn, you will end up with half of the thing on the page there. Oh. So. Well, I mean that first it sounds like that's a step backwards but on the other hand it puts you in control, doesn't it? Yeah. So it's useful for things like a drawing app where you're taking stylus input and drawing it straight away. There's no tearing issue there. Yeah. And you really want as low latency as possible to make it feel as natural as you possibly can, right? Exactly. And I guess also like in the day and age of where wasm is a thing, if you compile an existing C++ drawing library, it already has double buffering in there. Exactly. So you end up with double double buffering. Double double buffering. Double double buffering. Double double buffering. Oh. And so this is a way of opting out of that and then you just keep the buffering that your game engine has. Oh, that's really cool. So yeah. And that is pretty much all I know about it right now. It's one of those things that sort of flew past. I looked at a demo and we'll post the links to it and I was like. Have you ever read an article about the Austrian canvas which we're going to link to? Yep. And we'll link to the demo of the canvas, the low latency canvas which I don't know. Is it kind of? No, no, no. He's just excited about it, isn't he? Yeah, he's just excited about it. It was done by the engineer who did the implementation. Oh, that's good. Junov, I think. Oh, OK. I don't know their full name. But it works. It crashed Chrome a couple of times for me. So that's how experimental we're talking. But it's really exciting. Because it's just a simple drawing app. I would love a side-by-side example because I can't decide if it's like placebo effect that it feels faster because, you know, I'm told, this is low latency canvas. Like woo-hoo. Look how low latency is that. That line really appeared on screen faster than I've ever seen it appear before. So, you know, it's obviously very important for game engines and that kind of low latency. I would like to see some science behind how much faster it is on a phone, especially. Yeah. But yeah, that's going to be interesting. Sometimes it takes up my, like, one armpit just goes, pfft. That was me before I owe, not last year or the year before because I picked a t-shirt that I wanted to wear. It was an F1 t-shirt. I was like, yeah, I'm wearing my F1 t-shirt. And then just before going on stage pretty much, I just looked around and said, just yeah, this armpit. This one? Drives above. This one.