131–140 of 161 posts
I think Chrome's biggest problem is being a memory hog, but having a slow renderer!
The Chromium development team intentionally optimizes for speed (at the expense of higher memory usage) more than the Firefox team does - and, if you want, you know, long battery life, this seems ideal.
Rendering fast is nice, but when are they going to make the rendering look good? Image scaling at non-integer scales in Chrome is atrocious -- either coming out a blurry or aliased mess. I almost always need to zoom in 20% to 50% because web designers love tiny fonts too much, and setting a minimum font size breaks their fancy layouts. This results in Chrome making a mess of all images on the page. Thankfully Firefox…
So, for example, if you disable cleartype on Windows, you will have crisp aliased fonts at default font sizes on Firefox, but you will still get blurry antialiased fonts in Chrome no matter what.
Earlier quoted context omitted.
On ChromeOS and Windows, you can use a desynchronized 2D or WebGL canvas to avoid the additional latency at the cost of tearing artifacts and no ability to synchronize updates with the surrounding DOM. https://developers.google.com/web/updates/2019/05/desynchron... We added this for low latency drawing in Keep and Chrome Canvas and the ChromeOS PDF annotation mode.
This sent me down a rabbit hole to see if desynchronized canvas might improve rendering three.js scenes. TLDR: No https://github.com/mrdoob/three.js/issues/16684
It has complex and non-obvious effects. greggman on the three.js issue wrote a really nice summary on why it shouldn't be the default.
It's really only appropriate for highly latency sensitive applications, like drawing or certain games.
Earlier quoted context omitted.
What the browser giveth, the web developer taketh away. I tremendously hate it and it’s not like developers are incapable of building performant software, quite the opposite. But that’s just not where the resources go. The common sentiment (I have heard this directly uttered) is “If the user has 8GB of RAM, why wouldn’t I use it?”.
I really don’t think this is such a bad thing. It makes it much easier to develop software and has helped result in the explosion of awesome digital products that we see today. I do have my fingers crossed that Rust+WASM+WGPU will bring about some more efficient products, though. But I don’t think non-technical users value memory efficiency as much as we like to think sometimes.
> It makes it much easier to develop software
I've never seen compelling evidence that this is the case. Every time this argument is made, it seems to be by a webdev who has no significant experience with building desktop applications. Sure, if you already know webdev, it's easy to build things with webtech. This isn't particularly interesting. I'm much more productive building desktop applications than webapps, but that's because I've spent almost all of my time building desktop applications.
The real question is, given an average developer who has spent around the same amount of time on learning web development and desktop development, and both at a minimum amount of time (say, 100 hours) - which is more productive, and by how much?
Earlier quoted context omitted.
Yes, it seems like smooth scrolling is prioritized over low latency. On Windows I even get 3 frames (48ms) of lag (presumably because of DWM).
I use a wired mouse with a 1000hz polling rate on an M1 Macbook Pro with vsync disabled system wide (through Additional Tools for Xcode 13.dmg[0] => Quartz Debug.app => Enable Vertical Sync; it only actually disables vsync if you use an external monitor and close the lid of the MacBook). Like switching to the Classic Theme from Aero in Windows 7[1], as far as I can tell, this removes at minimum 1-2 frames of input la…
Are you using a >120Hz Monitor or don't you care about the occasional tearing?
Earlier quoted context omitted.
Does your experience as a consumer not suggest that the amount of developers employed is, if at all, inversely correlated with software quality?
no, it suggests that just as the amount of developers past a certain point on a project is a drag on that project the amount of developers of a product past a certain point does not significantly increase the quality of that product. If indeed the amount of developers employed was inversely correlated with software quality then the best software is that which does not exist. I realize there is a pithy saying that the…
Earlier quoted context omitted.
> For example with Wasm and WebGPU it's possible to create AAA games running in the browser. This has been promised since at least the WebGL and asm.js days. It still won't happen, but not mainly for technical reasons, but for business reasons. ...but of course also some technical reasons. Asm.js/WASM and WebGL/WebGPU are fine, but most other web APIs are a mess and the web is a highly unstable platform, APIs are dea…
I've always wondered why nobody built Kongregate 2.0 using modern web technologies. The indie game dev scene seems to be thriving, and you can play tons of games for free on itch.io While some of them have a webplayer, it's disorganized, and the user experience is usually terrible.
That didn't help the large move to mobile gaming by its primary audience (which I'm guessing was teens).
Towards the end Kongregate became a platform for idle games that pushed users hard towards pay to win. Sucks, but they grew huge off the glory days of ad revenue and I presume they had to do something to keep surviving.
Earlier quoted context omitted.
I use a wired mouse with a 1000hz polling rate on an M1 Macbook Pro with vsync disabled system wide (through Additional Tools for Xcode 13.dmg[0] => Quartz Debug.app => Enable Vertical Sync; it only actually disables vsync if you use an external monitor and close the lid of the MacBook). Like switching to the Classic Theme from Aero in Windows 7[1], as far as I can tell, this removes at minimum 1-2 frames of input la…
> I use a wired mouse with a 1000hz polling rate on an M1 Macbook Pro with vsync disabled system wide; it only actually disables vsync if you use an external monitor and close the lid of the MacBook Are you using a >120Hz Monitor or don't you care about the occasional tearing?
I don't mind the occasional tearing — I usually only notice it when using autoscroll in Firefox at a lower speed/velocity.
As a remote SWE, I sit in front of my computer all day every day, so I find that the benefit in speed I get from removing at least one frame of input lag outweighs the occasional tearing which occurs as a result. I'm not exactly sure why, but I haven't noticed any tearing when playing video content.
I also spend a lot of time in XQuartz, which has some longstanding rendering bugs unless you disable vsync.
Earlier quoted context omitted.
Yes, it seems like smooth scrolling is prioritized over low latency. On Windows I even get 3 frames (48ms) of lag (presumably because of DWM).
I use a wired mouse with a 1000hz polling rate on an M1 Macbook Pro with vsync disabled system wide (through Additional Tools for Xcode 13.dmg[0] => Quartz Debug.app => Enable Vertical Sync; it only actually disables vsync if you use an external monitor and close the lid of the MacBook). Like switching to the Classic Theme from Aero in Windows 7[1], as far as I can tell, this removes at minimum 1-2 frames of input la…
user_pref("accessibility.force_disabled", 1)
user_pref("general.smoothScroll", false)
user_pref("general.autoScroll", true)
---
# --disable-frame-rate-limit is buggy on macOS
open -a Google\ Chrome --args --disable-gpu-vsync --disable-smooth-scrolling
open -a Slack --args --disable-frame-rate-limit --disable-gpu-vsync --disable-smooth-scrolling
open -a Spotify --args --disable-frame-rate-limit --disable-gpu-vsync --disable-smooth-scrolling
I think Chrome's biggest problem is being a memory hog, but having a slow renderer!
Chromium seems consistently faster than Firefox to me, and I'm pretty sure that many other people have noticed this, too. The Chromium development team intentionally optimizes for speed (at the expense of higher memory usage) more than the Firefox team does - and, if you want, you know, long battery life, this seems ideal.