BlurHash: Algorithm to generate compact representation of an image placeholder

Don't think that's the correct adjective here.

[edit: and that almost all network traffic is now L7 routed because of gatekeeping firewall administrators in the late 90's, so everything had to go over :80 or :443]

To be fair, isn't it the DBA's job to gatekeep the database? The application programmers and business managers don't have the in-depth understanding to know how every individual change will effect the database. Of course they should follow best practices, but it's not really their job to know it inside and out - that's what the DBA does.

You don't know that 200 bytes per row would cost nothing - that's the DBA's job to understand it's cost. And we aren't talking about the amount of data, but without an in-depth understanding of what tables they were adding it to, how they're indexed, cached, etc, then you don't know the real cost. That 200 bytes might mean less can be stored in memory, if this is a frequently fetched table then that could be bad.

That's not to say the DBA made the right call, but that we don't have enough information to know if it was.

Point of order though: I don't think that's right for MacOS, though you're certainly right for Windows. HFS+ lets you use any Unicode symbol including NUL (because the filenames are encoded Pascal-style). I don't know the details how how APFS does it, but it also appears to support any Unicode code point, though it additionally mandates UTF-8. [0]

[0] https://developer.apple.com/library/archive/documentation/Fi... grep "filenames"

This is because classic MacOS used : as a directory separator instead of /, and this behaviour is preserved in the UI, but obviously not in the underlying layers.

    assets/example.png#LEHV6nWB2yk8pyoJadR*.7kCMdnj
    assets/example.jpg#LEHV6nWB2yk8pyoJadR*.7kCMdnj

    \ / : * ? " < > |

I wonder how the efficiency compares to just encoding on the bit level.

But yes the biggest performance gains aren't in pure, static IMG tag usage scenarios, the biggest performance gains I saw were in combo with CSS animations, and that was something important to what I was studying. As Blurhases are useful loading states this seems a common use case to me of having a Blurhash shown/involved in things like navigation transitions, and it seems pretty clear browsers have a lot more tricks for optimizing static images involved in CSS Animations than they do for canvas surfaces.

I was looking for a way to better amortize or skip the initial render as well. It should be possible to take the TypedArray `decode` buffer and directly construct a Blob from it, but I couldn't find a MIME Type that matched the Bitmap format Blurhash produces (and Canvas setImageData reads) in the time I've had to poke at the project so far. As I mentioned, memory pressure was a performance concern in my testing, so I'd also be curious about the performance trade-off of paying for an initial canvas render and getting what seems to be a "nearly free" compression to JPG or PNG from the GPU in converting that to blob, versus using a larger bitmap blob but no canvas render step.

Of course, my first clue should have been that it was also the only Javascript file.

You could probably devise a much smaller data representation too, to get the size down.

Like cinemagraphs, but unique and alive in a nice way.

http://i.imgur.com/Cb4ecUC.gifv