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.
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.
Do you have scaled resolution enabled? If so, that sounds like this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1404042
I think there's been a little bit of progress on that issue, but not much, unfortunately.
Sounds like Core Animation could fix that issue? I have a patch for that almost ready to go (mstange is testing it as we speak).
> WebRender is already turned on by default for many users in Firefox Nightly…
Are you using Nightly?
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.
~ A Chrome User
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.
[1] https://www.html5rocks.com/en/tutorials/internals/howbrowser...
Why do I care if it's first, second, or 100th? It has the same value to me. Thank you Mariko!
I'd be interested in reading Mozilla's blog post series you referenced. Is this an example?
https://news.ycombinator.com/item?id=16169236
Code Cartoons: https://hacks.mozilla.org/category/code-cartoons/
But it looks like they have been posting updates since 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
Can it be called a modern browser if it doesn't display tabs on the side?
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.
How are those awesome illustrations created. Which tool????
Looks a bit like balsamiq. But there's also this tool called "on-staff graphic designer/illustrator" that they could have used as well.
Mariko made all of those illustrations herself. Check out her “alternative introduction to promises” [1] on her personal blog.
[1] https://kosamari.com/notes/the-promise-of-a-burger-party
Self-production also always an option.
Is google falling behind in technology?
Recently I have been trying out gcp instead of aws, the difference in quality and documentation is staggering.
Here we can see a clear reaction to Firefox, a second to market posting.
They are continuously closing down products.
What is behind this?