When You Opened a Screen Shot of a Video in Paint, the Video Was Playing in It
Key topics
The article discusses how older graphics drivers used 'overlays' to render video, causing unexpected behavior when screenshots were taken, and the discussion revolves around people's nostalgic experiences and technical explanations of this phenomenon.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
25
60-66h
Avg / period
8
Based on 72 loaded comments
Key moments
- 01Story posted
Oct 16, 2025 at 3:57 PM EDT
3 months ago
Step 01 - 02First comment
Oct 16, 2025 at 6:12 PM EDT
2h after posting
Step 02 - 03Peak activity
25 comments in 60-66h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 20, 2025 at 2:00 PM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
While cameras were definitely common, they also weren't quiet as ubiquitous as they're today.
Lots of families only had them for trips etc, not readily available for kids to make photos of screens.
Not saying that cheating was impossible but uneasy unlike to now where there's a library for everything.
Cameras just weren't as ubiquitous as today. Unironically arguing that point is silly. They just weren't (I know you didn't, but we're in a comment chain that made that argument).
Yes, in most groups of people, there were a few of them that had cameras readily available, but it wasn't the norm for everyone.
What was available (not just cameras, but ocr etc pp) was a lot less accessable then it is today - where you just point your phone at it and it transparently extracts you the full text of whatever is on screen/lens, consequently the issue got a lot more problematic and widespread, which was the only thing what was put forward here.
I hate how incompetent tech writing and marketing rewrote and simplified mobile phone history into pre/post-iphone. Yes, we did have touchscreens, smartphones and camera-enabled devices many years before the iPhone. Arguably, on several metrics, many Symbian/Linux/blackberry phones of that era are better smartphones than today's iPhone/Androids as defined by hardware capabilities which got removed over time while arbitrary constraints got added on the software front.
Now I have a N86 which I'm going to keep until the last 2G goes offline.
The iPhone which made it was the 3G.
I was about 15 at the time, I'd had multiple digital cameras and had a phone with a crappy camera on it. All of my friends had digital cameras. Myspace had already peaked, Facebook was taking off, and that was largely driven by kids taking pictures.
The idea that the ability to take a photo wasn't ubiquitous for big parts of the western world in 2005 doesn't seem accurate.
At least by typing them the typer might learning something. :)
Darn, I thought this explained why, after upgrading my GPU, videos playing in Chrome have a thin green stripe on their right edge.
If video rendering used overlays, then YouTube could not put the toolbar or subtitles on top of the video, and they’ve been doing so for a long time.
https://issues.chromium.org/issues/40140067
>In today's Chrome, when a device supports hardware overlays, we promote at most one video's frames to hardware overlays.
MS started exposing some capabilities using MPO in the windows 8 era [0], and they've pretty much always had pretty comprehensive composition pipes in hardware for mobile platforms due to the power/bandwidth limitations meaning compositing the display can be a significant fraction of the total device's performance.
I suspect green (or other block colour) artifacts on video edges are due to bugs/mismatches in specification with the hardware video decoder and how the app displays it, and the bugs that often fall out of that.
Most video compression requires pretty large blocks, normally from 16x16 up 64x64 depending on format, and that may not align with the actual video size (e.g. 1080 does not divide by either). But often implementations still need that extra surface, as things like motion vectors may still refer to data in the "invisible" portion. And it has to be filled with something. It's then real easy to fall into bugs where small numeric errors in things like blending, or even just mix-ups between the different "sizes" that surface has, to cause issues at the edges.
I suspect the other comment about using ANGLE/dx9/dx11-on-12 may be effective as it /also/ causes the hardware video decoder not to be used, which is often a source of "unexpected" differences or limitations that commonly cause errors like that.
[0] https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
Your green stripe is likely because of the classic combination of unclamped bilinear filtering and a texture that's larger than the output region being used as the drawing surface for the video.
This issue can happen with overlays, but also non-overlay GPU drawing or CPU conversion routines.
https://old.reddit.com/r/OLED_Gaming/comments/1kovgdx/green_...
I'd make sure your drivers are up to date before fiddling with Chrome flags though.
...This is the oldest I've ever felt, unsure of my own memories regarding something I have to consult historical records about...
As OP noted, using hardware display planes can have efficiency advantages for cases like floating controls over a video or smoothly animating a plane over a static background, since it avoids an extra read+write for the composited image. However, it also has some quirks -- like hardware bandwidth limits on how small a display plane can be scaled.
If you have Netflix, look up "Cunk on Earth". Trust me, you won't regret it.
I have some vague memory of programs whose windows had funky shapes (i.e. not rectangular) also using overlays of some kind. Maybe that's a different sort of overlay?
They were rendered in some kind of overlay, that the rest of the GUI didn't know anything about.
Was this dependent on the OS? Or the driver?
the latency of the camera feed on the crt screen was unbelievable even (especially?) by modern standards!
after a minute of pure wonder i remembered about overlays. still mighty impressive.
Every so often you could get a glimpse of the man behind the curtain, by dragging the window quickly or the drivers stuttering, which would momentarily reveal the green color (or whatever color it was) before the video card resumed doing its thing. Switching between full screen and windowed mode probably also revealed the magic, or starting a game that attempted to grab the video hardware context. And of course sometimes other graphical content would have the exact right shade of color, and have video-displaying pixels.
You had to use the builtin screenshot function from your video player/tv viewer.
The current MPlayer under OpenBSD 7.7 still has the overlay video output
The desktop compositors takes the graphics content of all the windows, including their composition visuals, and combines them to form a full desktop image that is sent to the monitor.
...at the cost of latency and efficiency.
I was always stumped as to what the hell was happening.