Everybody forced here ripping 21 22 mosaic a road to FIFA World Cup soccer hobby six box half case number three I'll let you check out the results right there. You can always find them at latent sports cards calm Thanks for joining everybody and good luck guys three to go on The last day time break six box half case number four It's the other half case of this break And if you're looking for maybe something a cheaper option or you maybe not sure how you feel about the product You have three boxers at 5 p.m. With Sam. He's got quite a few spots left. So I'm looking for some three box mosaic breaks Random team style. Sam's got you guys at 5 p.m. Ricky mosaic from Mexico, Oriela and tuna red mosaic whales Aaron Ramsey and Mosaic montage Sanchez for Portugal We also have these in stock for personal which will take place after group breaks tonight We have them in stocks are three ninety nine ninety nine free shipping worldwide if you get it ripped We'll top load all your hits of course Get them all shipped out to you safely. You'd see me 11 now ski mosaic Switzerland granted Shaka Rookie silver Poland Yaka motor nice Croatia purple mosaic Motel Kovacic 43 of 49 on the Kovacic. There you go Croatia Silver for France killing him Bob a lot of big names. You haven't pulled color yet. That's that tough was a color man It's tough Pina baritone Luke Shaw got mosaic rookie for Ecuador is Alan Franco red mosaic Ronaldo Portugal pitch masters Manuel Locatelli Italy Pogba out of yummy Ward rookie mosaic Croatia born a Sosa Silver Croatia Luca Modric McKinney and DeVry DeVry University cruise stitch Vidal Kai Havertz Denmark mosaic Miquel Damse guard Denmark silver pure pure Emil Huyberg Huyberg, however, however, they say Huyberg Huyberg graylish Plata Zlatan and Bob a mosaic for England Calvin Phillips Red mosaic rookie for Bruce Sergio Pena Levandowski and a Weston McKinney men of mastery Lopez Kimpembe a England scripts Kyle Walker There you go England good starts of the break and blue mosaic for Belgium is Aiden Hazard Nice card Belgium 50 of 99 spread mosaic for France Karim Benzema And they povard pitch masters for France as well Taggart or Tega Kane rookie mosaic Portugal gel Palinia Germany silver Kai Havertz Harry Wilson Luiz Diaz Kevin De Bruyne a stupid neon Kulesevski mosaic rookie Venezuela is Romulo or Otero rookie red for Netherlands is Denzel Dumfries And a montage mosaic of Stephen DeVry Stefan DeVry box to Vinny Jr. Bachman Marquinhos Kaisado Sweden mosaic is Latin Ibrahimovic red mosaic Switzerland to Manuel Akanji Suarez met a mastery Stangs Irvine Kisa Portugal mosaic Rafael Guerrero Spain silver on Sufati Shakiri Jalpili Saka Next auto is for Brazil. It's an Everton nice hit Brazil Now numbered and blue mosaic for Mexico is Diego Linas 74 of 99. There you go Mexico Red mosaic for Denmark is Casper Dahlberg A thief got met a mastery mosaic Irving Lozano for Mexican Mexico He is Mexican Cristiano Ronaldo base Griezmann messy base in the same pack Colombia mosaic Rafael Santos Borre silver rookie Austria feel of lean hearts Ochoa Hitch Masters Munoz Latomba Aronson Holland Raspidori mosaic for Germany Kai Havertz red mosaic Italy zero M. Obole met a mastery mosaic rookie a thief for Qatar Padu Spain mosaic Danny Olmo Sweden silver is Latin Ibrahimovic How many hockey games are there tonight guys all I know is the Bruins Rangers That's all that matters to me How many games are tonight though hockey is weird I was always like two games in the first day and then the following Friday there's like eight Mosaic France Killian Mbappé red mosaic rookie Croatia, Jessica Guardiola Pitch Masters mosaic Guillermo Ochoa name our base Pedro Lukaku Lukaku Conte pink mosaic Denmark Casper Schmeichel 25 and 25 nice one Denmark Colombia silver David Ospina Gakpo Alvarado in Capier Got rookie mosaic for Poland is Jakob motor red mosaic for Qatar is Amo as Ali and Mosaic montage for Italy is Nicola Nicola Borrella Schlager Boyle Hassan Lorenzo D Lorenzo Chile rookie mosaic is Guillermo Maripane Silver for England Jack Grealish now we'll do it for box two still three to go break in next Yeah, three to go still a lot of spots for the three boxers later as well guys. It started 5 p.m. Vinnie Jr. Bachman Marquinhos Conte Kimek mosaic for Mexico Diego Linus red mosaic Spain Farin Torres Menomastry Janel Herrera Beyo and Capier Pulisic Rookie mosaic for Chile has been Brereton Silver rookie Portugal Nuno Mendez Ginter and Ruiz Torres Reynolds Jeff Felix Adayemi for Colombia is Juan Camilo Zuniga Zuniga Enye is tough for me on that one There you go, Colombia on the hit And England purple mosaic Harry McGuire 13 of 49 been talking about him all day today England with the purple there red mosaic for Switzerland shared on Shaquiri and Who nice him on for Spain men of mastery so I say Shaquira must a Shaquira Shaquiri Shaquiri Ronaldo base for Portugal Mosaic for Portugal Ruben Diaz silver for Belgium Jeremy Doku What do you guys think about the judge 60 second home run a lot of hot takes out there a lot of hot takes Nios Latomba Aronson Levandowski mosaic for Sweden is Deon Kulisevski red mosaic Wales Ethan and Padu and Mateo Kovacic men of mastery Laporte Saka Romero Josek rookie for Australia is Ryan Grant Silver rookie Ecuador Alan Franco pitch masters Jose Jimenez Sutar hop Ederson Griezmann messy Daniel James mosaic for Italy Federico Kisa Red mosaic rookie Colombia's Gustavo Kueyar Kueyar Levandowski pitch masters mosaic for Poland name are Pedro Lukaku Holland Raspidore we've got a blue mosaic now rookie for Qatar is Abdul Karim Hassan blue mosaic 86 of 99 The host spot there silver for Austria Conrad Leimer Pitch masters Tilo carer Ramsey Benzema Mosaic for Ecuador is pervice a stupid young Red mosaic rookie for Norway Frederick meet mid show Midshow, I don't know how to say that that character Um Lindelof Lindelof mosaic montage for for Sweden Ready to go guys breaking next last group break of the daytime Just three a case say Ricardo Pepe. No, it's not what it was connected Mosaic rookie Locongo for Belgium is the YouTube stream Silver rookie Mexico or EL Antuna. All right one sec guys Continue on in a moment here. I want to fix this really quickly Dashboard Or YouTube chat just get it from a restream says it's connected there. She says error. That's fun Well That's so weird It says it's dropping links into YouTube. We just can't read it. That's so weird All right, I'm gonna have to pop out chat because I'll have to end the stream I think Because you just have to like reset it Pop out chat just like the old days Just like the old days I'm sorry guys. I'm gonna respond to your messages because Restream decided to disconnect from YouTube for some reason Very odd There we go. I don't work for now McGuire's the best set of the daybreak That's your favorite Isaac, I know it is you're probably trying to message the person that got it So you can buy it. This is six box number three. Yes All right, let's continue three boxes left here Khrustich Silva Vidal Llorente mosaic for Spain Micaela Yarsabal Silver Chile Alexis Sanchez Mina and Ruben Vargas a euro euro ho Swiss right how sure all stars sure Mendez Pogba out of yummy Mosaic rookie Ecuador Gonzalo Plata Red mosaic Norway Martin Morton Thorsby Stefan liner Torres Havertz Franco got a Nice France auto David Trezeguet Throwback hit there. There you go France blue mosaic for Chile rookie Ben Brereton 88 of 99 That's an awesome hit man You go France they have so they did France has a nice hit to Germany and France hit a lot red mosaic for Argentina Rodrigo de Pao and They Ross Vadori rookie pitch masters pitch masters mosaic for Italy Plata graylish Zlatan motor and Boppe mosaic for Denmark Casper Schmeichel Silver rookie for Ecuador Gonzalo Plata Patricio and Nico Gonzalez Anderson Wendell Werner Mount mosaic for England Jack Graylish red mosaic rookie Columbia Wilmar Barrios and a Salcedo montage from Mexico Maley Jota or Yorzebol Rodin Messi base mosaic Venezuela Salomon Rondon rookie red mosaic for the United States Ricardo Pepe Bitzel and a Zach Steffen montage mosaic for the US Eugenio Mena Yermina or Yermina Marino Holland Quarta Portugal mosaic Diego Jota Silver Venezuela Salomon Rondon Locatelli Pickford Grant Diaz Sanchez Fatih Foden a problem was a Poland rookie Camille Piotkowski 22 of 49 on the Piotkowski for Poland Rookie silver Poland is Casper Coach Lowsky Coach Lowsky, I believe it's another tough one That's my favorite thing to see on jobify right there. I said that that's that's the best There's like Pongo rookie Montiel Verst on a rumour rookie mosaic for Poland is Coach Lowsky again Red mosaic Brazil Gabriel Jay Zeus And pitch ashes mosaic is when the album Rero Maripon Olmo Chaka Saka Chaka and Saka rookie mosaic for Chile is Charles ironguies Silver for Portugal Ruben Diaz. Right moving on guys think we still have three to go. I just can't I can't see the back end website, so Still three to go on the next one Last day time break. It's a water real quick in Bappé Ronaldo base Dumfries Torres. Yeah, Ricky mosaic from Belgium Albert Sambi. Loconga Or twice silver Fernando Muzlera. Let's keep it rolling guys Tomba Aronson Wales mosaic Garrett Bale red mosaic rookie for Sweden. Yes for Carlson Man of mastery mosaic rookie Akram Hassan a thief. Can you stay kunday Werner? Kazemiro rookie mosaic Loconga for Belgium Silver for Italy Nicola Nicola Borrelia. That you hop you got a redemption Who could this redemption be that mosaic donnaruma for Italy red mosaic rookie for the United States Brian Reynolds and A pitch master was a Guillermo, Ochoa from Mexico redemption time Rodrigo de Powell There we go, that's Italy, right? We're not Italy. Sorry Argentina. Yeah, there you go. Rodrigo de Powell Argentina redemption that is FIFA auto mosaics. I don't mean non numbered you go Argentina pietkowski Pogba out of yummy Neymar Hedry rookie mosaic for Chile is Ben Barrett on Brazil silver Marquinhos Alex Whitzel Carlson Cortua Reina Charleston was a Germany Florian verts Rookie red for guitar Hassan al-Haidos Hadoos Hadoos Borrelia mosaic montage verts donnaruma timber Bachman Rookie mosaic for Portugal job heli Nya Silver rookie for Qatar is Sad al-Sheb Levandowski Cavani rookie mosaic Argentina Gonzalo Montiel Red mosaic for Switzerland is Shakiri and a men of mastery mosaic Luis Suarez. Oops staying glass coming Here it is Nice go to the Netherlands Matisse Delight stained glass Netherlands Magda for your Netherlands Denmark mosaic Miquel dams guard Rookie silver for Austria Daniel Bachman and last pack of box five Raspidori rookie Griezmann messy mosaic for Poland Robert Levandowski red mosaic Argentina Leandro Paredes And pitch masters Raspidori rookie for Italy one thing about every mosaic lots of chrome dust Yep sold out Sold out daytime everybody Make sure you're grabbing some spots for the nighttime breaks with Sam Here's a break schedule for you. Yeah, so that daytime. Thanks everybody We got one more after this Then there's a three box Mosaic road to World Cup breaks starting 5 p.m. Eastern. Like I said, there's baseball basketball and football tonight as well Alright, here we go. Let's see. Let's see a gold. We haven't seen a gold yet today a gold or a black would be cool Levandowski Verts rookie mosaic for Chile and you any Omana Silver Portugal rookie Joe Palinia Lean hard Modric Huyberg Mosaic Poland, Wojciech Chesney red mosaic France and Golo Conte Zlatan and Nico Gonzalez Zapata Hassard auto here It's Argentina it is Lucas Martinez quarter rookie scripts Argentina with a Argentina couple autos here blue for Austria's Marcel Sabitzer numbered 88 of 99 and Red mosaic Germany. You also a gimmick a lot going on in that pack Davinson Sanchez on the pitch masters for Colombia Kalin's itch hazard a desk Pogba Mosaic for Spain is a nice Simone Silver rookie Mexico Luis Romo Polgar and Diaz a de Bruyne Foden Parades mosaic for France as kunday jules kunday red mosaic Spain Amarclaport In a montage is Adrian Rabio You guys like this stained glass or do you like the stained glass of last year's products? Peppy rookie England mosaic Luqshaw red mosaic Peru, Renato Tapia And was a montage key for more whales Tapia Conte gimmick rookie rookie base mosaic for the US Brian Reynolds Silver kunday for France Patti Rodan Abram Griezmann messy. What do you got a purple? Yeah purple Ricky mosaic purple guitar I'm always Ali for 49 couple of color cards for Qatar Germany's silver Timo Werner two more packs So saw ferret on the Konga Moreno Holland quarter rookie mosaic for Sweden is Jen's least can you stay I don't say this person actually Just can you stay there red mosaic for Netherlands Frankie the young Pitch masters Holland pitch masters mosaic Rui Patricio does from the packs It's hit me now. I'm like can't quite sneeze but need to sneeze That's wrong man. Shaka a mobile a Pena Benzema Pado mosaic Jeff Felix for Portugal a Silver Denmark Miquel Dom's guard Donnaruma and Pretty good break. Give me a sec. We'll do a quick recap of color Short prints and autos here. All right, so we had blue mosaic Austria Marcel Sabitzer 88 of 99 We mosaic Chile Ben Brereton 88 of 99 Qatar blue Abdel Karim Hassan 86 of 99 Mexico blue Diego Linus 74 of 99 Belgium blue Aiden Hazard 50 of 99 purple mosaic I'm always Ali rookie for Qatar for a 49 Poland Camille Piekowski 22 of 49 Harry McGuire England 13 of 49 Croatia Mateo Kovacic 43 of 49 Pink Denmark Casper Schmeichel 25 out of 25 autos now Argentina Lucas Martinez Cuarta None numbered Argentina redemption Rodrigo de Pal Base auto there a scripts for France David Trezzegay nice hit Legend there a Juan Camilo Zuniga for Colombia Everton or for Brazil there and For England a Kyle Walker scripts with a Matisse delights on the stained glass for Netherlands That's gonna do it. Thanks again, everybody. We have one more six box breakup next


