In 1994 I was in high school, and there were no animated GIFs. One way you could make images move in the web browser was to use a mechanism similar to this.
I wrote a C program which would load 6 frames of a smiley face animation and would feed them sequentially, in an endless loop, to anyone who requested the image. Mosaic was happy to animate them.
I get called in to the web mistress's office. The web server is down. We had a donated Silicon Graphics Origin server, if my memory serves me correctly. This was a beefy machine.
The cgi-bin C program would load 6 images, as fast as it possibly could, and dump them into a network socket. It would not throttle. It would not check if the client disconnected. It had one job. It did it efficiently, and ruthlessly.
I expect that you were using this weird corner of the HTTP spec that is X-Mixed-replace[1]; where the server can keep feeding responses for the same request and the browser is supposed to replace the element with the new-one. A lot of IP cameras are using this to stream JPEG to the browser.
This technology is getting phased out and mostly only works with images.
bugzilla still uses it to show the "Please wait while your bugs are retrieved." page while executing a search to then replace the page with the results.
Video tag pointing to an MP4 will use byte range requests in chrome, which is pseudo streaming. For real streaming look into something like rtmp or hls, which does require js in some browsers. The main difference is one can handle live feeds the other cannot to my knowledge. Also real streaming has adaptive bitrate (switch to lower quality to avoid stuttering and buffering). The distinction between streaming and pseudo streaming is blurry. My litmus test is it can it handle live feeds? Html5 video tag cannot without hacks, per my understanding
Our app does something like this by loading an image with an xhr then immediately requesting the next image when the previous one finishes
Multipart+JPEG is easily 5x more expensive than MP4 in terms of bandwidth. All new IP cameras come with MP4 as a replacement. Steaming can be done in various ways, usually with the help of some JavaScript + video tag.
This sounds super interesting; a bunch of questions:
Did you just sent multiple images concatenated into the output stream, including file headers? And Mosaic would actually replace the first image with the second and so on? Was the CGI script referenced in an <img> tag?
Honestly, it was 23 years ago and I forgot the exact details. I still remember the meeting though. The feeling of dread, excitement, and ridiculousness of knocking out such a powerful machine (at the time) in order to server animated smiley faces.
Nowadays, I knock out powerful machines doing slightly more useful things.
This was what we did before gifs. Then gifs came along and we stopped. Funny to see it again... as an innovation! Remember history, because it repeats.
NCSA httpd introduced the Common Gateway Interface which allows you to execute any binary, and whatever it puts on stdout is sent as the reply. Back then it was typically a Perl script or a compiled C binary.
My company makes a DAS(distributed Antenna System) product with an embedded web interface. All of our web sites have C/C++ cgi back ends. There are more makefiles in the Web folder than the whole rest of system. It is quite mind boggling. But the engineer that has control over this area is stuck in the 90s.
Found the old guy :). Back then it was quasi-normal to just write your own HTTP server. A TCP socket that just slapped some headers on whatever it was reading from disk. Now everything is so complex...
I remember using server push, and the CGI interface was a hell of a lot simpler than the 8000 levels of abstraction my Typescript Angular apps going through before they hit the wire.
The worst part is that the majority of the added complexity is useless. Instead of replacing the bad parts of HTTP, HTML, JS, and CSS we just build more shit on top of it. This requires more hacks and just up the complexity level even more.
Interesting. Firefox' developer console does not understand this kind of request properly and shows its termination after the first frame. Chromium on the other hand handles it correctly.
Sure, but the animation sucks. Extremely choppy and slowed down.
I wonder if this technique can optimize preloading.
For instance, we could send out only 1/2 of the frames (of course, with twice the delay to keep the same animation speed), then load the rest as it's available.
I have no idea what I'm talking about yet, but there seem to be something here.
It seems like this is the same as with video, where the client is trying to determine how many frames it needs to precache before it starts displaying. I'm not sure how much measurement capacity the server has, here?
I did the same thing about fifteen years ago by generating a mJPEG stream from a PHP-script. As far as I can remember, it seemed more reliable than using GIF. See https://en.wikipedia.org/wiki/Motion_JPEG
MJPEG is indeed much better for this. It uses less bandwidth (GIFs have no compression) and less browser memory (old frames can be discarded). When I was at globo.com, we developed this to serve animated thumbnails for live video streams: https://github.com/jbochi/live_thumb
The main advantage is that, because a video format rather than an image that can loop, the player can discard past frames. The GIF method is probably constantly leaking memory.
This technique used to be used to embed "videos" into html emails years ago. Haven't seen it used in a long time maybe email clients block the streaming behavior now (for good reason).
This is really cool! Completely suboptimal but fascinating none the less. Great project and idea :) would be interested in hearing some people's ideas for real applications of this
My company uses the same technique at scale to serve animations into emails, often at thousands of gifs generated per second and streamed to the user. Interestingly, when you stream gifs frame-by-frame, some size optimizations are not available to you but there are plenty that are. (cropping, transparency, etc)
Actually, that's not true. GMail proxies images, but doesn't do a lot in the way of caching. They actually cache the DOM when moving between messages for a short while, but a browser reload will reset it.
Been working for 3 years in the past in an email isp I had different information, gmail did cache the images and did it "forever". May be this changed recently?
So this was done during a programming paradigms course at KIT? I'm teaching functional programming basics using Haskell at my university. At the end of the semester we aren't quite that far. But I am far from sure whether this exercise, just looking at the given types, has didactic value and I wonder how much of the stuff the instructor has given and how much the students worked out themselves given the course materials.
I would be a bit hesitant (teaching-wise), to talk about any function of the type IO () -> IO Char -> (Frame -> IO ()) -> IO ()
Although, not to be a spoil sport, it seems like a fun thing to do over a long weekend.
This is just using the framework that I made for the exercise. The students didn't have to do any Crazy IO stuff. You can see the parts under "Aufgabe" here, which is what they were supposed to code: https://github.com/def-/gifstream/blob/master/SnakeFinished....
This seems interesting. Maybe I can use something similar next year to generate some interest. Without IO (which is monads, which is too advances since we also do functional C# and functional java paradigms in the same course) the subject matter is always a bit dry since the students have nothing but the ghci repl to get any interaction or feedback going.
? This would give them a little more liveliness but wouldn't require them to understand anything beyond "IO () is something that the repl can run". If they're feeling exploratory, maybe give them a few monadic combinators like >> to play around with, possibly specialized to IO.
You could also build a "sandbox" monad specifically for the class/framework. Let the students treat the monad as a blackbox Turing machine/state machine, unless they get time/interest/show aptitude to dive deeper. Doing that gives you the benefit that they don't accidentally google "Haskell IO" and fall down the monad rabbit hole without some preparation.
I wonder whether you can even hide the IO in the logic function by providing a random number from the outside which the students can use, so that from their perspective the logic function is pure, which would be quite desirable.
edit: By the way, if you download 2013.tar.bz2, I highly recommend checking out the cable3, which implements an entire IBM PC capable of running Windows 3.0 in only 4043 bytes (8086 nibbles).
> edit: By the way, if you download 2013.tar.bz2, I highly recommend checking out the cable3, which implements an entire IBM PC capable of running Windows 3.0 in only 4043 bytes (8086 nibbles).
People interested in that emulator may also want to know that the non-obfuscated version (still only 760 physical lines of C, though that's partly achieved by putting opcode information in the BIOS ROM) has moved to GitHub:
Very interesting from a tech perspective, make sure you lazy load the gif if you plan on using it after window load event otherwise it's never going to happen and you'll just get the endless spinner :D
Hey, cool, I wanted to do the exact same thing the other day but as a countdown clock. For those saying this has no practical use, a countdown definitely does :)
Looking at the code and the actual file generated, it seems that the image is not compressed at all, using one byte per pixel. It also defines a palette of 128 colors, which is mostly unused. A bit of compression would drastically reduce the image size, this kind of monochrome images of axis-aligned blocks compress very well !
This is great. If I were to serve this over apache is there a limit on the connections? I'm asking because I'm assuming there is only a specific number of concurrent connections per child in apache(?).
So if gif 2 is embedded in 100 sites will it bring my server down since children are not closing connections?
I had problems with Haskell after 1024 open sockets, but compiling with ghc -threaded fixed them. Other than that, no problems encountered yet. (using nginx as proxy)
There's probably a cheap optimization in there somewhere. Diffing frames on each tick, but for that size it probably doesn't matter. Thanks for the link to GifStream!
I notice that it has some problems with lots of visitors and some browsers that delay showing the next frame of the gif. I guess that's what happens when you misuse GIFs
> It is written in Haskell and works by dynamically generating each frame of the GIF and slowly feeding them over the HTTP connection.
This seems rather difficult. These are dynamically generated. There are 246060=86400 possible slides, but at download time, we have to find the correct starting point. Did I get that right?
What would the difficulty be? You pick the first image by looking at the server time then send the next frames once per second...
You may optimize it by sending diffed frames (IIRC the gif format allows one to only update the pixels that change from one frame to the next). You could even pre-generate both sets of images (full frame and diff) and use the script to send the right frame at the right time.
I don't understand why this is getting so much attention. From the description:
"[It] works by dynamically generating each frame of the GIF and slowly feeding them over the HTTP connection."
So there is nothing (AFAICT) new or interesting going on here. It's just an animation generated by the server in real time that happens to be formatted as a gif. It's no different from what many low-end web-enabled security cameras do.
No, low end security cameras send separate JPEG images (sometimes as a MJPEG stream), not GIF frames. GIF frames would be terrible for the cameras because of the limited colour palette.
OK, well, that's true. But is sending an animated gif instead of jpegs really that much of an innovation? If I did the same thing using, say, APNGs would HN go crazy over that?
it is one of those thing you do because you can do that. If you try to open the GIF only it won't work well and if you try to save it as image it won't work.
for me it has no real application that I can think of, it consume lot of bandwidth and processing even for small size gif.
good knowledge for developer, I certainly cannot even think in that line. But no use of it in current form.
I wrote a C program which would load 6 frames of a smiley face animation and would feed them sequentially, in an endless loop, to anyone who requested the image. Mosaic was happy to animate them.
I get called in to the web mistress's office. The web server is down. We had a donated Silicon Graphics Origin server, if my memory serves me correctly. This was a beefy machine.
The cgi-bin C program would load 6 images, as fast as it possibly could, and dump them into a network socket. It would not throttle. It would not check if the client disconnected. It had one job. It did it efficiently, and ruthlessly.
Poor server.