Basically I just played around with making GIFs. And it looks like problem is in the fact that neither browser neither my image-viewer are able to play GIF images with frame rate higher than let's say 7-9 FPS.
Here's link to the GIF i generated from the "red-black" sketch using ImageMagik
this is link to gif with "0" specified as delay between frames.
this is link to gif with "10milliseconds" specified as delay between frames (equal to 100 FPS)
on my machine both of them (when viewing in Chrome) play at around 7FPS
So looks like the problem may be limitations of players rather than GIF-maker.
EDIT2:
So I decided to try to use only 40 frames from the animation to make GIF. From what I can see on my machine, there's NO perfomance improvement. (At least no significant. Or maybe I am just tired of watching those circles for 1h)...
EDIT:
Here's link to Image Magik page of how to compress GIFs:
As to "fast-running GIFs" - i guess they're very low resolution, eg. 128x128 or smth. Or maybe on top of small dimensions, they have only 20-30 frames.
WHILST TRYING TO FIGURE OUT WHAT WAS WRONG I STARTED DRAFT OF THE POST, MAYBE SOME INFORMATION MAY BE USEFUL:
The Issue of saveImage() slowing down execution is ONLY related to interactive sketches or sketches which rely on clock-related animation.
The original "red/black" sketch on openprocessing is neither. It doesn't use millis() and thus it's not "clock-related". It just adjusts it's position by frame.
Because of that if you just saveFrame() all of the sequence into a folder you will get perfect and smooth sequence of each and every frame without any animation being lost.
As far I can see the resulting GIF has two separate problems:
a) it's slower than the original sketch
To solve this one, it may be better to simply save frames with saveFrame() and after that just convert them into GIF with some GIF-making tool which allows to specify framerate. Eg. ImageMagik command line utility.
In case of this sketch the writing to disk is almost not a problem (because these are red/black images which can compress well), the problem is the converting them to GIF. I tried to use ImageMagik to compress like For me to compress 357 frames (less than 10 seconds of running of the sketch). And ImageMagik (a command line utility written in C++ tool over 30 seconds running all my CPU cores at 100%). Maybe processing GIF-export library is not so sophisticated as ImageMagik, but we can anyways assume that converting to GIF (palette making, LZW compression) may take some time.
b) the colors are not as smooth as in the original sketch
This one comes from the fact that GIF was invented in 1987. It's VERY old image format, which somehow managed to survive till today.
It only allows to have 256 color-pallete and this is why your colors may not be as smooth as you want. Again there's no much of solution to this.
Also transparency is not represented as alpha/mask, but just as 1 color of 256 color palette, which is rendered as fully transparent dot. (in plain english: dot which is not rendered at all)