Database. Share content. Moodle's database activity allows you to build, display and search a bank of entries on a topic of your choice. These entries include files, images, links to websites, text and more. They may be moderated before approval, commented on and rated. Accessing it with the teacher role we see three dots to the right for editing, deleting, approving and unapproving. Database activity entries can be displayed as a list and individually in single view. In this database activity, beautiful places, when the entries are displayed in a list we see a name and image along with its location in the world. If we click to access single view we can also see who added this entry and when. All of these options and more can be set up when adding a database activity, so let's explore it now. Our teacher adds a database activity by enabling edit mode top right and then clicking add an activity or resource. Database is an activity because learners interact with it. Click once to go straight to the activity or click the I icon for more information and then the add button bottom right. The name is important because learners click on it to access the database. You can optionally give it a description which can be displayed on the course page by ticking the box. Other settings can be expanded by clicking the links. Entries. Here it's important to decide whether or not to moderate entries before they appear and note if you set them to be moderated and never approve them you can have a useful private sharing area between teachers and individual learners such as with a journal. Should students be able to edit their entries and or comment on entries? Should there be a limit on entry students must add before they can view others? Should there also be a maximum number of entries students can add? Ratings. By default editing and non-editing teachers can rate database entries but if you want students to do this also access permissions from the more link and then allow students the capability mod data rate. Other settings are similar to other activities. In activity completion to track that students have access to database do we want them to manually click to confirm they have seen it? Or do we want it automatically marked complete when they've simply viewed it or obtained a grade or passing grade or added a required number of entries? No need to select view as well as the requirement. To alert course participants that a database activity has been added or updated click send content change notification. After clicking save and display we come to a start page where we can choose either to create our database activity from nothing by creating new fields ourselves or to import a preset for example from MoodleNet or to use one of Moodle's presets. If we click use preset we can view and preview for presets which will make it easier to create our database. If we want to use the preset we click the button bottom right use this preset but instead we'll go back and click create a field. Fields means the information boxes course participants must fill in such as adding text a file or an image. Here are the available fields short text is useful for names or titles of entries and ticking required will force the student to enter something here. With image we can specify the size of image for list view and single view. Usually list view would be smaller than single view. Finally we'll add the coordinates field so students must enter the latitude and longitude of the location. Templates. Templates define how you want the fields displayed. Anything done to the single and lists templates here will determine how they look. The add template will determine what participants see when they click to add their entry and you can also set up an advanced search template. The simple way to set up your database easily is to click the save button for each template as we're doing with the add template now but you can edit templates also to improve the display. For example by removing or adding items from the available tags on the left or for instance if you want the list view to display as a table you'll need first to disable the code editor and then enter the code for the header and footer of your table and if you're comfortable with code you can also explore the CSS and other templates. Moodle's documentation will help. Now it's time for our students to add an entry adding a name, uploading an image and entering a geographical location. Our teacher will approve it from the three dots so that it can be viewed by all. To summarize the database activity allows you to build, display and search entries on a selected topic.


