Microsoft veteran explains Windows quirk that made videos play in Paint Microsoft veteran Raymond Chen has answered a lingering Windows question – why did video screenshots keep playing in Paint? In a post on Microsoft's Old New Thing blog, Chen explained that it's all about green screen technology and making the best of the limited resources available to the OS at the time. Windows used a …
Phone might be listening to conversations, transcribing them and then shipping to advertisers for targeting.
I also found many such coincidences.
That said I often say: "Oh man, I'd love to buy a lawnmover (or some other thing that I don't typically would use). I wonder which company has discounts right now." etc. I am yet to see an ad pop up with such a thing. Maybe they treat it as an outlier and remove from targeting.
It was likely used for that purpose because Windows Media Player would color-key to a super dark, nearly black magenta. This was on pre-Vista PCs. I discovered this trick on an early 2000s laptop when playing around with screenshotting a DVD and pasting it into Paint.
Anyone could spin up an overlay using DirectDraw. You'd create an overlay surface, define the color key, and send data/flip it using the correct YUV format. In my own experiments I had used the packed UYVY format.
Windows Vista removed support for these video overlays due to conflicting with the Direct3D based Desktop Window Manager. DRM video today uses a newer overlay format that is seamlessly composited by DWM but when you take a screenshot the video gets blacked out, but any playback controls that were overlaid still rendered in the screenshot. Also, since Windows 7 with a simple API you can declare any top-level window to be DRMed with a single API call, and will be blacked out from any screenshots, or even hidden entirely.
Early MPEG cards did the same. Is this really "surprising" to anyone?
The early RealMagic MPEG decoder accelerators, and even WinTV cards, and some early GPUs worked in this exact way.
Show a particular colour. Have the video-out signal loop through the accelerator card... that card replaces any purple/green/whatever pixels in the image with the video stream it's trying to render.
0% CPU usage, the accelerator card does all the work, no complicated software or trying to pass more info down the very-limited ISA/PCI/VLB bus speeds of the time. With the advanced ones, they even detected the size of the overlay area to replace with video, and resized the video to fit (so I could resize my TV window to be in a tiny box in the corner of the screen while I got on with other things). The "TV app" was basically just an always-on-top purple window. You could just use Paint to do the same, or even a large box inside Write/Wordpad/whatever.
I've seen cards with literal VGA In/VGA Out that work that way, ones that used PCI bus mastering and DMA to do it, etc.
Pick up any old RealMagic or Hauppauge WinTV card and they work this way. I think early Voodoo's worked this way too.
Pre-dated by a tape copy program on TRS-80 model 1's which used the video RAM to load and execute the copy programme leaving the entire 16K RAM available for the copied data (in particular Scott Adams Adventures, which were always 16KB in size even if they had to be padded out to fit because it made it impossible to copy if the copy programme had nowhere to run. Original TRS-80's had 7-bit video RAM, so you needed the "lower case mod" for this to work. TRS-80's typically only had one tape deck too unless you had bought the expansion interface, so tape to tape in digital from was out. The lower case mod, which added the 8th bit to video RAM was, for most people, the cheapest and often first upgrade they did. An expansion interface and/or extra RAM was very expensive back then. There was always the option to copy tape to tape via simple audio connections, but tape loading from audio was always more of an art than a science back then, so loading the game and saving it back out was the preferred option.
The stock VIC-20 shipped with 5K (5120 bytes) of on-board RAM - not counting the half-byte colour RAM which was located in a non-contiguous memory block.
That 5K was split between Zero-Page, Stack, OS variables, your BASIC code, and the screen:
5120 - 512 (screen) - 256 (ZP) - 256 (Stack) - 512 (OS vars) - 1 = 3583, which is what the POST message reported as available for use by BASIC.
You could access screen RAM from location 7680 to 8185 just like any other part of the RAM (including the 6 'lost' bytes from 8186-8191, which arise as a consequence of the 22x23 screen matrix occupying 506 bytes of the two 256-byte pages allocated to it). With no bitmapped graphics mode, anything accessing the screen did so via this memory-mapped mode - and that also meant you could use some or all of it for storage provided nothing else wrote to it.
Using it for BASIC programs was impractical, as the screen editor directly accessed that memory and would therefore trash your code - but you could definitely use it as temporary storage for ML code during things like decrunch operations to unpack level data, for example.
The color used for colorkeying in windows was normally a vivid fuchsia (Full red and blue, 0 green).
Colorkey and chromakey are slightly different with Color-keying the hardware only has to match a specific color value and swap the pixels with the video overlay data. Chroma keying has a chroma value (specified as CrCb or UV, and matches over a range of Luma values, which is what is used on greenscreen technologiies. This is to account for the fact that you cannot guarantee the light levels of the greenscreen as it is lighting dependant.
Linux would do this too but the overlay color was a specific shade of blue instead. If you had the sub-pixel font rendering going you'd sometimes get individual pixels in text have video bleed through too (... if your text window was covering the video playback area.) If you force playback using xv or xvideo it may STILL do this.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
