The image that tries to illustrate how frames per seconds affects motion is wrong. At least in my browser, it is crossfading between images in the 30 and 15Hz illustrations. That's not how video works: you show individual images sequentially with no mixing. Simplistic attempts to "improve" motion are universally worse than leaving it alone.
Most display technologies essentially crossfade between sequential frames due to the response time of the image display elements. There's been a lot of work on reducing this but it's still a thing.
1080i is interlaced; 720p, 1080p, and 2160p are progressive, i.e. non-interlaced. My understanding is that most commercial Blu-rays are progressive encodings, broadcast may be different. (1080i was common back in the day.)
Interlaced had the advantage of looking better for fast motion, such as in sports; for example, 480i with 60 fields/sec would look better than 480p with 30 fields/sec, at equivalent bandwidth.
The purpose of interlace is to double the frames per second and capture motion better. The downside is some vertical resolution loss and some odd, but rarely seen, visual artifacts.
Doesn't interlacing alternate even lines from one frame with the odd lines from the next, thus showing 50% of each image? Which would make it a ghetto crossfade as described.
Not really. On a CRT monitor, the odd lines fade before the even lines begin lighting up, and they are on different physical locations on the monitor. Recombination of the two images to improve resolution occurs entirely in the human vision processing system.
It's worth noting that this takes advantage of the human vision system's features. When an object moves quickly across your vision (for example, when turning your eyes quickly down a field), there is resolution loss that your brain makes up for, And when focusing on a still object, vision allows you to see more resolution.
So when a player runs across the camera view, your brain correctly processes the lower resolution and higher motion resolution. And when a player is still, your brain correctly processes the improved resolution.
Yup - for me, each ascender of an "h" is a line of red pixels next to a line of blue, no actual black at any point.
Removing the unnecessary font-weight CSS makes it better. Personally I also find it more readable if I remove the font specification and let it fall back to Serif, and it also takes up less vertical space, but that's a matter of personal taste. Not tried it on mobile.
> Yup - for me, each ascender of an "h" is a line of red pixels next to a line of blue, no actual black at any point.
Each of your pixels is made of a tiny red, green, and blue pixels. The 'black pixel' is the gap between the red and blue sub-pixels (the green being off is black.)
100% contrast. People went to great effort to achieve the highest possible contrast in print, e.g. with barium sulfate coated paper, optical brighteners in paper, single-use carbon film typewriter ribbons, oil based inks so pigments could be used instead of dyes, etc. Contrast is good. The only good reason I can think of to use less than 100% is for syntax highlighting.
This text looks okay to me even if I manually adjust the gamma to approximate doing antialiasing/compositing in linear space. It’s on the thinner side, but plenty readable.
Which platform has “correct” font “blending” (and what do you mean by “blending”)? I have not yet heard of one which does antialiasing or compositing of fonts or other vector graphics in linear (vs. gamma-adjusted) space. The font hinting / antialiasing on Windows is super ugly. Linux varies a lot from one machine to the next and a long history of various font problems.
Maybe what you meant was “looks OK on the Mac with more-correct-than-usual font blending, and looks terrible on X other platform”?
More likely what you meant was “looks OK on a Mac with a high-resolution display (typical of recent Macs), but is harder to read on a lower-resolution display (still common among budget PCs).”
Macs do weird stuff with font compositing, try toggling subpixel rendering in CSS [0] and watch the weight of your type completely change. :- )
Whatever they're doing, at least one of these modes has to be wrong.
Windows is a complete mess when it comes to text display, but that's nothing new, although to be fair to them, they do not screw this particular thing up.
FreeType2 in Firefox or a Chromium-based browser on X11/Wayland is spectacular, especially following the expiry of many ClearType-related patents, and the Adobe's contributions; with the various fontconfig settings which change the output, it doesn't noticeably change the weight (for a given size) for modes that people actually want to use (nobody's going back to v35).
OSX has an interesting approach, and if they could resolve their blending/filtering/rasterization/whatever (god only knows where their problems lie) problems; a lot of people like the tradeoff of legibility for accurate text sizes in a given weight, and that's OK.
[0]: Usually accomplished with -webkit-font-smoothing: antialiased or -moz-osx-font-smoothing: grayscale
CSS rules to disable subpixel rendering (because OSX still doesn't do it right) are littered all over the internet. Here's a random blog post from the front page of HN which has it applied to the body text probably because OSX made the text look inexplicably terrible for no good reason by default:
http://ajroach42.com/floppycasts-1-44mb-podcasts/
There's a reason this CSS property doesn't actually do anything on other platforms.
This is just the entrance to that rabbit hole though; for anyone interested in continuing the journey all the way down I'd highly recommend: https://github.com/leandromoreira/digital_video_introduction.