I'm Surma. I am a developer advocate for the open web platform and work with the Chrome team for Google and London. And I have the great pleasure today to talk about one of my newly found passions, which is WebAssembly. You have probably heard of it a little bit, and you can contact me on Twitter if you have any questions in the future. And later on, my colleague, Deepdy, from the Wasm Engineering team is going to talk a bit about the future of WebAssembly. Before we start, though, I wanted to bring us all onto the same page, because WebAssembly is often associated very tightly with C++. So much so that a lot of people think it is all about C++, when in fact, WebAssembly is so much more than that. Many of the demos that you can find online are about C++ and M-scripten. And that makes sense, because M-scripten is an absolutely amazing tool. But it is very important for web developers to realize that it's not just C++, and that WebAssembly by itself is actually a really useful tool to have in your back talket. And that's what I want to talk about in this talk. I want to show some other languages that support WebAssembly, how you can use WebAssembly maybe without learning a new language. And then, as I said, Deepdy is going to talk a bit about what the future of WebAssembly might hold. So to just make sure everybody knows what we're here for, this is WebAssembly.org, where we explain what WebAssembly is. It is a stack-based virtual machine. And if you don't know what a stack-based virtual machine is, that is absolutely OK. What is important, though, is that you realize it is a virtual machine, meaning it's a processor that doesn't really exist, but something that has been designed to easily compile to a lot of actual, real architectures. And that is called portability. So it is a virtual machine designed to prioritize portability. So when you write some code in whatever language, and you compile it to WebAssembly, that code will get compiled to the instruction set off that virtual machine. And then those instructions get stored in a binary format, usually in a .wasm file. And because that virtual machine is designed to easily compile to real processors, this file can now be ingested by a runtime, which in our context here is most likely the browser. The browser can turn that wasm file into actual machine code of the actual machine the browser is running on, and then execute that code. And from the very start, WebAssembly was designed to make that process secure. So yes, you are running code on your bare metal, but it's not an insecure thing. We already talked about WebAssembly at the last IO, actually quite a bit. It's a technology that's growing super quickly and actually also maturing at a very impressive pace. And we talked about how some big companies are using WebAssembly to bring their existing products that they probably wrote in C++, for example, to the web. So for example, there was AutoCAD, who had been working on AutoCAD for years, and it's a well-known product. But now they put in the effort of compiling it to WebAssembly, and suddenly it was running in the browser, which is kind of mind-blowing when you think about it. Another example would be the Unity game engine or the Unreal game engine, which now support WebAssembly. So these game engines often already have a kind of abstraction built in, because you build your game and then you compile it to a PlayStation or to Xbox or other systems. But now WebAssembly is just another target, and what is impressive is that the browser and WebAssembly are able to deliver the performance necessary to run these kind of games. And I find that amazing. And these things are going to continue to happen. So you have already seen in the web keynote that my colleague Paul Lewis built a Perception Toolkit, which helps you build kind of immersive experiences, and they wanted to build links into the real world in the form of QR codes and image detection. So QR codes can already be detected by browsers using the Shape Detection API, but not every browser has that implemented. So what they're doing is they're using that Shape Detection API, but if it's not available, they have cross-compiled Zebra Crossing, a QR code library to WebAssembly, and load that on demand to fill the gap if they find it. And image detection isn't on the web at all, so they built that themselves and used WebAssembly to give a new capability to a browser. The UI Toolkit QT announced that they're also supporting WebAssembly now. So that kind of means that you can now actually take an old LibQT app and compile it to WebAssembly, and then you have this weird window in a browser tab experience, which is not ideal, but it just shows that it works. But LibQT is a very powerful and generic UI library, so there's loads of demos on the website at the bottom where they actually built a kind of good and native looking UI using LibQT and WebAssembly. So if you don't know that much about WebAssembly, you might be asking, how did they do that? And the answer in these cases is M-Scripton. M-Scripton's goal is to be a drop-in replacement for your C or C++ compiler, and instead of compiling to your machine code, it spits out WebAssembly. And they really try to be a drop-in replacement. Whatever code you wrote to run on a system should just magically run on the web. And that's very important as a distinction to make, because M-Scripton does a lot of heavy lifting behind the scenes to make that happen. And I think because it works so well in these scenarios, is why it is so tightly associated with WebAssembly currently, because originally M-Scripton was an ASM.js compiler. So this was an idea by Mozilla, where they wrote this compiler that takes C code and turns it into JavaScript. So what you see on the right is ASM.js. It's just normal JavaScript. And every browser that can execute JavaScript can execute ASM.js. But the plan was to give some browsers an understanding of ASM.js so that they have a dedicated fast path to make these kind of programs run faster. So you have a chunk of memory, and you have some variables, and suddenly your C++ code can run in your JavaScript engine. But C and C++ often use other APIs, like file opening and maybe OpenGL. So M-Scripton made that work by using WebGL to pretend to be OpenGL and to emulate a file system so you can pretend to be working on real files. So they're basically emulating an entire POSIX operating system to make code run on the web that was never written for the web. So they hacked that happen. So when WebAssembly came along, M-Scripton just added a new output format, but kept all the work they had put into making that emulation. So M-Scripton was basically able to use all the experience that they had with making POSIX code work on the web and apply it to WebAssembly. So they were able to extremely fast, deliver extremely impressive and actually mature demos and tools around WebAssembly. And they deserve a lot of credit for taking everybody along with them and leveling out the playing field for all the other languages that have come along since. And I think that's why WebAssembly is so tightly is so good with C++ because of that quick maturity of M-Scripton. But what about web developers? How about you who might be working at a web agency or maybe even a freelance developer? How can WebAssembly be useful to you? Do you have to learn C++? Spoiler alert, no. When you are a web developer and you think, oh, I should learn C++ so I can use WebAssembly, many people end up like this. Because what even is C++ when you know JavaScript? And fun fact, it works the other way around as well. When I see a C++ developer see or write JavaScript for the first time, they make the exact same face. And I'm not saying that because one language is better than the other, but just because they require such a drastically different mindset to write. I have written both professionally. And whenever I switch, I twitch a little bit. It takes some time. It's just very different to think about. What I'm saying is there was so far no incentive for a web developer to learn C++. And so the amount of people who are comfortable in both worlds is fairly small. And as a result, WebAssembly seemed like a very niche technology when, in fact, it's actually a really useful tool to have in your back pocket. And so what I want to talk about is the two main use cases that I usually see when I think about WebAssembly. On the one hand, I want to talk about the surgical replacement of tiny modules in your JavaScript app, the hot path, the bottlenecks, with WebAssembly. And I want to talk about the myth that WebAssembly is faster than JavaScript. But first, I want to talk about the other facets, about ecosystems. It might seem a bit weird because nobody will probably disagree when I say that the JavaScript ecosystem is pretty huge. I mean, just look at NPM. It's massive. But it's just a fact that not for every topic, JavaScript is the first choice while other languages might be. So sometimes you're faced with a problem, and you're looking for libraries to solve these problems, and you find them in C or in Rust, but not in JavaScript. So you can either sit down and write your own JavaScript port, or your new option is to tap into another language's ecosystem using WebAssembly. And that's exactly what we did with Squoosh. Squoosh is an image compression app that runs completely in the browser and offline, no server side, and you can drop in images, and you can compress them with different codecs and then visually inspect how these different codecs have different effects on the visual quality of your image. Now, the browser already offers that, if you know, because with Canvas, you can decide in what image formats you want to encode an image, and you even get control of the quality. But it turns out that these codecs by the browser are optimized for compression speed rather than compression quality or visual quality. So that was a bit lackluster, to be honest. And also, you're kind of bound to the codecs that the browser supports. So until recently, only Chrome could encode to WebP and none of the other browsers. So that wasn't enough for us. And so we googled a bit, and we found some codec encoders for JPEG written in JavaScript. But they were kind of weird. And also, we didn't find a single encoder in JavaScript for WebP, so we thought we have to look at something else. And we found loads of encoders in C and C++. So WebAssembly. So what we did is we compiled, for example, the library called ModsJPEG into WebAssembly, load it in the browser, and replace the browser's JPEG encoder with our own. And what that allowed us is that we actually got much smaller images at the same visual quality setting, which is kind of cool. But not only that, it only also allowed us to expose loads of expert options that the library had, but that the browser obviously didn't expose. So things like configuring the chroma sub-sampling or different quantization algorithms are not only valuable to squeeze out the last couple bytes from an image, but also just as a learning tool to see how these options actually affect your image visually and the file size. The point here really is that we took an old piece of code. ModsJPEG goes back to, like, 1991. It was written definitely not with a web in mind, but we're using it on the web anyway and using it to improve the web platform. And we used M-scripten. So with M-scripten, to show you how that works, I usually find myself in a two-step process. The first step is compiling the library, something that you can link against later. Often image codecs make use of threads in SIMD, because image compression is a highly parallelizable task. But neither JavaScript nor WebAssembly have support for threads or SIMD just yet. Deepdy will talk about it a bit later what is coming on that front. But for now, we disable SIMD to make sure we don't want to do any problems.  This is the function that I want to call from JavaScript later on. So it takes the image, it takes the image dimensions, and then uses ModsJPEG to compress it and returns a typed array buffer, which contains the JPEG image. And once you have written this bridge code, we call emcc, mscripten-ccompiler, with our C++ file and the library file. Link it all together. And provided I didn't make any mistakes, we get this output, a JavaScript file that sets everything up for us and the WebAssembly file. Now, here is something to keep in mind. Because mscripten is a drop in replacement and does all these emulation and all that have you lifting for you, it is always a good idea to keep an eye on your file sizes, because these kind of file system emulations and API tunneling, that's code that needs to get shipped. So if you use a lot of C APIs, these files can become quite big, especially the JavaScript file. We have been working with the mscripten team quite intensely to help them keep it at a minimum, but there's only so much you can do if you want to be a drop in replacement. So keep an eye on your file sizes. Another example of WebAssembly in Scrooge is image scaling, because it turns out that making an image bigger or smaller, there's many ways to achieve that with many different visual effects and visual outputs. So with a browser, if you just use the browser to scale an image, you just get what you get. It will probably be fast. It will probably look good. But sometimes having control over the different variants of scaling an image can really make a big visual impact. So on this video, you can see me switching back and forth between the Langsoz 3 algorithm and whatever the browser has. And you can see that with Langsoz 3, I actually have a linear RGB color space conversion. I actually have a much more real perception of brightness in this picture. So in this case, it's actually a really valuable piece of code to have running. So these image scaling algorithms that we are using in Scrooge, we actually took from the Rust ecosystem. Mozilla has been heavily investing in the Rust ecosystem, and their team writes WebAssembly tools for Rust. But the community also abstracts those away to just generic tools. One of these tools is WasmPack, which really takes you by the hand and generates, turns your Rust code into WebAssembly modules that are more in JavaScript and really small. And I think it's really fun to play around with. So with Rust, same kind of principle. We have a library, and we want to write our little bridge code. So in this case, the resize function is what I want to call from JavaScript. It takes the image and my input size and the output size, and then I just return the resized image afterwards. And then you use WasmPack to just turn all of that into a WebAssembly module that you can use. Now, the size comparison is not quite fair, because it's a different library and it's a smaller library, so don't compare it byte by byte. But on average, Rust tends to generate much smaller glue code, which kind of makes sense, because Rust doesn't do anything of the POSIX file system emulation. You can't use a file function in Rust because it doesn't do file system emulation. They have some crates that you can pull in if you want to have that, but it's much more of an opt-in approach. So the bottom line is that with Squoosh, we are using four different libraries, at least, from two different languages that have nothing to do with the web, but we still proceeded to use them on the web. And that's really what I want you to take home from this entire thing, is that if you find a gap in the web platform that has been filled many times in another language, but not on the web or not in JavaScript, WebAssembly might be your tool. But now let's talk about the surgical replacement of hot paths in your JavaScript and the myth that WebAssembly is faster than JavaScript. Now it's really important to me, and that's why I came up with this really far-fetched visual metaphor. Both JavaScript and WebAssembly have the same peak performance. They are equally fast, but it is much easier to stay on the fast path with WebAssembly than it is with JavaScript. Or the other way around, it is way too easy sometimes to unknowingly and unintentionally end up in a slow path in your JavaScript engine than it is in the WebAssembly engine. Now that being said, WebAssembly is looking into shipping threads and SIMD, things that JavaScript will never get access to. So once these things ship, WebAssembly will have a chance to actually outperform JavaScript quite a bit. But at the current set of things, the peak performance is the same. To understand how this whole falling off the fast path happens, let's talk a bit about V8, Chrome's JavaScript and WebAssembly engine. JavaScript files and WebAssembly files have two different entry points to the engine. JavaScript files get passed to Ignition, which is V8's interpreter. So it reads the JavaScript file as text and interprets it and runs it. While it's running it, it collects analytics data about how the code is behaving. And that is then being used by Turbofan, the optimizing compiler, to generate machine code. WebAssembly, on the other hand, gets passed to lift off the streaming WebAssembly compiler. And once that compiler is done, Turbofan kicks in and generates optimizing code. Now there is some differences here. The first obvious difference is that the first stage has a different name and a different logo. But there's also a conceptual difference. Ignition is an interpreter, and lift off is a compiler that generates machine code. So it would be an overgeneralization to say that machine code is always faster than interpreted code, but on average it's probably true. So here's already the first difference in terms of speed perception. But more importantly is this difference. For JavaScript, the optimizing compiler only kicks in eventually. This code has to run and be observed before it can be optimized, because certain assumptions are made from the observations. Machine code is generated, and then the machine code is running. But once these assumptions don't hold anymore, you have to fall back to the interpreter, because we can't guarantee that the machine code does the right thing anymore. And that's called a deopt, a deoptimization. With WebAssembly, Turbofan always kicks in right after the lift off compiler, and you always stay on the lift off, on the Turbofan outputs. You always stay on the fast path, and you can never get deopted. And I think that's where the misconception comes from that WebAssembly is faster. You just always get easier to get deopted in JavaScript, and you cannot in WebAssembly. And Nick Fitzgerald from the Rust WebAssembly team actually did a really nice benchmark that he wrote a benchmark in both JavaScript and WebAssembly. JavaScript is red, WebAssembly is blue. And run it in different browsers. And what you can see here is, yes, OK, WebAssembly is faster, but the main takeaway really here is that JavaScript has to spread. It is kind of unpredictable in how long it takes. Well, WebAssembly is spot on, always the same time, even across browsers. And I think that is really the key line I would like you to take home with you. WebAssembly gives you more predictable performance. It delivers more predictable performance than JavaScript. And that's actually a story I can tell as well from Scooch. We wanted to rotate an image. So we thought, OK, let's use Canvas, but we couldn't because Canvas is on the main thread. Offscreen Canvas was barely in Chrome at that point, so we actually ended up writing a piece of JavaScript by hand to just reorder the pixels to rotate the image. And it worked really well. It was very fast, but it turns out the more we tested in other browsers, the more it became a bit weird. So in this test case, we are rotating a 4K by 4K image. And this is not about comparing browsers. This is about comparing JavaScript. The fastest browser took 400 milliseconds. The slowest browser took eight seconds, even off the main thread. That's way too long for a user pressing a button to rotate an image. And so what you can see here really is that we clearly stayed on the fast path in one browser, but we fell off the fast path in another. And the browser wasn't usually a fast browser. Just some browsers optimized differently. And so we wrote our rotate code in WebAssembly, or in a couple of languages that compiled to WebAssembly, to compare how that performs. And what you can see here is that pretty much all the WebAssembly languages bring us somewhere around the 500 millisecond mark. I would call that predictable. I mean, there's still a bit of variance, but nothing compared to the variance of JavaScript. And that's a logarithmic scale. And also what you can see here, I just noticed, is that the head-to-head performance of WebAssembly, the peak performance of WebAssembly in JavaScript, is pretty much the same. So if you look at the graph, you might be wondering what assembly script is. And if you haven't, I'm really excited about this, because assembly script really brings me back to the title of my talk, which is WebAssembly for Web Developers. Assembly script is a type script to WebAssembly compiler. Now, that might mislead you, because you can't just throw your existing type script at this compiler and get WebAssembly out of it. Because in WebAssembly, you don't have DOM API, so that you can't just use the same code. But what they're using is the type script syntax with a different type library. So that means you don't have to learn a new language to write WebAssembly, which I think is kind of amazing. So that's what it looks like. It's like type script just with a couple of minute differences in that something like i32 is not a type that JavaScript has, but it is a type that WebAssembly has. And then there are these built-in functions like load and store that put values onto the memory or read them from memory. And the assembly script compiler turns those into WebAssembly modules. So you are now able to write WebAssembly without learning a new language and harness all these benefits that WebAssembly might offer to you. And I think that's kind of powerful. Something to keep in mind is that unlike type script, WebAssembly doesn't have a garbage collector, at least not yet. And DeepD will talk about this a bit more later. So at least for now, you have to do memory management yourself. So assembly script offers a couple of memory management modules so you can just pull in, and then you have to do the C-style allocations. It's something to get used to a bit, but it's very much usable right now. And once WebAssembly does get garbage collection, it could get even better. So that's one of the full disclosure. Assembly script is a fairly young and small project. It has a group of extremely passionate people behind it. It has a couple of sponsors, but nothing compared to Mozilla behind Rust or M-scripten. That all being said, it is absolutely usable and very enjoyable. My colleague, Aaron Turner, wrote an entire emulator in assembly script. And so if you're interested in that, you should look him up on GitHub and take a look at the code. Now, one thing that I want to make sure that I say out loud is, at the current state of affairs, putting everything in wasm is not a good idea. Java and WebAssembly are not opponents. There is synergy between them. Use them together. One doesn't replace the other. Like debugging is going to be harder, and code splitting is much harder with WebAssembly currently than it is with JavaScript. And you have to call back and forth. It's just not going to be a great experience. I had some people treat it me that they want to write their web components in C++. I don't know why they would want to do that, but apparently they want to do that, but I wouldn't recommend it. What I would like to say is, WebAssembly is the right things. Do some performance audits. Do measurements. Where are your bottlenecks? And see if WebAssembly can help you. Did you find a gap in the platform? And you can fill it from a different language. Again, WebAssembly is your tool. But now to talk a bit about the future of WebAssembly and the upcoming feature, I would like to welcome Deepty to the stage. Thanks, Surma. Hi, everyone. I'm Deepty. I'm a software engineer on the Chrome team, and I work on standardizing WebAssembly features as well as implementing them in V8. Sorry about that. So most of what you've seen in this presentation so far has landed and shipped in all major browsers, which is the MVP or the minimum viable product of WebAssembly. And we've been working hard on adding capabilities to make sure that we get closer and closer to native performance. The MVP itself unlocks a whole set of new applications on the web, but this is not the end goal. And there are a lot of new exciting features that the community group and the implementers are working to enable. The first one of these is the WebAssembly threads proposal. The threading proposal introduces primitives for parallel computation. Concretely, that means that it introduces the concept of a shared linear memory between threads and semantics for atomic instructions. Now, why is this necessary? There are many existing libraries that are written in C or C++ that use P threads, and those can be compiled to Wasm and run in multi-threaded mode, allowing different threads to work on the same data in parallel. Aside from just enabling new capabilities for applications that benefit from multi-threaded execution, you would see performance scale with the number of threads. So the threading proposal builds on primitives that already exist in the web platform. The web has support for multi-threaded execution using web workers, and that's exactly what's used to introduce multi-threaded execution to WebAssembly. The downside of web workers is that they don't share mutable data between them. Instead, they rely on message-passing for communication through post-message. So they rely on message-passing for communication. So each of these WebAssembly threads runs in a web worker, but their shared WebAssembly memory allows them to work on the same data and making them run close to native speeds. The shared linear memory here is built on the JS shared array buffer. So if you look at this diagram, each of these threads is running in a web worker and can have a WebAssembly instance that's instantiated with the same linear memory. This means that the instances operate on the shared memory but have their own separate execution stacks. So the API to create a WebAssembly memory remains almost the same. If you look at the first line there, you create a WebAssembly memory with a shared flag and a mandatory maximum. This creates a shared array buffer underneath with the initial size that we've specified there, which is one page of memory. So with all of these threads operating on the same memory, how do we ensure that the data is consistent? Atomic modifications allow us to perform some level of synchronization. So when a thread performance and atomic operation, the other threads see it as happening instantaneously. But full synchronization often requires actual blocking of a thread until another is finished executing. So the proposal has an example of mutex implementation, and I pulled out how you would use this in a JavaScript host. If you look at it closely, there's subtle differences between what you would do in a worker versus what you would do on the main thread. So on the main thread, the tryLockMutex method is called, which tries to lock a mutex at the given address. It returns one if the mutex is successfully locked, or zero otherwise. And on the worker thread, it will lock a mutex at the given address retrying until it's successful. So basically why this is the way it is is that on the web, you can't actually block the main thread. And this is something that's useful to keep in mind when using the threading primitives. So what is the current status of this proposal? The proposal itself is fairly stable, but there's ongoing work to formalize the memory model that's used by the shared array buffer. The thing I'm really excited about here is that this is shipped in Chrome 74 and is on by default. So Surma mentioned Qt earlier in the presentation, and Qt uses full thread support. So this is something that you can use in your applications today. As the shared memory primitive here is the JavaScript shared array buffer, and that's temporarily disabled on some browsers, WebAssembly threads is not currently available by default on all browsers. But you can still try this out in Firefox Nightly behind the flag. One of the goals of WebAssembly is to be a low-level abstraction over modern hardware. This is especially true of the WebAssembly SIMD proposal. SIMD is short for Single Instruction Multiple Data. It lets one instruction operate at the same time on multiple data items. So most modern CPUs support some subset of vector operations. So this proposal is trying to take advantage of capabilities that already exist in hardware that you use every day. The challenge here is to find a subset that is well supported on most architectures, but also is still performing. Currently, this subset is limited to 128-bit SIMD. There are a couple of different ways to use the SIMD proposal. By using auto vectorization, you can pass in a flag to enable SIMD while compiling, and the compiler would auto vectorize your program for you. On the other hand, many SIMD use cases on niche and highly tuned for performance. And use hand-coded assembly. So these would be using Clang built-ins or intrinsics that generate machine code that is tuned for performance. Now, SIMD can be used for a large variety of applications. So you can use it for image or audio video codecs, applications like Google Earth and Photoshop, or even machine learning applications on the web. We've had a lot of interest for WebML and SIMD collaborations as well. So let's take a closer look at how this data is operated on. Here you see a simple example of an ad instruction on an array. Let's say this is an array of integer values. So on the left side is what a scalar operation would look like, where you add each number to the other and store the result. The vector version of this would just boil down to one hardware instruction, for example, a P add or a VP add on some Intel architectures. So SIMD operations work by allowing multiple pieces of data to be packed into one data word and enabling the instruction to act on each piece of data. This is useful for cases where the same operation has to be performed on large amounts of data. For example, take image processing. Say you want to compress an image in Squoosh or reduce the amount of color of an image in Photoshop by half. So SIMD operations would actually make this a lot more performant. So we've talked about making use of underlying hardware capabilities and always capabilities to make your applications performant. Now let's look at what happens on the other side. What are we doing for better interop with the host? One of the proposals that's being implemented by multiple browsers is the reference types proposal. With the reference type proposal, WebAssembly code can pass around arbitrary JavaScript values using the any ref value type. These values are opaque to WebAssembly, but by importing JavaScript built-in functions, WebAssembly modules can perform many fundamental JavaScript operations without actually requiring JavaScript glue code. So the WebAssembly table object is a structure that stores function references at a high level. So this reference types proposal also adds some table instruction for manipulation of tables inside of WASM. The neat thing about this is that the reference types proposal is actually setting up, setting the stage for really useful future proposals. So for efficient interop with the host for the WebIDL proposal or exception references for exception handling, and it also enables a smoother path to having garbage collection. And I'll be talking about all of this in the next few slides. So a proposal that our team will be focusing on in the near future is the WebIDL bindings proposal. WebIDL is an interface definition language, and it can be used to define interfaces that are implemented in the web. We touched on this a little bit with the reference types. The basic idea here is that this proposal describes adding a new mechanism to WebAssembly for avoiding unnecessary overhead when calling or being called through the WebIDL interface. The WebIDL bindings proposal would allow compilers to optimize calls from WebAssembly into existing web APIs and browser environments today, as well as other APIs that may use WebIDL in the future. So let's take a closer look at this. So when you have a WASM function, you would call this call a JavaScript through the JS API. The JS API goes to the binding layer that facilitates communication between the JS API and the web APIs for DOM access. This adds a lot of glue code and additional overhead. The goal of the WebIDL bindings proposal is to reduce this overhead and optimize calls from WebAssembly into existing web APIs. So effectively, this would not have to go through the JS API. And the bindings would also be optimized to reduce the overhead. So you would have streamlined calls between WebAssembly and Web APIs. So currently, when we talked about C, C++, Rust, and porting these languages to WebAssembly is very well supported. And there's a lot of work ongoing to bring different classes of other languages to the web. One such feature is garbage collection, which is necessary for efficient support of high-level languages. That means faster execution, smaller modules, and outside of C, C++. This is really a requirement for being able to support a vast majority of modern languages. This is also a large and open-ended problem. But we've been making progress by carving out smaller proposals and honing in on the exact design constraints. So currently, WASM design explicitly forbids tail-call optimizations. In the future, we want to enable correct and efficient tail-call implementations of languages that require tail-call emulations. So these would be functional languages like Haskell. We8 already has an implementation for this, and this is actually moving along quite well. So for full C++ support, we need exception handling. In a web environment, exception handling can be emulated using JavaScript. Exception handling, which can provide the correct semantics, but really isn't fast. So post-MVP WebAssembly will gain support for zero-cost exception handling. And this is something that is being actively worked on as well. We're also working on a number of other proposals. So feel free to check out the future features documentation on the WebAssembly GitHub page. The other thing I want to emphasize is that a lot of these are in the design phase. And if you're interested in wanting to participate, all of the development is done in an open community group, so contributions are always welcome. We also talked about performance. So if you have performance bottlenecks and you've used WASM to elevate some of the concerns, we'd love to hear from you. Sriman and I are going to be hanging out here and later in the web sandbox. So if you have questions, please come find us there, or obviously find us online. Thank you.


