Right when you think now I know how deep the knowledge pockets of HN go you get surprised by a comment like this. Never imagined someone giving a talk about such an obscure digital event.
What an awesome explanation. Thank you for sharing!
It's not just about speed, it's about timing. With setInterval the alignment of the screen refresh and the code to update will quickly become out of sync and cause periods where 2 frames are the same.
Your browser, as a regular desktop application, is almost certainly double buffered. You will never see tearing, but things can look temporally uneven.
>I was wondering why the animation was so stuttery and then I saw they are using setInterval for the animation...
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.
Ooh you could even animate with a css transition from one bounce to the next with a linear curve; then you don't run any JS per frame, only at the bounces.
The problem I think is that transitions have fixed amount of time, both long and short travels finish with the same amount of time giving a different velocity of movement. Also executing Javascript every frame is not that heavy
Executing JavaScript every frame is not that heavy, but if the main thread is blocked because of something that is, which may even be in another tab, the animation will stutter.
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.
As someone who's new to front end and css is there a good resource on what properties are more costly, or which functions are newer and meant to be more performant like translate3d is mentioned as being gpu accelerated? I've seen mentions of reflow, repaint, and layout thrashing but not a comprehensive list of what functions are meant to replace what other ones, or relative cost of each function in common use cases. I've managed to grasp javascript fairly easily coming from python, but css seems like this obscure black box that I thought would be much easier to get a handle on.
I have no great answer to your question, and you might know this already, but while translate3d is indeed newer, it’s not a “new more performant” replacement for positioning with top/left using the position property.
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.
>I've managed to grasp javascript fairly easily coming from python, but css seems like this obscure black box that I thought would be much easier to get a handle on.
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.
The key to animation on the web is to at all costs avoid using JavaScript to manipulate a DOM object on a tight timer. To achieve a smooth animation, you need between 24fps and 120fps depending on the device, so between 43 and 8 milliseconds to get everything done. Doing DOM stuff that fast is going to be a headache compared to using CSS animation or even using the Canvas API.
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.
Regardless of whether there is a reflow, translate() allows you to do subpixel animation [0]. It will always be smoother than animating CSS position [1].
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.
Exactly. This is what CSS Animations [1] were made for.
And you don't even need to do collision detection, as CSS can already alternate directions and loop infinitely.
Nice demo. I was curious how you were going to avoid collision -- my assumption was since the pattern wasn't a "single cycle" loop (whose total length presumably depends on the LCM of the width and height) that the animation setting would either need to be very complicated or changed periodically, but you cleverly sidestepped the whole problem by applying X and Y translations to different wrappers so they can each have their own fixed period: smart!
setTimeout would probably be fine if they used the diff in elapsed time between calls to derive the position deltas rather than assuming it is always going to be 30ms.
If you make it just large enough so the logo has a few pixels left and right to bounce, it starts vibrating and changing colors really fast. Looks like it's really angry from being confined :D
In 1999, my DVD player could do this smoothly without any hitches or glitches. In 2020, my Xeon can't render this fast enough to avoid stutters. Either code quality has gone way down or my DVD player had a faster CPU.
I have a 60fps + 144fps monitor setup and when I move it to my high refresh rate one, it goes hyperspeed :) You should calculate delta time with performance.now() and change position based off of that.
Only tested on an iPhone, works fine at 60fps. You can open the standalone page at https://wwpzj.csb.app/ to avoid the whole codesandbox app running at the same time.
I am grateful for your effort and have no intention to troll or diminish you - in case it looks like that. But still: now in desktop Chrome logo bounces from the very bottom or right edges of window, which is great, but there are gaps at the left and top edges, so logo never reaches those two edges.
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)
There are probably a dozen edge cases (!) that are not covered, though I bet most of them would be the same if using SDL or any other graphics engine. This was mostly a sample of canonical requestAnimationFrame use, in contrast to the original, and not an attempt to re-create the whole thing.
> Thank you and please stop wasting your time on this
Haha. Thanks. I like these mini-challenges, helps me relax for a few minutes :)
This is definitely not smooth on iOS, on a brand new iPhone that’s arguably way faster than whatever system played the original DVD screensaver.
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.
There are no elements in the page for style to be recalculated, so I doubt the reflow is what's slowing it down. I'm curious on what could cause bad performance for you though. It runs smoothly at 60fps on an iPhone 11 and the iPad, using Safari. Did you open the standalone page at https://wwpzj.csb.app/? My only guess would be that the CodeSandbox UI is too heavy for mobile.
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.
With these dedicated devices the engineers often were able to cut corners or use custom hardware.
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.
Same here, it's not smooth on Firefox on my laptop. Some of the alternative implementations mentioned in this thread are somewhat better but I don't think any are consistently hitting 60FPS.
Because it was not coded with performance in mind. It updates the position left and top properties forcing the browser to re-render on each frame. What it should be doing is use CSS transforms so that only the GPU would be doing the updates.
Or use canvas and this won't be a matter of DOM manipulation.
I'm a bit surprised and saddened by how literally this comment is being taken by replies. I think it's an apt comment, so I'll explain how I see it. My takeaway of the point is that we now live in an age of excessive abstractions. This is just a fun toy, so I don't want to be too critical of this case. But in other applications, excessive abstractions allow us to ship things that don't work, but look like they do. This fills the internet and our phones with garbage.
Why do people bother minifying code this small? It's 168 bytes gzipped. The unminified source is probably under 1kb gzipped. Just no point to minifying.
a long time ago I went into my living room and saw my parents very quiet sitting down looking at the dvd logo bounce. So I asked, what are you doing, and they said, oh we've been here waiting for the logo to hit the corner...:D
Try https://gif.com.ai
to turn it into a gif. You can set timing with a bouncing </marquee> tag to make it move from end to end. I’m not aware of any tools to turn gifs into screensavers however. I’m pretty sure they exist though.
That's got to be one of the least efficient suggestion I've read in a long time. GIFs are horrible, except they are awesome. In a 90s sense of awesome.
It would be much more efficient to turn it into a proper video.
Oh my, what is wrong with people?? Or maybe it's just me. I have a PTSD like reaction instead. I was a DVD programmer for 10 years, and every where I looked would be a screen with a DVD player connected doing this. I'm so glad to not be in the shiny round disc business any more.
Depends on what year you started really. The original DVD burner cost $15k and the blank discs were $50 each but only held 3.95GB of data. The 2nd gen burner dropped to $5k and <$10 discs. The 3rd gen burners came out with the General media. These burners were less than $200 and blank media holding the full 4.95GB of data dropped to less than <$1. General media came with the +R/-R battles, and neither of these formats were compatible with a large portion of existing DVD players.
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.
It actually uses a time-based interval and tries to move every 5ms. At this resolution, different browsers will handle it differently.
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.
As a historical note, the bouncing logo wasn't just for fun, but was important to prevent screen burn-in on CRTs. If you had a static image on a CRT for a long time, it could damage the phosphor. Sometimes you could even see the image when the screen was off!
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.
As to why they are not necessary anymore: we just turn the screen off (some displays, especially OLED, are still prone to burn-in).
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.
Waterloo Station (in London, named after the bridge, which is in turn named after the battle, which was in Belgium) for a while had these full colour panels which I guess may have been plasma? These were used to display train information.
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?
That you feel the need to inform us of this "historical fact" makes me feel especially old... having lived through the CRT -> LCD transition period when buying an LCD made going to LAN parties a lot easier
It didn't even occur to me that this would need to be explained. Up next we should talk about why it was bad to leave VCRs paused for long periods of time.
I remember being told as a child that it "wears out the tape," but I'm going to guess it's specifically because the same section of tape stays wrapped around the capstan (the metal cylinder it loops around to be read) when it would normally be passing through. Keeping the same section of tape under tension for a prolonged period presumably weakens or risks distorting it.
It was worse than that. The head drum continued to spin throughout the entire duration of the pause, rubbing against the film at high speed. That's because the VCR didn't have any "memory" to hold the entire frame¹, so the lines of the frame had to be read from the tape over and over again.
¹ It was actually an interlaced field, not a frame, but that too much nitpicking.
It isn’t about tension. In order to display a paused image, the head must continuously rotate and scan that section of the tape. You can literally overheat and wear the tape out in that spot because there is a spinning piece of metal against it. Only specialized VCRs such as high end professional/broadcast or security recorders have something like a framebuffer.
I think my favorite contextual example of this is the opening line from Neuromancer: "The sky above the port was the colour of television, tuned to a dead channel."
I wonder if 2000n years from now, scholars will be wondering over the meaning of that sentence, the same way that they currently discuss the meaning of "wine-dark sea" in the Iliad and the Odyssey (https://en.wikipedia.org/wiki/Wine-dark_sea_(Homer))
That section on ancient languages tending to lack blue is very interesting. I wonder if there was just a lack of blue in their environment. If the local birds and flowers don't contain any blue, then you just have the sky and the sea(or whatever large body of water.)
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?
Homer’s wine-dark sea leads down an interesting rabbit-hole of thinking about perception, other minds, shared labels for sensations, how one individual consciousness is shaped by (exists only in context of?) others, and the implications of the information age with more extensive inter-mind connections and increasingly numerous and specific shared labels.
I had one (it was either cheap or free from someone who wanted to get rid of it years ago) and I loved that it was my first TV with HDMI input at a time when HDTVs were out of my price range.
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.
I once spent over $2k on a second-hand 21" CRT at an IT auction. Took two of us carrying it up/down stairs because I was worried about one of us slipping if solo. Needed a corner desk to fit the thing. I remember having 2-3 CRT screens pre-2000 and the desk required filled the room.
I still don't know what it is about 60 Hz that made me see the flicker plainly as a strobing light. TVs at 50 Hz—nothing (other than being generally bleh back then). Had to use 800x600 instead of 1024x768 just to have 85 Hz instead.
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/
The reason for flickering on specific patterns is independent of temporal dithering. This is caused by cyclic polarity inversion: http://www.lagom.nl/lcd-test/inversion.php
(temporal dithering usually is visible as slight noise on darker shades)
Hmm, afaik the framerates were chosen to be equal to the AC freq so that there are no glitches in the image. Do those countries have converters or something in the TVs, or did they watch jumpy image?
Fluorescent lighting, assuming it's not starting to fail, flickers at 120 Hz because each half cycle lights it up equally (+ or - doesn't matter). Incandescent also has 120 Hz flicker but the valleys are almost as bright as the peaks (slow response) so it's essentially imperceptible.
Cheap LEDs like some holiday minilights are rectified so they'll flicker at 60 Hz and I can't stand them.
Three reasons: You sit much closer to a computer screen compared to a TV, so your peripheral vision has a better chance with the computer screen to see flicker. Computer CRTs supported higher refresh rates, so they used phosphors with shorter afterglow (otherwise you'd get ghosting/S&H-like artifacts like TFTs produce). You can notice this one when you photograph a computer CRT vs. photographing a TV with the same shutter speed. And at the end of CRT TVs a lot of them were 100 Hz.
Interesting hypotheses, though I still can't quite accept them as final. I seem to recall that the effect was much more noticeable, not only when sitting in front of the screen—basically enter the room and there it is. And I think that I've experimented with lower refresh rates too, at least I definitely had the time and inclination—but can't remember if the monitor allowed them with the available resolutions. It's stuck in my memory that only 60 Hz does this.
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.
Yeah, and I had 3d shutter glasses that worked great with the trinitron... In 2000 or so. Nvidia 3d Vision came along later but now sadly those product lines are abandoned, I guess due to VR which is just not what I want at all
Coincidentally, my whole team still uses Nvidia 3d Vision 2 at work, despite lack of support from Nvidia. One of the reasons I took the job is because I saw they were using it. Not having access to those systems is one of the hardships of working at home. https://www.jpl.nasa.gov/news/news.php?feature=7638&fbclid=I...
Was that the one with the demagnitize button? I used to slap the monitor while pushing the button so my coworkers would think I hit it so hard the image bounced around
All the better ones had that button, usually named "degauss". My 22" flat CRT (it was flat on the front, like LCDs today, which was a great feature at the time, but made the thing extremely expensive and extremely heavy) had a degauss function that was apparently so powerful it visibly distorted the image on other monitors right next to it when I degaussed mine. I made a joke of doing that in the middle of games on LAN parties ;-) didn't work repeatedly though, after degaussing once I had to wait for some time until degaussing again would actually do something.
And if they didn't, and somehow you managed to magnetize it, you needed to use a degaussing coil, moving it away from the screen in a spiralling motion... ah, the memories.
I assume that by "somehow managed to magnetize it" you mean "had crappy detachable boom box speakers sitting on top of it in college, causing the TV to eventually display distorted blobs at the top edge of the image".
I honestly don't know. I picked up a Compaq monitor with a magnetized grille from the trash in 2002 or so, and used for my secondary pc (a venerable P200 MMX that took a LONG time to recompile the 2.4 kernel on a then-unstable Debian Sarge).
No idea how the previous owner managed to magnetize it, it never happened to me.
I finally replaced my aging CRT at work (3rd screen for unimportant stuff) after it finally died after 20 years of service. I still miss pressing the degauss button, which (perhaps relatedly) needed to be pressed after powering on and sometimes multiple times during the day.
I frequently use apps with "night" theme (black background, white UI controls). You know how Android apps have "back" button on the top-left corner, right?
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.
Make an image of the back button, revert the color, and make your phone display it when you sleep.
You will burn the other pixels and won't see the pattern anymore !
I have an early OLED TV that I burned in (left it on for some reason while I was asleep, displaying YouTube). A few years later there is no longer any evidence of the burn-in; it was very apparent at first, but went away quickly with normal use.
The people I know who use waze a lot (30+ min drive to work every day) have the notify icon (bottom right) clearly burned into their OLED phone screens.
I've been using OLED for a long time now, and never had this OLED burn in - including one particular phone (Ativ S, so Samsung S3 screen) that was in use by me for years and then used as a navigation system by my mother until the battery perished. However, someone I know had a phone (I believe the Samsung S8) nearly constantly playing videos with full brightness, and there it did show red streaks over the screen. I wonder what kind of usage triggers it.
I'm not usually an early adopter but I was the first guy at my LAN party to bring an LCD monitor. It was smaller and looked worse than everyone's CRTs and had terrible ghosting, but everyone was fascinated by it and could tell it was the future.
I've still yet to see an LCD that performs as well as those CRTs, though.
It does. I’m sure most people don’t think the quality difference is worth the hassle of storing physical discs and paying for them. Compressed 1080 is good enough.
True, except now in EU, the bitrate of 4k streaming is low because the EC asked companies to reduce it. This because of the COVID-19 pandemic leading to everyone [who can] being required to work from home.
Yeah, if you buy a new TV and sit close to it you can tell the difference. But I think for most people 1080p at a distance was acceptable where a fullscreen VHS picture would have been illegible, and the convenience became the next biggest factor. The leap from VHS to DVD was a lot larger than the leap from DVD to Blu-ray, in terms of the perceived quality IMO.
Yes. Streaming services provide 1080p or 4k resolution images but it doesn't matter because they apply heavy compression in order to save bandwidth. In my experience, even 100% black frames have artifacts. No wonder people turn to copyright infringement.
The population of devices in the field is heavily dominated by DVD. Old people and immigrants use a whole lot more DVDs because the video they watch is not available online. Fidelity matters way less than the message.
I still buy DVDs because I like classic movies and for those movies it doesn't matter whether you watch in dvd quality or Blu-ray. Plus DVD rips are significantly smaller in size and even though I have Blu-rays for some movies I don't have a Blu-ray player on my computer to rip them. So effectively my preference is to buy DVD, unless it's a relatively modern movie (post 90s)
You're talking about the most popular movies that were transfered to digital or even restored. Most films weren't. Plus, we lost immense amounts (most) of cinema that was produced before ~1950s when better film started being used.
DVDs have been around for over twenty years. There are plenty of things that were released on DVD but now hang in license limbo due to a publisher going out of business or whatever. There may have been a transfer done for a DVD release that would need to be re-done for HD, and that all takes time, money, usually personal interest of some sort, and of course the physical items still have to exist (2008 Universal Studios vault fire, anyone?)
As far as I know lots of TV shows were not shot on film but rather on tape, which naturally limits quality to PAL/NTSC, since that's what gets recorded on tape. Similarly the archives of broadcasters are/used to be tape.
I had heard of this before, but didn't know that screensavers were designed to prevent that damage from happening. In this case, the bouncing DVD logo seems like an odd choice, as the way it's designed, there are certain pixels on the screen that it will never cross (corners, for example), which would fail to serve the desired purpose. Can someone explain?
To expand on this: off is perfect, off most of the time is wonderful, on and changing is great, on and unchanging is bad. So yes, you ideally want equal usage all around but you're splitting hairs between perfect and wonderful with the bouncing DVD logo's coverage.
If you look really really carefully at that video, when the camera shakes around you can see where the motion tracking for the logo overlay loses it a bit.
It doesn't have to cross them. Showing a black screen won't burn it in. The problem is illuminated areas that stay that way for too long. The dvd logo itself just can't be in the same spot. They probably could have just had the tv turn off/show nothing. Maybe it would have confused users not knowing that the tv was still on.
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.
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.
True for any flat screen panel as well.
The plasmas are really prone to ”ghosting” - just a matter of minutes. And there are ”washing” programs to ”reset” the panel.
I guess plasma is the main reason why on-screen channel logos went from solid to translucent?
Ironically, the increased popularity of OLED displays in television, computer and smartphone screens has brought this problem back. If this trend continues, perhaps those 3D maze, tubes, fish, will come back to everyone's computers soon.
Why didn't we do this back in the CRT era, and invented screensaver instead, then? TV is understandable, you don't want a DVD player to show a black screen, otherwise it appears dead. But what about screensavers on computers, why did it come into being? (I know turning a CRT on takes time, but we don't have to turn it off completely to blank the screen either?)
Update: It appears that the original motivation was public terminals/machines.
I don't think it was a major concern. First, you can always display a dummy black image without turning off the CRT. Also, VESA defines two "off" modes in DPMS (1993): blank and fully off. "Blank" allows the monitor to partially suspend without shutting down the CRT completely, which allows an instant recovery.
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.
I really wish modern vendors would stop shipping screensavers -- or at least refuse to disable them on non-CRT monitors.
The energy waste, battery degradation, and keeping the CPU/GPU awake longer are all huge wastes. Sadly, screensavers are nothing but wasteful nowadays.
Gives rise to a quick brainteaser (perhaps depending on whether you've given number theory any thought before): under what conditions is it guaranteed to hit a corner (regardless of where it starts)? Also assume it's traveling with slope 1.
What I want to know is, who implemented the original animation (on silicon, I presume?), and did they foresee that it would have such a cult following today?
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.
292 comments
[ 1.7 ms ] story [ 375 ms ] threadhttps://www.youtube.com/watch?v=QOtuX0jL85Y
What an awesome explanation. Thank you for sharing!
Jesus it's 2020 at least use requestAnimationFrame!
https://flaviocopes.com/requestanimationframe/
The issue is the css properties manipulated, as commented by another person.
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.
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.
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.
https://www.html5rocks.com/en/tutorials/speed/high-performan...
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.
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.
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...
1. https://www.bouncingdvdlogo.com/logos/dvdlogo-01.png
2. https://www.brandsoftheworld.com/logo/dvd-video-0
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)
EDIT: I added a simple rate-limiting function :)
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 :)
No wonder modern frontend is such a mess.
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.
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.
I made one a little while ago https://imgur.com/7t9svTV
It would be much more efficient to turn it into a proper video.
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.
https://github.com/boglarkasebestyen/dvdscreensaver
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.
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.
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...
¹ It was actually an interlaced field, not a frame, but that too much nitpicking.
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?
It worked fine, felt like a huge waste of money. But it weighed over 100 pounds!
We're both just as bad as each other, the meaning is discernible.
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.
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/
(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.
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.
I remember playing MoH:AA, the play experience was quite out of this world.
This basically calibrated the thing to look normal... with the magnet there. It took quite a while to restore to normal.
https://www.youtube.com/watch?v=3pVLizAHby4
No? Huh, guess it was just me ;)
No idea how the previous owner managed to magnetize it, it never happened to me.
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.
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.
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.
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?
Sorry.
(Someone should do a better version.)
Edit: https://news.ycombinator.com/item?id=22882947
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.
I guess plasma is the main reason why on-screen channel logos went from solid to translucent?
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.
The energy waste, battery degradation, and keeping the CPU/GPU awake longer are all huge wastes. Sadly, screensavers are nothing but wasteful nowadays.
Is it always angle of incidence = angle of reflection?
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.
<marquee behavior="alternate" direction="up"><marquee behavior="alternate" direction="left"><span>DVD</span></marquee></marquee>
https://jsbin.com/kuzolurapi/1/edit?html,output