171–180 of 276 posts
From my first try, I immediately had the performance monitor visible because I knew this could be RAM intensive.
I iterated a few times until I settled on SKIA and boy, the performance was night and day.
Is it possible to restrict this as a user? Like to force webpages to use under a certain amount of render/paint time/resources or else just break so that one dumb tab doesn't use up all my battery? Then I can opt-in to greater resources usage if it's a webpage I actually care about. I've seen the "This webpage is using alot of resources" popup before but I don't think it would happen in this case. Because honestly I…
> In 99% of cases I do not care at all about the "artistic vision" of the UI designer and in the other 1% of cases (say an in-browser game or some useful data-viz) I could choose to allow the tab to go crazy with my resources. I'm with you 100%. Although I'd go one step further and say CSS just isn't needed at all, and should be removed from all browsers. Same goes for WebGL (if you want to play a game, download Stea…
Is it possible to restrict this as a user? Like to force webpages to use under a certain amount of render/paint time/resources or else just break so that one dumb tab doesn't use up all my battery? Then I can opt-in to greater resources usage if it's a webpage I actually care about. I've seen the "This webpage is using alot of resources" popup before but I don't think it would happen in this case. Because honestly I…
Seriously. It seems pretty reasonable to allow a web page a total amount of processing that is something like 100% CPU or GPU for 5 seconds. (E.g. can be 25% for 20 seconds.) And beyond that it gets throttled to 3% CPU cumulative max for however long it's been open so far. And make that the default for popular browsers, so sites are forced to be efficient or else be super super janky and stuttering. And allow a permi…
[1]: https://searchfox.org/mozilla-central/source/browser/modules...
Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster. By the way, the same trick was speeding up large rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of .
Is there a good way to learn techniques like this from first principles other than trying to become an employed frontend dev?
So the you need to fix that height /remove resize, then google on which technique to use?
Earlier quoted context omitted.
The problem is that everyone (browsers + developers) need to agree on a replacement, which is notoriously hard to do. Chrome got laughed out of the room with Dart/Flutter.
Well they don't really. What ought to happen is someone just makes a new browser (or adds support in an existing browser) unilaterally on an experimental basis. If it's good enough I imagine it would catch on. The limiting factor is presumably that that's a lot of investment for an experiment, but getting anyone else on board without a successful experiment is going to be impossible. (well, also, you have to have a g…
What would that actually mean in practice that would be different from how Dartium did it?
Earlier quoted context omitted.
I was just starting a comment on this but you beat me to it! I believe contain: strict; on the parent element would have been sufficient here.
I tested `contain: strict` on their color changing SVG and didn't see any difference. Profiler says it's still doing layout.
Earlier quoted context omitted.
They should put in something that allows users to electroshock web designers for wasting their battery.
I don't think combined energy output of every power station on Earth would be enough after we have Electron apps for so long. (edit: typo)
Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster. By the way, the same trick was speeding up large rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of .
As an old-school webguy, fixes like this article make me sad. The average front-end person these days has so little respect for the DOM and then gets mystified about why the McMaster-Carr website is so good despite being build with ancient practices.
Just wrap it in a container with fixed height and "overflow: hidden". Now the layout engine knows that it doesn't need to recalculate positions of elements outside that wrapper, and it's much faster. By the way, the same trick was speeding up large rendering back in the day. As long as you know the size of your rows or columns ahead of time, which kinda defeats the purpose of .
`contain: strict` is much better than `overflow: hidden` for this case, and implies `overflow: hidden`.
Yes, looks like this property isn't just a hack, but was designed with exactly the performance considerations laid out in the article in mind. Animating height is only expensive when the element’s height affects layout, which it doesn't have to!