here works hello hello everyone my name is Laura and this is my channel Lord's Little Library so today's bullet journal is going to be a little different I wasn't sure if I was going to do one this month then I decided I do need a bullet journal so what I've done is I've actually completed my bullet journal so you're not gonna be watching me do it fill it out with color it's just gonna be a flip through I'll still have my regular voice over but I decided that because of my energy levels due to COVID I thought it would just be easiest on me to show it to you guys this way so it's for December obviously and I didn't really have a theme throughout the entire thing I just thought this would be a pretty cover page I really liked how November's looked just with the array of colors so I decided to do something similar I have my TBR page and my books read page first as I did last time however I'm thinking I might want to change the order of things I like having these back-to-back so I can see what I wanted to read and what I did end up reading I also decided that my TBR was only going to be three things this month because of read-a-thons then I have my rankings page and my read-a-thon page rankings page I found to be very helpful at the end of the month and I am participating in the reindeer read-a-thon then I have my calendar I decided that for next year I might want to put my calendar more as probably the first spread as it is kind of the basis for majority of the things that I plan in my bullet journal but I wanted to keep it simple spread I just have a books coming out this is just for December so I can keep track of the books coming out this year and books to buy with my new $20 a month system I decided to coordinate what books I want to buy what month so I can keep track of buying either new books or books off of thrift books just so I can really have a better handle on controlling how much I am buying and then I decided to organize my YouTube and other social media pages a little bit more by adding boxes just to make the organization neater and so far I've already found this to be very helpful rather than just a blank page strewn about with notes same with Instagrams and with my reviews I decided to block off special areas for title author and rating and then I can have empty space below for my notes as usual but this way I can just have a little bit of a better neater system for it and then at the end I have my 2021 wrap up this is just for the end of the year and it's going to help me with some of my end of the year videos so thank you all so much for watching this video I know it was a little different than normal but hopefully by the time January rolls around I should be back to normal with doing the actual bullet journal as you're watching if you liked this give it a thumbs up and maybe I can do something similar to this in the future otherwise feel free to subscribe and hit the bell to be notified as I will be posting a lot of videos soon and follow me on my social media down below see you in the next video I wish you happy reading


