I like the writeup and drawings, but I have to mention that this is a bit too specific to browsers as they work right now, specifically Chrome. Having to pay attention to the paint/compositor distinction and layer count is something that newer renderers like WebRender make obsolete. You don't have to worry about layer count causing needless overdraw if you have a unified system so that occluded content is culled, for example.
WebRender is already turned on by default for many users in Firefox Nightly…
Unfortunately for Firefox this concept doesn’t work very well on the CPU it seems. Every time I open Firefox on my (slightly older but still very capable) MBP the fans go nuts and the CPU could fry an egg. Probably has something to do with my integrated graphics chip.
And yeah I’m going to keep posting this anecdote until Mozilla acknowledges the problem.
I'm not trying to be an asshole, but it's hard to not feel like this is a reaction to Mozilla's amazing blog post series on how they created their new evolution of Firefox. The writeup is still great, but it feels second-to-market and chasing.
I’m on Mariko’s team. She said in a team email today that she took her inspiration from the “How Browsers Work” series [1] by Tali Garsiel and Paul Irish from 2011.
Well that was interesting, and I had no idea that "getCoalescedEvents()" existed. I've been a little disappointed when trying to write drawing applications before - circles end up looking like polygons unless you add some kind of interpolation.
So today we have mouse events, touch events and pointer events. And due to the demands of modern platforms we have things like these passive and cancellable flags. Is there any kind of best practice these days on how to handle user input? As far as I know, iOS doesn't support pointer events (I'm not even sure Chrome was keen on them until recently?) Do I just have to register handlers for all three? Does that affect performance?
And is there any way to get pen data into my browser (pressure, tilt, proximity, ...)? I remember this used to be possible with a plugin (eg the Wacom plugin), but I've been disappointed every time I've looked at pointer/touch event pressure values.
When attaching non-passive events at document level "the entire page is marked as a non-fast scrollable region." - this is the default thing that's happening in React, since events are attached on the document. We really need passive events in React
Oh I couldn't agreed more. Chrome's tab management, in my opinion, was quite bad last I checked. Having lots of tabs open means making them so small that they're losing their title and super hard to click on them. Granted, I haven't used Chrome recently, maybe it has improved. But I think Firefox was better at this and with a tree tab extension you can actually browse the web, have a lot of projects going on at the same time and utilize that RAM.
I haven't found a good enough tree style tab extension for Chrome/Chromium and that is the main reason I am not even considering it as an option.
WebRender is already turned on by default for many users in Firefox Nightly…