[HN Gopher] The fastest GIF does not exist
___________________________________________________________________
The fastest GIF does not exist
Author : todsacerdoti
Score : 457 points
Date : 2022-02-20 14:11 UTC (8 hours ago)
(HTM) web link (www.biphelps.com)
(TXT) w3m dump (www.biphelps.com)
| kajal7052 wrote:
| uthmancodex wrote:
| Forge36 wrote:
| This "in practice spec" is a cool dive into history.
|
| There is a similar quirk in the RTF spec where x and y
| coordinates were swapped.
| andrewmcwatters wrote:
| If you think that's crazy, there are other things like this that
| browser vendors do that are _not_ standardized, and when you
| start writing a renderer to figure out why your output doesn 't
| match, you find all of these silent agreements everywhere.
|
| If you know, you know.
| ridaj wrote:
| The internet in all its duct tape glory.
|
| Prime example of trade-off between cleanliness of implementation
| and backwards compatibility. As much as I like a pristine, pure
| spec, the market winners are clear. It pays to keep product debt
| around.
| keyraycheck wrote:
| If we could only deprecate features more aggressively, our code
| would be so much cleaner...
| afiori wrote:
| flutter and Dart are essentially this applied to the DOM and
| JavaScript
| Gigachad wrote:
| And then you get a HN thread linking to some 10 year old
| bugzilla thread about how firefox doesn't support non
| UTF-8/ASCII encoded websites.
| [deleted]
| wk_end wrote:
| What's the deal with the "hypothetical" IE5 source code that
| looks very much like actual IE5 source code?
| garaetjjte wrote:
| There have been leaks over the years.
| OJFord wrote:
| I think it's a joke, and the excerpt taken from a leak without
| admitting that.
|
| Along the lines of 'downloading Linux distribution ISOs'.
| ufo wrote:
| I've got to say that the dancing dog doesn't have the same pizzaz
| if it's cropped like that, without his friend.
| mad182 wrote:
| So pretty much the same as this: https://webaim.org/blog/user-
| agent-string-history/
| btdmaster wrote:
| I converted the GIFs to APNG and both ffmpeg and ffplay gave the
| same results as the browser, so the specification is very
| consistently ignored.
| miohtama wrote:
| I like the "Internet Explorer 5 is closed source, but could
| hypothetically look something like this" bit.
|
| Is this source code available through MS partnership programs or
| an old leak?
| layer8 wrote:
| There was a source code leak in 2004:
| https://slashdot.org/story/43253
| stingraycharles wrote:
| I recall there was a leak a long time ago, but definitely well
| after the IE5-era. Hypothetically, it could be this leak where
| the code comes from.
| 07d046 wrote:
| It's in the Windows 2000 leak.
| Banana699 wrote:
| I was confused by this, I wondered on what basis they inferred
| that code. Never occured to me it might be leaked.
| oefrha wrote:
| Pretty easy to find the code on Sourcegraph:
| https://sourcegraph.com/search?q=context:global+fake+one+up+...
|
| The repos I checked have all been DMCA'ed on GitHub, though.
| [deleted]
| rr808 wrote:
| Its pretty trivial to disassemble binaries back into C++, but
| its against ToC so you wouldnt admit to doing so.
| nneonneo wrote:
| This has real comments, white space, and meaningful variable
| names. It's vanishingly unlikely to be decompiled C/C++ code
| in this case.
| ldjb wrote:
| I don't believe the source code is still available officially
| (although it used to be through Microsoft's Shared Source
| Initiative and Government Security Program), but the Windows
| 2000 source code was leaked back in 2004.
|
| https://news.microsoft.com/2004/02/12/statement-from-microso...
| draw_down wrote:
| Windows 2000 and NT 4 code leaked in 2004.
| vanderZwan wrote:
| Given that the reason for the forced delay is historical abuse by
| ads, I'm wondering if back in the days this didn't lead to an
| arms race between browsers and ads (I wouldn't know because I
| always use an ad-blocker). For example, after canvas was
| introduced ads could use those instead.
| NotSoVeteran wrote:
| Author here - loving all the discussion! I was a bit intimidated
| to submit this to hn - I'm humbled that someone else thought it
| was worth posting. Of course, happy to answer any questions
| anyone may have!
| alisonkisk wrote:
| nayuki wrote:
| If anyone is interested in reading the GIF specification, I
| reformatted the plain text version into HTML:
| https://www.nayuki.io/page/gif89a-specification-html
| andai wrote:
| Neat! Is there an automated tool for the conversion? Preferably
| hooked up to a RFC database?
| joshvm wrote:
| Rate limiting or clamping "0" delays upwards can also help for
| polling applications where you want to be as fast as possible,
| but you're never going to be _actually_ zero. For example if you
| have a thread that 's pulling images from a camera (publishing at
| 30 fps) in a loop, you can delay for 1ms between polls and nobody
| is going to know, but that can have an enormous impact on CPU
| usage; especially on embedded platforms. Instead of running at
| 100% thread usage (calling camera.read() and waiting for it to
| return true), the spin/loop cost is basically free and you only
| need to worry about the cost of acquiring/decoding the frame. In
| theory branch prediction should help because you'll take the "no
| image yet" branch 99% of the time, but in practice that just
| makes the loop iterate faster. I learned this the hard way
| writing a custom camera publisher in ROS, but I've seen it a lot
| in tutorial code and I think a lot of beginners make that
| mistake.
| wzdd wrote:
| IMO a better, though more complex, solution would be to keep the
| frame delays as specified in the GIF, but to disable GIF looping
| if the sum of all frame delays was less than 10 ms. That way you
| get the one good use case (>256 colour gifs) but malicious or
| broken GIFs with 0 frame delays don't hang your machine. This is
| complicated by the fact that browsers (used to?) display the
| first frame of a GIF before the complete animation was loaded.
| But you could handle that easily enough by making this decision
| at the time of first loop rather than at initial GIF load.
|
| (Fortunately, this is all largely irrelevant nowadays.)
| xoa wrote:
| An interesting quick dive into how some of the artifacts of
| historical implementations can carry forward decades later. I'm
| saving this one. While everyone on HN is probably familiar with a
| pile of examples of this in our own work particularly if you do
| anything lower level, this is a nice example because it's really
| easy to grasp even for total non-programmers and gives a feel for
| the layers upon layers the digital world is built on. Details on
| the x86-64 bootstrap sequence are interesting to tech people but
| this is the sort of thing I might show in a school class.
|
| That said at first I thought the author was being a bit tongue in
| cheek on the suggestion to fix it with:
|
| > _A downside to making any changes is that the badly formatted
| GIFs won 't render any more. I reckon just be bold, like the
| release of Netscape 2.0...If Netscape was fine with breaking
| poorly-made GIFs, we should be too!_
|
| But we kind of have a bit more content now then when Netscape 2
| was released, and it seems they're serious?
| Support more than 256 colours in a single frame of GIF animation
| Support fast GIFs (10ms delay) No confusing behaviour with
| small delay = slow GIF Better compression for GIFs with
| multiple small areas updated per frame
|
| But frankly at this point why? We've got good universally adapted
| image formats that do more than 256 colors. We've got webm and so
| on (even Apple caved on that one in the end) for baked animation
| which is much smaller and more powerful than gif, and plenty of
| CPU and libraries for generation on the fly. We've got powerful
| ways to do animation purely with HTML/CSS/SVG/JS. GIF is a
| historical artifact with a lot of its value at this point purely
| about old things. This wouldn't even retroactively bring newer
| capabilities to older systems because it would require updated
| code which by definition means the ability to run new browsers
| and thus modern capabilities.
|
| I get they really enjoy hacking on gif but come on. Only way I
| can see it working is if all the players agreed on some metadata
| that could be added to gifs which wanted 'standards' vs
| 'historical' playback with the default remaining historical, and
| potentially also make it a browser setting. That'd still leave
| the ad issue, but maybe at this point that's moot given the
| advancements in blockers (and it'd be a very easy thing to look
| for as an indication of an ad, and thus be selected against).
| rsch wrote:
| If only.
|
| GIF is still the only format that supports animated frames, and
| is supported in most applications that support images. I
| sometimes create some animated WEBP to post somewhere, but the
| outcome is always the same, I have to go back and convert it to
| GIF or it won't display.
| layer8 wrote:
| > We've got webm and so on
|
| The spiritual successor to animated GIFs -- by that I mean
| nonlossy pixel-perfect animations -- would be APNG, which is
| supported by virtually all current modern browsers:
| https://caniuse.com/apng
| hutzlibu wrote:
| "nonlossy pixel-perfect animations "
|
| That sounds way less awesome, when you consider it only had
| 256 colors, so allmost all content did indeed loose a lot, by
| converting to gif.
|
| And this is actually the first time I have heard of apng and
| interesting that it is even now widely avaiable. But I do not
| really see a broad use case, compared to webm.
|
| Because file size matters usually much more, than pixel
| perfect animation.
|
| I wanted to convert a short screencast to a gif, result:
| hundreds of megabyte big monster, with crappy quality.
|
| The same with webm: 2 MB and good enough quality.
| layer8 wrote:
| The use-case isn't video, it's small icon-style color
| animations or animated pixel art (like the example in the
| article). It's the same difference as between JPEG and PNG.
| Hokusai wrote:
| > That sounds way less awesome, when you consider it only
| had 256 colors, so allmost all content did indeed loose a
| lot, by converting to gif.
|
| Nonlossy can be used for pixel perfect animations, lossy
| formats cannot.
|
| > Because file size matters usually much more, than pixel
| perfect animation.
|
| It depends. For video, that is true. For user interface,
| any glitch is distracting. Using JPEG for user interface
| images like buttons is in most cases a bad idea. Each
| format is useful in different situations.
|
| > I wanted to convert a short screencast to a gif, result:
| hundreds of megabyte big monster, with crappy quality.
|
| You are right, that is not a use case for GIF or equivalent
| formats.
| gfody wrote:
| we have better formats but gifs are still everywhere, maybe
| there should be a gif222 to fix this stuff and maybe improve
| compression a bit too
| NoahKAndrews wrote:
| That's kind of the point. What makes you think that people
| still using suboptimal GIFs are going to want to go update
| those GIFs to comply with breaking changes in how the spec is
| interpreted?
| secondcoming wrote:
| I don't know why the animated gif seems as popular as ever, I
| can't think of any positives about it... bad colours, large file
| sizes and are encoders more readily available than proper video
| encoders? Also, supporting it fully now requires either threading
| or an event loop. The value isn't worth the complexity.
| LeoPanthera wrote:
| It's still a reasonable format for its original use - images
| with large areas of solid color where only a small percentage
| of pixels change across a small number of frames.
|
| If your animation has <256 colors then it's even lossless,
| something not possible with any of the video codecs.
| garaetjjte wrote:
| >something not possible with any of the video codecs
|
| Which codecs? You can have eg. lossless H264 just fine.
| LeoPanthera wrote:
| Lossless h264 requires 4:4:4 chroma, which is allowed by
| the spec but not supported by many consumer playback
| methods. (QuickTime Player, for example, only supports the
| yuv420p pixel format.)
| brigade wrote:
| It is part of the High 4:4:4 Predictive profile, but you
| can use it with 4:2:0 subsampling if you want. It's more
| accurate that the all profiles H.264 defined kinda sucked
| except for Main, and no one really thought 10bit, 422 or
| especially 444 were useful and completely ignored those
| profiles until it was too late to be worth implementing.
|
| Actually, lossless video is also rather marginally
| useful, especially given the decode cost of the
| arithmetic coding H.264/HEVC/VP9/AV1 have.
|
| Ironically for your example, lossless, 4:4:4, and 10bit
| H.264 actually will play back on the new M1 Macs in
| QuickTime Player, though with a warning about it.
| zamadatix wrote:
| H.264, H.265, VP9, and AV1 all support losless encoding
| (regardless of color count).
|
| Webp is the more literal replacement for the GIF use case
| though and also has no color limitations in the lossless
| animation mode.
| malwarebytess wrote:
| For the user the proposition is the opposite. The value of the
| technically superior formats isn't worth the increased use
| complexity.
| h3mb3 wrote:
| They usually work where jpg and png images work too, most
| importantly in most places where you render Markdown. No matter
| how more efficient a real video file would be, often a short
| gif right there in the README.md is the perfect way to convey a
| piece of information.
| npteljes wrote:
| Partly because of how they're presented to the user. You send a
| video, there's usually a play button, a bit of a delay to load,
| and sound. Gifs play automatically, first frame loads with
| barely any pause, and there's no sound ever. So, they present
| two different use cases, which, at the end of the day, have
| nothing to do with the format itself. But it can show that to
| humans, often the ends matter, not the means.
| Gigachad wrote:
| It's also a UI issue. On most OSs I can copy/paste an image
| like it was text. And a gif counts as an image so I can
| copy/paste images without having to save them. And since many
| modern UIs are hostile to saving videos, its the difference
| between holding and copying vs having to take a screen
| recording or finding a video download website to rip it.
| hackandtrip wrote:
| Are they though? If I remember correctly, most "gif" sites
| online serve webp...
___________________________________________________________________
(page generated 2022-02-20 23:00 UTC)