It's not uncommon to see headlines like company X makes bumper profits or bank Y suffers record loss. Earning season is a busy time for businesses, usually every quarter in fact, and once a year the same applies to central banks. We've just published our annual accounts. They're basically an overview of our financial position at the end of 2022, and they showed zero profit for the year. In fact, we drew on provisions that we'd set aside in previous years to avoid making a loss. That's the topic we'll be discussing today. We want to explain how central bank losses and profits come about and what they really mean for people. We'll also ask if it even matters whether a central bank makes a profit or a loss. You're listening to the ECB podcast, bringing you insights into the world of economics and central banking. My name is Katie Ranger. I'm joined in the studio by one of our press officers here at the ECB, William Lelyfield, who's going to break all this down for us. William, great to have you here on the podcast. Yes, thank you, Katie. I'm very excited to be here. Now, before we start, I just want to give a bit of info as to why this topic is relevant at the moment. In today's difficult economic environment, central banks across the world are either making or warning of losses. It's important to remember, though, that central banks are not like ordinary companies. They can lose money and still operate effectively. A small disclaimer before we start. In our conversation today, we will be talking about where profits and losses can come from in the euro system. So that's the ECB and the central banks in the 20 countries using the euro. Now, William, we've got all that out the way. Let's start with the basics. A central bank doesn't work towards making a profit. Its aim or its mandate is actually to keep prices stable. So tell me, where do profits come in all of this? Yes, as you say, we are a public institution, but like any like an ordinary company, we can make profits and losses. But making profits or avoiding losses at all costs is not our aim. Our aim is to keep prices stable. So they're basically a byproduct of what we do of our mandate. So if we do generate profits, where does that income come from? So for a central bank like the ECB and national central banks of the euro system, our profits typically come from the assets that we hold. So these can be bonds that we hold. It can be interest rates that bank pay us when they borrow money from us. And we also have foreign reserves, which also pays us an interest. So these interest rates basically are our main source of income. So for example, you said loans, the banks take from us. So just like I have a loan from the bank, I pay the bank interest and the bank pays the ECB interest. All right. So if this income is bigger than our costs, then we make a profit, obviously, just like any other normal company. What do we do with that profit? So what we do is we first set aside some of it, because we want to be prepared for times when maybe profits are not so big. Whatever is left, then we distribute among our shareholders. And our shareholders are the national central banks, and they usually distribute it to their shareholder, which is nine out of 10 times the national finance ministry. Okay. So that's the profits. Let's look at the other side of things. What things can be a cost for us? So when banks deposit money with us and banks do deposit money with us, because they have accounts with us, just like citizens have accounts with commercial banks. Commercial banks have accounts with the Euro system, and we pay interest rate on these deposits. And that's, I would say, the biggest source of costs. And that's linked, for example, to one of the key interest rates that we set every six weeks, right? Exactly. When we set interest rate, we set three interest rates, and one of them is the deposit facility rate. And this is what we pay the banks. And currently, this percentage is two and a half percent. All right. So these losses that we've seen this year have been down to different things, some of them a little bit more tricky to explain than others. But this last point that we talked about, the interest rates, this is key here because they're closely linked to some of those losses. I just want to zoom out a second to look at the economic environment that we're in right now, because it's also important. Inflation is high, and we are raising our key interest rates to tackle that, including the deposit facility rate that we just talked about. William, what does all of this mean for our profits and losses? Can you really take us through what's going on step by step? Yes. So what happened? We recently increased our interest rate again with half a percentage point. And this has been going on since July 2020? Yeah, exactly. So the amount that we pay on this deposit facility, on the money that banks pay with us, is increasing quite rapidly because we are currently already at two and a half percent, and it doesn't look like we're done yet. So we are faced with increasing costs in this deposit facility. And on the other side of this, our income on the bonds that we hold, the interest rate on bonds that we hold is quite low because many of the bonds that we bought had long maturities, so we're stuck with them for a very long time. And maturity means it's the promise that you get repaid. So if you buy a bond with a maturity of 20 years, that means that in 20 years you get your money back in these 20 years towards the date of maturity, you will get an interest rate every year, but you will get your money back only in 20 years. For a five-year bond, you will get your money back in five years, for a one-year bond and one year. Okay, so let me recap quickly. We have been raising interest rates. This cost that we have linked to the increase in interest rates that we pay on bank's deposits is going up, but the income that we're getting is not going up at the same rate. So there's a mismatch in our income and our costs. And part of this is linked to the fact that in recent years we bought all of these bonds with very long maturities and very low interest rates, which means that the income we get will not change for quite a while, at least not in time for it to be matched up with the costs. Exactly. All right, so we've got it clear where the losses have come from. But the whole thing about the bonds, it makes me wonder why didn't we buy bonds with higher interest rates? And here I come back to what I've said before. So everything we do has a monetary policy reason. And back then we were in a period of too low inflation, which is maybe a bit difficult to imagine at the moment. But it's not that long ago. And to tackle too low inflation, we bought a lot of bonds with long maturities and low interest rates to help us reach our price stability objective. William, could we have done anything to avoid these losses? Only theoretically. Theoretically, we could have sold the bonds when they were still worth more than they are at the moment. But we are not in the business of, let's say, buying and selling bonds just to make profits or avoid losses. We are in the business of doing monetary policy. And back then we had a good monetary policy reason to buy these bonds. And now we have a good monetary policy reason to keep these bonds until, as we said, maturity. And it's also perfectly normal that in good times we make profits. And then we set some of these profits aside so that in less good times we have a buffer to cover these losses. Like we've seen this year. Like we've seen this year. That we ended up at zero, despite having losses. Now, what do the losses actually mean? I mean, what do they mean for people? Do they hurt anyone? Well, the benefit that that that national central banks and via the national central banks, the finance ministries and via the finance ministries, the taxpayers would get if we have profits, of course, is not coming. So in that sense, we distribute less profits. And that that is, of course, not something that finance ministries like like to hear and probably taxpayers also know. But we have made profits in the past. So in the past, we have been making transfers to the finance. Yeah, we have made huge transfers actually. So the euro system as a whole has made three around 300 billion in profits since 2012. The ECB alone around 13 billion. So we have transferred a lot of these profit to taxpayers. Yeah. And now this time, we can't. And if we hadn't had enough provisions, what would have happened there? Then we would have made losses. So outright losses. So even below the line, there would have not been a zero as we have now, but there would be a negative number. And this could potentially be covered by income that the national central banks, our shareholders make. And if that would not be enough, we could theoretically also function with, with, let's say, negative capital. And that's what I said at the beginning, right, that central bank can make a loss and still operate effectively, not like a normal company, which would go bankrupt. Exactly. Okay. So overall, all fine for this year. What's ahead of us though? Do we expect to make more losses in the near future? Yes. Unfortunately, it looks like there will be a few more years where we will experience losses. But gradually, the situation should improve. Because on the one hand, the interest rates on our assets, on our, for example, the bonds that we hold, but also the interest rates on loans that we will be providing to banks again, is much higher than the interest rate that we are getting now. And that should then match, and more than match ideally, the costs that we make on this, on this deposit facility that I mentioned before. So then the mismatch between income and costs will start to balance out. Exactly. Okay. Thank you so much, William, for breaking all that down. Now, before we wrap up, we always have a question that we ask all our guests on the podcast. And that's for a hot tip linked to the topic we're discussing today, very broadly linked, shall we say? Have you thought of something to inspire our listeners? So, Katie, you already warned me that this question would come, and I was a bit struggling to find something nice. And to avoid the obvious money by Pink Floyd, I thought it was nice to go with a song called Money Talks by ACDC, which is one of, I would say, my favorite. There are actually three songs that I'm aware of that have Money Talks in their title. And so there's something for everyone. There's a sort of a house type of song from, I think, the 90s by a band called The Adventures of Stevie V, which is called Money Talks. And for their very old listeners, there's also a version by the Kings. Okay, we should have said at the beginning that William is a big music fan. So I'm not surprised that your hot tip is song or songs here. But that's great. Thank you so much, William. It was a pleasure. Well, that brings us to the end of this episode. I want to thank William Lelefeld, press officer here at the ECB for explaining everything about central bank profits and losses. As usual, you can check out the show notes for additional material on this topic. You've been listening to the ECB podcast with Katie Ranger. If you like what you've heard, please subscribe and leave us a review. Until next time, thanks for listening.


