Bouncing DVD Logo
bouncingdvdlogo.com
bouncingdvdlogo.com
This was the original purpose of screensavers, which saved your screen from damage. Displaying a dynamic image prevented one part of the screen from being overused.
Means something very different now.
If the majority of the blue you see in the world is the sky and the sea, would you just start to think of blue as a blank? If you just consider blue as something more like we consider white, then any competing hues dominate what you describe. So just like white with the tiniest bit of red becomes pink, a purplish sea becomes red?
This basically calibrated the thing to look normal... with the magnet there. It took quite a while to restore to normal.
No? Huh, guess it was just me ;)
No idea how the previous owner managed to magnetize it, it never happened to me.
I remember playing MoH:AA, the play experience was quite out of this world.
On LCDs, I still can see faint flicker on some static backgrounds, and I think 60 Hz might play a role here too—though it seems to also depend on the brightness and Flux being on or off. E.g. on https://marctenbosch.com/news/
When I get rich and have lots of free time, I'll probably buy a bunch of old CRTs just to dig to the roots of this.
(temporal dithering usually is visible as slight noise on darker shades)
PAL and 50 Hz TV are not synonymous. Brazil has 60 Hz AC and uses PAL-M which is 60 Hz TV. AC=TV even in these odd cases.
Old CRTs couldn't possibly clock their flyback to anything but mains.
Cheap LEDs like some holiday minilights are rectified so they'll flicker at 60 Hz and I can't stand them.
15 years later it is still the case I use today, even though I am thinking about replacing it. Doesn't get much carrying today though.
¹ It was actually an interlaced field, not a frame, but that too much nitpicking.
There is also a navbar (back/home/recent buttons). In my case it's a white-ish rectangle that's almost always present on screen. By the time Samsung added an option to hide it, the damage was already done.
I have them both burnt in on my screen. I first noticed them after merely 1.5 years of using the phone.
OLED burn in is a 100% real thing.
I've still yet to see an LCD that performs as well as those CRTs, though.
It worked fine, felt like a huge waste of money. But it weighed over 100 pounds!
I had a small apartment so my desk/office area was a corner of the living room and I could run an HDMI cable over to use it as a secondary monitor for watching stuff on the computer. Even the fact that it would display 1080i was a huge jump from my previous bargain bin TV.
It was the days of Windows Media Center and it was before cable companies got rid of Clear QAM channels so I found that I could just take the shared cable in my 3-apartment house and hook up to a cheap Hauppauge card for tuner, guide, and DVR. Add a cheap USB IR receiver/remote and it was like having the "good" cable with the bells and whistles (but with a better interface and for free).
Eventually got an HDTV when prices came down and income went up, but a few years ago when a girl I knew was looking for a CRT to set up a retro gaming station for her young daughter, I donated all 111 lbs. of it gladly. That thing is probably still going.
We're both just as bad as each other, the meaning is discernible.
This was not necessarily wanted in OLD CRTs, where the startup sequence could take a while (and possibly other factors, such as reducing the lifespan, but I'm not sure about this).
Funnily, we are starting to see a bit of a comeback of these in OLED smartphone that have an always-on display to show time and a few things: the illuminated portion generally moves over time.
You can see some burn-in on old phones, in the notification areas, the taskbar for computers, or sometimes the always-on TV panels at airports or train stations.
They suffered terrible burn-in, and I was never sure why they were used. Eventually they ripped them out and replaced them with panels using the same technology (monochrome panels made of amber LEDs) that is used in the rest of the network for displaying information.
The thing about information is that you don't want it to spin or hop about, it needs to remain perfectly still while a potentially large number (tens of thousands of people use the station in an hour, if anything goes wrong all those people want information) stare at the information and so it can't avoid burn in. I can see that for the advertising screens, the opportunity for huge full colour screens is worth the risk of burning in an image, and worst case you could in theory even charge an advertiser who insists on holding a single image for the cost of repairing/ replacing your screens. But the information screens don't much benefit from colour, the pixel-addressable LED screen is only a small improvement over prior electro-mechanical devices which of course couldn't burn in, why allow burn-in just to get a colour screen? Maybe they were cheap?
Also, cue trainspotters and such putting 10-hour+ 1x-speed captures of the screens running through the entire cycle up on YouTube...
Even old TV shows look better than ever, as long as they were scanned from film. Look at the original Star Trek or Twilight Zone on Blu-Ray.
How are you watching a film on DVD if it hasn't been transferred to digital?
Update: It appears that the original motivation was public terminals/machines.
BTW, the "black" on a CRT is almost a true black. The electron beam is off when the signal voltage is less/equal to the black level, there's no "black light" if the black level is perfectly calibrated. Displaying a black image fullscreen is indistinguishable from an endless vertical/horizontal blanking interval from a practical standpoint. There's a measurable decrease in power consumption, although it's not much (it can be great enough on a large TV, though).
On the other hand, VESA blanking mode turns off additional circuitry, and it can save a lot of power while still keeping the CRT heater on, suspending the screen without the disadvantages of a long wakeup time or stressing the tube.
They were going to redesign the Apple operating system, and started with the screensaver.
It was a very cool screensaver, but I’m not sure how much progress they made beyond that.
Sorry.
(Someone should do a better version.)
A CRT screen basically works by firing electrons (or if you want that a bit more scaremongery: a beam of beta radiation) at the phosphor plate, the impact of which makes it emit light. Shades are achieved by varying the intensity of the electron beam and colour is formed by having three different colours of phosphor dot and three beams (and a grid to make sure the right dots were hit by the right electrons), but these details are irrelevant to the burn-in problem.
See https://en.wikipedia.org/wiki/Cathode-ray_tube for a longer and better explanation of how it works, and the history of the technology.
Under normal operation this is mostly all fine: the phosphor "recovers" once the beam stops hitting it for a while. The phosphor does degrade (essentially they burn) a little over time with use which is also fine if the wear is level, though it does mean the screen effectively fades a little with age. If you leave a particular image on screen for a long time then it becomes more of a problem because the lit areas degrade and the unlit ones don't. Essentially the phosphor plate develops permanent tan lines. It was not uncommon to see the shadow of login prompts or semi-permanent UI elements burned into screens this way.
It happens to other screen types too, though for slightly different reasons in each case. Plasma screens are particularly sensitive to the problem, but it can affect LCD displays too (some types worse than others). See https://en.wikipedia.org/wiki/Screen_burn-in for examples and a bit more detail.
The earliest screen-savers were just turned the screen black. This could lead to machine being powered off accidentally (potentially losing work if a user had walked off without saving) when someone thinks they are off and tries to turn them on, so instead a simple moving message was added, the message to indicate the machine is intentionally on and the movement to stop the message burning in. Other animations were added, with After Dark's iconic flying toasters appearing in ~89, and around the Windows 3.x era it exploded and almost became an art form (anyone else fondly remember the three-and-two-tenths flying toaster brigade, or Johnny Cast-Away?), some people competed to have the best screen-saver, or just the most "them" screensaver along with wallpaper/colour-scheme/other-desktop-customisations, and of course every corporate desktop carried the (bouncing) company branding when idle. Things died down when we became more energy conscious: going back to black screens because turning the whole apparatus off when idle saves energy.
The energy waste, battery degradation, and keeping the CPU/GPU awake longer are all huge wastes. Sadly, screensavers are nothing but wasteful nowadays.
I guess plasma is the main reason why on-screen channel logos went from solid to translucent?
https://nikital.github.io/screensaver
(But then it would troll you just before hitting it)
Used your code, but didnt have a license. Do I have your permission? Here is the link to the repo: https://github.com/pabloriveracelerity/mac-dvd-screensaver
Please let me know if you do not approve and I will take it down ASAP. No ill intentions. Just wanted to join the fun. :)
https://codesandbox.io/s/nostalgic-cherry-wwpzj?file=/src/in...
(I made the exact same thing last year as a joke for our team monitors)
On a technical note, not that there’s much you can do about this, but because you’re reading clientWidth and clientHeight each frame, you’re forcing reflow. A performant implementation would probably require avoiding the DOM altogether within the draw loop, so that would mean using canvas/webgl.
For science, I went ahead and converted the code to ES3 and ran on the 10-year old first generation iPad (with setInterval) and it's still pretty smooth.
EDIT: I added a simple rate-limiting function :)
No wonder modern frontend is such a mess.
I beleieve you are quite competent in this, so for me it's just another illustration of how HTML/DOM ecosystem is broken in so many ways that it takes enormous effort to perform such a trivial task. Thank you and plase stop wasting your time on this)
> Thank you and please stop wasting your time on this
Haha. Thanks. I like these mini-challenges, helps me relax for a few minutes :)
I think adding `will-change: transform` might help a bit, to hint the user agent that you'll be animating transforms...
This probably wasn't the case with DVD players (because the effort wouldn't have been worth it for a mass market consumer product) but 1980s Amiga home computers for example in some regard still outperformed mid-1990s PCs, which nominally were several orders of magnitude faster.
They were able to pull this off by clever hardware tricks and due to custom chips that were highly optimised for very specific use cases.
Run-of-the-mill PCs on the other hand were standardised and designed to perform good on average in most situations, not just very specific ones.
Or use canvas and this won't be a matter of DOM manipulation.
<marquee behavior="alternate" direction="up"><marquee behavior="alternate" direction="left"><span>DVD</span></marquee></marquee>
What an awesome explanation. Thank you for sharing!
Most web displays run at 60 Hz (16.66ms), making it inefficient to update every 5ms. 144Hz displays do exist and are wonderful, but you should always use requestAnimationFrame anyway.
Jesus it's 2020 at least use requestAnimationFrame!
setInterval isn't the problem. He's animating the CSS position (top, left), which triggers a full reflow and causes the stuttering. Always animate with translate3d, which is GPU accelerated.
setInterval is definitely the main issue here, especially with a 30ms delay, 33 or 16 would at least give it a chance to sync with refresh rates. Absolutely positioned elements do not trigger reflow, as the element is removed from the normal document flow [1]. See my example in another comment.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/position#ab...
[0] https://css-tricks.com/tale-of-animation-performance/
[1] https://www.paulirish.com/2012/why-moving-elements-with-tran...
Once you're hitting 60fps there is no difference in smoothness regardless of method.
But in reality, it looks better if you avoid subpixel values, as the image will flicker slightly; the frames not aligned with the pixel grid will suffer blur or distortion. Try setting speed to 0.1 in the example to see it wobble. The effect is noticeable even on hi-dpi screens.
Not saying you should animate anything using position these days, CSS transforms are certainly the right tool.
It’s just another property which can sometimes be used to do what you could earlier only do with ‘position:’, but there are still many cases (the majority) you position things using the “old” position property.
They have different uses, and for that reason one also requires a reflow while the other does not.
All I can say is use it, a lot. CSS skills are more of a dark art than anything resembling engineering. And the only way you get good is by trial and error, learning what works best and why.
https://www.html5rocks.com/en/tutorials/speed/high-performan...
The animations built into the platform can run and remain smooth under a broader range of conditions, which is why they should be preferred if you don't need the level of control that running script via requestAnimationFrame gives you.
https://bouncing-logo-css.glitch.me/
Just needed a tiny bit of JS to set the sizes and randomise the logo colour.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animati...
The issue is the css properties manipulated, as commented by another person.
Here's the link: https://codepen.io/ademilter/pen/oJqvNR
I'm pretty sure the screensaver was done in software. All DVD players have some sort of an embedded computer inside (even the earliest ones had to handle things like on-disc menus). It wouldn't make much sense to implement all that non-time-sensitive logic in an ASIC.
The first software was painful running under NT 4.0. With specialty discs with a large number of individual assets, it was easy to create so many files in a single folder that the system would slow to a crawl, and eventually crash during the muxing stage. You'd start it up again and watch it fly by the files it had already muxed, and then slow down when it got to the new files. It was a glorious day when Win2k comes out, and the same type of project no longer crashes like it did under NT. WinXP was like a gift from heaven. Then, you'd get some challenging programming requests like make a randomized game attempting to not repeat an item until all items have been displayed once. You get it programmed and begin testing in the plethora of consumer DVD players on the market. You then discover that some of the lower cost players don't acutally have the ability to select a random number. Instead, they have a preset list of random numbers starts over every time the player is restarted making it impossible to play the game as requested. You think browser compatibility is a pain, the DVD player/media combinations were insane.
Then there was MPEG-2 encoding. Early days required specialty hardware boards in your computer to do real-time encoding. These were in the $20k-$50k systems. High end encoders would allow for 2-pass encoding, but that meant playing the VTR for the first pass, rewinding the tape, and then doing the second pass in real-time. A 2 hour movie would take over 4 hours to encode. Then, if there was a problem with the encode (bitrate/buffer spikes/underflows), you'd have to figure out how to solve it and do the encode a second time. If you had the fancy encoder, you could do segment based encodes so you didn't need the full 4 hours. Mid-2000s, software encoding became viable. Now, you could run 2-pass encodes faster than real-time.
Then there were the oddities to deal with like timing was based on a 27MHz clock, so when the software told you there was a problem at time 59265000000, it actually meant 6mins 35secs.
No, I'm not scarred by the experience ;-)
Edit: I didn't actually answer the question. The role was to take the video/stills/subtitle assets and link them together. Every button on a menu screen had to be programmed to go to a specific spot on the disc. The video/audio/subtitles had to be combined to play together, then when finished told where to go, or stop, or loop, etc. Menu elements had to be placed in the correct section of the disc to that the menu/title buttons on the remote behaved correctly. DVDs had a very defined structure. VTS_01.vob VTS_02.vob makes me shudder when I seem them now.
I made one a little while ago https://imgur.com/7t9svTV
It would be much more efficient to turn it into a proper video.
Is it always angle of incidence = angle of reflection?