HN user
Nothing? I actually measured it incorrectly in the comment you replied. With nothing happening on the page Chrome's task manager reports ~0.1 CPU usage for the tab. Almost all of the overhead on this page is from the header and footer animations [1] and not the widgets. Browsers limit things like `requestAnimationFrame` in inactive tabs anyway so even if it was bad it wouldn't be devastating.
Wow, that's quite silly - and might partially explain some of the worsening battery life on Android.
It's likely the same on iOS. You'd have to try implementing it to really see why it isn't practical.
Consider you were implementing drawing a button. Your UI framework calls your draw method with some interface to draw with and gives you a rectangle specifying the region to draw. Your button is probably some form of rounded rectangle which will be complicated to draw a subsection of if the rectangle intersects a corner. If it intersects the button's text then you probably need to figure out which characters intersect the text and only render those. It's a non-trivial amount of work to cull the draw commands to an arbitrary region. Also, if you stop passing dirty regions around then the widget drawing method is closer to being a pure function meaning the UI framework can cache the draw instructions instead of calling it over and over for different regions.
Chrome on desktop has an option for flashing whenever it paints and it only highlights the line of text you're typing on. So clearly chrome still tracks dirty rects properly.
Looks like it but it doesn't show any renders for the cursor flashing so I don't fully trust it.
Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused.
You're right that they avoid unnecessary painting but it is not this granular anymore. It used to be but rendering is so much faster these days where it is cheaper to just render a bit more than tracking dirty regions. It's easily visible on Android where you can enable "Show view updates" and see the entire textbox view updates when the cursor flashes. The docs say the same thing.
https://developer.android.com/reference/android/view/View#in...
Zoom in, take a look at what code is running, and you'll see it's all `lottie_light.min.js`. Being offscreen doesn't mean it's doing nothing. In fact, it looks like once it shows once it keeps spinning its RAF loop forever. Shrink your window so it disappears, reload, and then profile.
That's from Lottie, the animations that play in the header and footer of the page. Shrink your window until they disappear and try again.
Sorry, I meant to say that it was what I was suggesting. Video games render a lot more than the widgets on that website. Rendering less takes less time, so your `requestAnimationFrame` loop idles longer between executions waiting for vsync, which means your CPU or GPU usage is not pinned.
A website shouldn't be pinning CPU or GPU.
That's exactly what I was saying. Rendering a few widgets shouldn't pin your CPU or GPU because it's so little work.
This page, however, has an animated SVG and moving DOM elements in the header which consume far more resources than the widgets it is trying to showcase. Compare usage before and after deleting the header element (`section.hero`) in the inspector to see for yourself.
Yes, visual effects and animations in UIs burn cycles just to make it look nicer. Doesn't matter if it's a website or the native system UI.
To be clear, I'm not saying it's fine to constantly render when you know nothing changed. I'm saying the load from this should be very small. Most of the performance issues from this page are actually from the header animation, which you can delete in the inspector to see a significant drop in usage (mine went from ~35 to ~6.6 CPU).
My point was more that rendering a few widgets at 60+ FPS is nothing for anything with a GPU, and everything has a GPU these days.
Anyway, something like this only needs to paint when states change or animations are running. That's an easy optimization to make here if it doesn't do it already. And games don't even bother with it, they repaint all UI even if it doesn't change.
This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'.
It's not crazy. That is literally what 99.99% of video games do. They repaint everything constantly, only limited by either your vsync rate or hardware.
And on the higher end you can get an ESP32 CYD (Cheap Yellow Display) which has a 2.8" or larger touch screen, SD card slot, LiPo battery connection and charger, speaker port, and maybe more for ~$15. Can make fancy UIs for it with LVGL or install something like MicroPythonOS on it if you have PSRAM.
$5 compute
Unrelated but the author at Tom's Hardware is apparently unaware of AliExpress so they bumped the price from $2 (or less) to $5. And that's the price for just one. These things are so cheap you can throw them in everything. They're the perfect alternative to a Raspberry Pi because they have WiFi, Bluetooth, lots of GPIO, and decent compute. Not enough to run Linux but you don't need Linux for IoT.
i wonder why they haven't done the same on Windows
Probably because a lot of people feel like they need exclusive fullscreen for best performance and/or latency. But in reality borderless fullscreen is exactly the same when games use the DXGI flip model. It bypasses DWM (the compositor) to render directly to the display when only the game is visible and seamlessly allows you to switch to other windows. You can even disable Vsync and it will allow screen tearing when bypassing DWM.
Personally I trust Apple more than I trust TP Link with this stuff.
What if a TP-Link camera supported HomeKit Secure Video? You access the camera through Apple but all of these cameras are still directly connected to the internet, meaning you still need to trust the camera manufacturer.
I’m able to watch a camera that has no internet access because it passed through my Apple TV, which serves as a home hub.
How exactly does this prevent the same kind of issue for Apple devices? Aren't you just trusting that Apple handles your data better than TP-Link? Not saying they don't but routing through another device doesn't really add security on its own.
But why? The Steam Deck and Machine are pick up and go like consoles by default. Only a small minority care that it's actually a PC you can use for things other than games.
The only thing that sets them apart is Steam's hardware isn't locked down.
You'll likely see a lot more Steam Machine-like PCs because of this. SteamOS fixes most of the problems you mention. Price is the new normal and you should expect next gen consoles to come closer to it. It's not a bad deal anyway when you consider the bigger library, cheaper games, and no subscription required.
A web app is limited. Even if it loads fast, it feels clunky.
But what about it feels clunky?
HTML and CSS are a lot faster than you want to believe. You can't tell me you've never used a website that isn't slow. Problem is the people making most websites don't care to optimize or profile anything.
Also why would you store UTF-32 in text column when SQLite clearly doesn't support it? The docs show there are only methods to pass UTF-8 or UTF-16 text.
Change RDBMS instead of changing configs from their default value? They're configurable for a reason.
You also get so many weird glitches with state refreshing, sessions being cleared, log in not persisting.
And these don't happen in native apps? Because they somehow have less bugs?
Apps feel SO much better with the native UI, pre-downloaded
React Native apps are pre-downloaded and have a native UI. Lots of them feel really bad. Not all, though.
You can make fast websites/PWAs just like you can make slow apps.
Or, you know, it's small because it's just a WebView wrapping a website.
It's against the App Store rules but if you build an app with React Native/Expo you can OTA update it to do something completely different without going through another review. Enforcement is minimal, especially since you can selectively roll out updates to make it unlikely that a reviewer gets it.
It's such a weird thing to be concerned about though. Your phone automatically updates apps by default so they can suddenly look different later. And even then, so what? If the change was malicious just stop using it? Apps are sandboxed, websites are sandboxed, you'll be fine.
You'll still find people praising Apple (maybe even Google) for their review process even though their store is full of garbage. Really justifies their 30% cut.
I assume that means it is rendering an entirely new image each frame... which is a tad wild.
What's wild about that? That's exactly what it's doing and what most uses of canvas/WebGL do.
You need to click the "fps" text for it to actually show the FPS value (it'll be green). The 400 you saw was something else.
The same complaints can be made by the second developer because the first developer chose the "wrong" framework.
Exactly this. There's so much fragmentation within the browser ecosystem that there is no guarantee your second developer will be comfortable/familiar with what the first developer chose. Even if you went with React you could be using state management they don't understand, a styling system they don't understand, etc... Even if you choose the most popular everything at the start of the project there is a lot of churn where things eventually fall out of favour.
I'd also be skeptical of web developers who work with React but aren't familiar with vanilla JavaScript. It's probably a good indicator that they aren't the best candidate but we can't all be picky.
It's for backwards compatibility, as always. You also need to enable foreign keys or they aren't enforced. You also need to tune for performance (enable WAL, adjust cache size, etc.).
The SQLite documentation is very up front about these things [1] and more. It should only be an issue if you're the type of person who never reads any documentation.
I never took SQLite seriously for the very reason that field types were not enforced by default.
I can understand not taking it seriously if it was completely unsupported but I'm pretty sure most databases don't have perfect default configs. Even PostgreSQL needs configuration for optimal performance because the defaults are for low (minimum) spec systems.
then eventually adding nearly all the reliability facilities of TCP to the app (automatic retry, etc) by hand.
Depending on what you're doing you're still probably doing better than TCP after all that work. TCP is a stream based protocol which is not ideal for many applications due to head of line blocking. If you built your own reliability layer over UDP you likely avoid that issue entirely.
I think the main goal is direct to phones rather than being an alternative to fiber. But it's also a very good option for people living in rural areas with poor service (shoddy DSL).