Hi, I'm Chris Harrelson, the Blink Rendering Lead for Chrome. I'm in charge of teams whose areas of expertise span from parsing HTML and DOM APIs to translating all of that into rendering concepts like display lists, composited layers, and arresterized textures that can integrate with your computer's multi-core CPU, accelerated GPU, and high-resolution touch screens. And if you don't know what a display list or layer is, that's OK. In this video, I'll give an introduction to those concepts. And if you want to learn even more, the RenderingNG blog posts explain it all. Over the past eight plus years, we've been hard at work on a complete next generation re-implementation and architectural upgrade of the entire rendering pipeline of Chrome that I call RenderingNG. NG stands for Next Generation. We embarked on this effort because feedback from developers told us very clearly that browser rendering implementations were not good enough for the demands of the user experiences developers need to build. So we set out to change that in Chrome. Fixing all of it was an enormously difficult and complex challenge, but also critically important. And I'm happy to announce that as of this year, the architectural upgrade is done. The RenderingNG architecture puts in place a rendering pipeline with clearly defined pipeline phases. It uses data structures that can easily be passed across threads and processes. It supports running all animations and scrolls off the main thread in all cases. And it has excellent security and performance isolation for tabs and iframes in order to get the best possible performance. There were three main areas in which Chrome in particular was not good enough, reliability, performance, and extensibility. Developers had many complaints about bugs and inconsistencies between browsers. They reported it was impossible to achieve 60 frame per second animations or load complex pages fast enough. And they wanted to explore user experiences beyond just the affordances built into the browser, but were struggling to achieve them. We set out to solve each of these areas in turn. Reliability has to come first. There's no way to add product features if it isn't rock solid to begin with. So we spent quite a long time fixing bugs and adding testing to the existing system before being ready to reimagine that system. For example, we fixed an enormous number of subtle bugs in the layout subsystem alone. As we described in the LayoutNG deep dive blog post, there were a few root causes of these bugs that had to do with the pre-rendering NG architecture not being up to the task. And we set up mechanisms to continuously monitor and improve quality over time, including bug and regression SLAs and benchmarks such as Compat 2021. Next up came performance. There we had the goal of enabling developers to easily utilize all of the powerful hardware in today's devices to their full potential. But there's also the goal of making the browser as efficient as possible, preserving battery life and providing a good user experience regardless of whether the device was on the high or low end of capabilities. Finally, we planned for extensibility. We want developers to be able to achieve the user experience they want, but in a way that takes advantage of the power of the browser for excellent performance, accessibility, and reuse of existing built-in features. To do so, we designed the architecture very carefully to provide extension points for developers in just the right places. Now, let's briefly go over the key projects that make up rendering NG. Composite After Paint is a project to disentangle compositing from style, layout, and paint so that we can increase throughput and use less memory without sacrificing performance. Composite After Paint also fundamentally improves our ability to achieve additional performance isolation of animations from JavaScript. Layout NG is a ground-up rewrite of all layout algorithms for greatly improved reliability and more predictable performance. Blink NG is a systematic cleanup and refactoring of the Blink rendering engine into cleanly and separated pipeline phases. This work proceeded continuously and completed this year. GPU acceleration everywhere is a long-term effort to roll out GPU rasterization, draw, and animation on all platforms all of the time. Threaded scrolling, animations, and decode is a long-term effort to move all scrolling, non-layout-inducing animations, and image decoding off the main thread. Viz is a centralized raster and draw process for Chrome that increases throughput, optimizes memory, and allows for optimal use of hardware capabilities. Threaded and accelerated canvas rendering is the project that put in place the architectural pieces that made off-screen canvas possible. And finally, Video NG is a long-term effort to provide efficient, reliable, and high-quality video playback on the web. Now I'd like to give a brief overview of how the rendering NG architecture works on the inside. The entire system is organized into a high-performance rendering pipeline with a number of stages, each of which performs a well-defined task. If you're a web developer, the inputs to the pipeline are familiar, DOM, style sheets, fonts, images, video. But the magic and the mystery of browsers is what exactly they do to turn all that into pixels. The pipeline starts with animation updates, then runs style, layout, pre-paint, scroll, paint, commit, layerization, raster, activation, aggregation, and finally draw. And along the way, the pipeline creates a number of intermediate data structures. I'll talk about those data structures in a bit, but first let me draw your attention to the colors of the pipeline stages that you can see here. Green, yellow, and orange. These colors have to do with which thread or CPU process is running these stages. Green is the main thread, yellow is the compositor thread, and orange is the Viz process. Because not only are there 12 stages and seven or more key data structures, the whole thing is highly parallelized. Rendering NG makes maximal use of multiple CPU processes and threads to achieve performance isolation, parallelism, and security sandboxing. Each distinct site is placed in its own render process. This means that different tabs and windows from different sites run in parallel and don't jank each other. It also means that cross-origin iframes such as ads within a site don't slow down the site and vice versa. Likewise, the browser UI is fully isolated from the performance of browser tabs, that you always be able to control the browser regardless of site performance. Finally, all graphics are centralized in a Viz process, which can integrate iframes, tabs, off-screen canvases, video, and the browser UI into an optimized GPU rendering system that takes full advantage of your computer's capability without loss of efficiency or security. Within each process, there are a number of CPU threads. This allows operations such as JavaScript, scrolling, and image decoding to all happen in parallel. And it's all optimized to maximize throughput, smoothness, and responsiveness of scrolling your page interactions and animations. And finally, there are well-defined components within each thread and process to access all of the web platform APIs, process input from touch devices, mice, and keyboards, and schedule work efficiently and fairly. The renderer main thread has the DOM APIs with which you may be familiar and also runs JavaScript. The render compositor thread runs animations, handles input, and composites and rasters content. Here is an example set of pages and iframes. Let's see how that example maps to the above concepts in practice. First, CPU processes and threads. As you can see, there are a lot of them. However, each one falls into the groups I mentioned earlier and following that pattern, the browser can scale well to many tabs and sites at once with good performance. Second, here is how the rendering pipeline flows through those components in order to update rendering on the page. In this example, a change to the DOM starts in the main thread via a page loading, JavaScript changing page state, or a built-in browser feature doing the same. The steps go from the main thread all the way to this and back multiple times in a complex, coordinated dance. But code structure is not all. There are several key data structures that underpin the entire architecture. These data structures are the key to defining clear inputs and outputs to the pipeline stages. They are also critical parts of being able to safely, correctly, and efficiently accelerate and make extensible any kind of UI developers might put on their site. HTML and CSS have a huge variety of ways to express visual designs and it's really important to be able to accelerate all of them, not just to select subset. Frame trees are a way to represent the hierarchy of pages and iframes for a browser tab. Without this data structure, security and performance isolation of cross-origin iframes would not be possible. In the flow chart shown here, you can see that there are a number of steps in merely resizing a webpage that have to be coordinated across multiple processes because there could be one or more cross-origin iframes embedded within a page and those iframes also need to be resized. The immutable fragment tree represents the output of layout but also the input to feature layouts. This data structure is the key to how layout and G massively improve the reliability of the layout pipeline phase. Property trees are at the center of a lot of things but in particular are the key data structure that makes it possible to clearly express the visual hierarchy of a webpage. This in turn makes it much easier to accelerate animations and rendering of all content. The example property trees shown here are for a relatively simple setup of a scroller with rounded corners containing an iframe plus a rotations transform and a blur filter. As you can see, the property trees are already somewhat complicated. It can get much more complicated on a real page with many moving parts but due to the clean and thorough design of property trees, the system scales easily to these cases without massive complications. Display lists and paint chunks are critical keys to being able to not just efficiently paint a webpage but also composite it onto the GPU in a maximally performant and efficient way. And last but not least, compositor frames are how the browser can coordinate drawing multiple kinds of content on the screen while still allowing them to be computed in parallel on different CPU processes and threads. So that is a whirlwind tour of rendering NG. But what now? We have all this technology. What kind of things is it unblock? What kind of new features can we build on the web with it? The first thing worth noting is that rendering NG greatly improves the performance of all websites. Their render, animate, process input and scale much better than before and all without developers having to do anything. In fact, the speedups have been coming at a regular clip for over eight years now behind the scenes. As I explained in a blog post recently as part of the Fast and the Curious series, the composite after paint feature alone improves scroll latency, responsiveness, peak rendering speed, GPU memory use, time spent rendering and battery life by significant factors. In addition, there are important new developer APIs that the community has desperately wanted for many years, but browsers were unable to implement. Rendering NG has made many of these APIs possible and in fact, we have already shipped some and more are on the way. Let's walk through some examples. Container queries, the number one feature request in the state of CSS survey for several years running is an API to let components be responsive to their embedding context, not just to the size of the viewport. Async rendering allows the browser to only render what you need on the screen without forcing the developer to virtualize content. Scroll linked animations add support for moving content in precise lockstep with the scroll gesture. Shared element transitions add animations during single page app and multi-page app navigations to make them much more seamless. And finally, Offscreen Canvas is the very first web API that allows a developer to run their own rendering code off the main thread. I'm excited to see what web developers will build on top of this technology. And again, if you're interested to learn more, please check out the whole blog post series, which has much more detail than I could fit into this short video. And watch for more blog posts to come on additional parts of rendering NG. Thanks for listening.


