this post was submitted on 25 Dec 2025
158 points (86.6% liked)
Programming
24072 readers
324 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I don't understand why they bother with the "modern" method if the fallback works so well and is much simpler and cheaper.
The modern method is more efficient if your network is reliable.
Modern: I-frame (screenshot) then a bunch of P-frames (send only what changed). If a frame gets lost, the following frames aren't really usable, frozen until next I-frame Old: Send only full screenshots. Each frame has all the data, so losing one doesn't matter.
I'm sorry, it seems to me that your first statement and supporting paragraph are taking the opposite position.
Oops. I meant the modern method is better if network is reliable. Not unreliable
Gotcha. That probably is true.
It's what the LLM suggested.
JPEG method tops out at 5-10fps.
Modern method is better if network can keep up.
Don't need high fps to watch an ai type.
Have you ever told an engineer not to build something overdesigned and fun to do?
From what I read, the modern solution has smooth 60 fps, compared to 2-10 FPS with the JPEG method. Granted, that probably also factors in low network speeds, but I'd imagine you may hit a framerate cap lower than 60 when just spamming JPEGs.
you don't need 60 fps to read text? All you need is to stream the text directly?
it seems like they sometimes need to stream the finished app coded, too
(still no need for 60 fps...)
When the unga bunga solution works better than the modern one
They didn't explicitly say but it sounds like the JPEG solution can't put out a substantial FPS. If you start to do fancier stuff like sending partial screenshots or deltas only then you get the same issues as H264 (you miss a keyframe and things start to degrade). Also if you try and put out 30 JPEGs per second you could start to get TCP queuing (i.e. can't see screenshot 31 until screenshot 30 is complete). UDP might have made this into a full replacement but as they said sometimes it's blocked.