Hello welcome back on my YouTube channel. In this video I'm going to demonstrate how to delineate the catchments that drain into a lake. Here you see a DEM, but inside this DEM is a lake. However the DEM has values there too, and we need to mask those if we want to delineate the catchments. We don't want those pixels to be taken into account in the delineation procedure. You need to follow the same procedure if you want to delineate catchments that drain into a sea or an ocean. First we need a lake polygon. We can download the lake polygon using the quick osm plugin which downloads features from OpenStreetMap. I install the plugin from the Plugins Manager. After installing the plugin I can click this icon and the first time I use it I need to accept the terms. To get the lakes I choose as key, natural and value, water. I define the extent as the layer extent of the DEM and I choose under advanced that I only want the multi polygons. Then I run the query. Now the lakes are downloaded. Note that also lakes outside of our area of interest are downloaded because the DEM extends the area with no data values. I select the polygon that we need and I click export save selected features to a geo package and let's create a new geo package which I call LakeData and I call this layer Lake. I change the projection to the one of the project and click OK. Now we have a new layer that only consists of the lake polygon that we need in the rest of the process. Let's style this layer. I'll just quickly do that in another video. I've covered how to do this in more detail. Now we can remove the downloaded lakes but we only have our lake and DEM left. Now I need to create a polygon layer with the extent of the study area and I use here expect layer extent. With this tool I can create a polygon with the layer extent. I choose the DEM and I save the result to LakeData and I call the layer extent. After clicking run you can now see that there is a polygon covering the extent of the DEM layer. The next step is that we need to cut the lake polygon out of this extent polygon and I use the difference tool. As an input I choose the extent polygon and as an overlay the lake polygon and in this way the algorithm will extract the features that are outside of this lake polygon. I save it to the same geo package and I call this layer difference. Here you see the result. Let's remove some layers. Here we see the extent polygon with a hole at the location of the lake and if I overlay it with the DEM then you see the part that we need to mask. We can mask the DEM now by using raster extraction clip raster by mask layer. As an input I choose the original DEM. As a mask layer I choose the difference polygon and I assign minus 9999 as the no data value and I keep the resolution of the input raster. In fact this makes a copy of the DEM but it masks the lake area to the no data value and I call the result DEM masked. Let's run it and here we see the result and that's the DEM with the masked lake. Because we are going to process this DEM with the PC raster tools plugin I'm going to convert this DEM to the PC raster data format. I use the convert to PC raster format tool. I choose DEM masked as an input. I choose scalar as the output data type because it's a continuous raster and I choose DEM lake masked dot map as the output file name. This just creates a copy in the PC raster format. The next step is to create a flow direction map. We use the LDD create tool which fills the syncs and results in the flow direction map. I keep the defaults and I save the result as flowdirection.map and here is the result. The next step is to use the pit tool to find all the outlets at the lake shore. The pit tool will find all the syncs that are left in our area. I call the result outlets.map. Now every pit has a unique value so I can style this with the palleted unique values renderer. I just use random colors and click specify. Now you see here that every pit at the lake shore has a unique value. We're going to use these outlets as the input for the catchment tool. Let's go back to the processing toolbox. There I choose the catchment tool. The catchment tool needs a flow direction layer as an input and the new outlets layer. I save the result as lake catchments. Then I run it and it delineates all the catchments related to the outlets. I can simply copy the style of the outlets to give the same colors to the delineated catchments and there is the result. Of course this also contains artifacts but you can correct those by removing the pits that you don't need or exporting only the polygons for your research. I hope this was useful. Please subscribe to my YouTube channel if you want to receive updates and looking forward to see you next time again.