Topic: GIF/PNG generation with JS? (Page 1 of 1)

Hey guys,

I remember some time ago, a few people here had come up with some clever code to generate a GIFs and PNGs client-side using Javascript, similar to how Wolfenstein 5K (and many others) generated XBM images.

Does anyone have any code for this still lying around? I'm curious to try out some algorithms using it.

Jason

Sorry man, only have BMP generation code to hand, although can readily provide that if you'd like?

Gif, Png, absolutely anything ( yes! ) can be generated in JavaScript and used in the browser through the data: URI scheme. So far the most common application I've seen/done was BMP because the file format is dead simple and small-ish images ( e.g. 96x64 ) can be generated on the fly at ~20 fps.

Check out Neja or my old and dirty texture generator ( ca 2004 ). Notice the bytes to ISO conversion is sub optimal in these examples. Since then I simply use a LUT of escape( String.fromCharCode( value ) ) or the following function:

/*
 *  bytes2iso
 *  argument  any number or values
 *  return    a String with the arguments casted to byte and converted to ISO format
 */
function bytes2iso()
{
    return escape( String.fromCharCode.apply( String, arguments ) );
}

alert( bytes2iso( 64,20,40,65,69, "string will give %00", Math.PI, foo ) )

Also I always work with an LFB that I join('') and concatenate to the BMP header before flushing to an IMG tag or similar. One more thing, 8bits BMP might be faster ... unless the values put in the LFB are already converted to ISO.


Hope that helps,



(Edited by poi on 12-31-2007 14:30)

Gents, let me take the opportunity to whine about Wrayal's web space being down too often (can't access it for the past days).

And offer a solution, a 2GB solution : http://www.beyondwonderland.com/wrayal
Which I will offer to anyone who has a history of steadily posting on the 20liners or contributing useful things to the DHTML forum.

Why do I do this? Certainly not to rule the world by owning your javascript sources

I have 50GB of web space, and rising, and 10 times more bandwidth A MONTH, for a low, low, low cost (you wouldn't believe the price).
I like useful information to be up and maintained, and available to the masses : it serves them, and it serves me back, the better the web,
the better my browsing experience.

Another example of this are the java cfxweb contests, which I used to moderate when the site was up.

As a former member of a prominent java demo group, featured in the contests linked below, I have kept a mirror to this day..
Cfxweb's Java Applets Coding Contest

Ah, BMP! I totally forgot about the existence of that format. That should work as well. Thanks for the links, guys.

yeah that's probably one of the last cases where BMP is actually relevant.

quote:

---

poi said:

Gif, Png, absolutely anything ( yes! ) can be generated in JavaScript and used in the browser through the data: URI scheme.

---

They say IE8 will support data URIs.

quote:

---

poi said:Notice the bytes to ISO conversion is sub optimal in these examples.

---

It is however the simplest way of doing it, right?

edit: in terms of line count ... there is no bin to base64 1 or 2 liner correct?

(Edited by Arthurio on 01-12-2008 13:02)

Base64 conversion requires to mangle the bits and stuff.

However, since binary to base64 conversion turns 3 bytes into 4 characters, it's possible to make a specific 1-line method converting an triplet of bytes ( RGB values ) into base64.

But binary to ISO is easier and probably faster. Beside, although you work in 24bits, you often use a limited set of colors therefore the conversion is often not necessary or can be done using a look up table / hash table.

Another significant perfomance boost is to use 256 colors or less and generate a BMP8. This way the number of bytes to convert is divided by 3, and if you use even less colors, you can position them in the range of characters that don't change when converted to ISO hence eliminating the conversion altogether

Could someone tell me what's causing the huge memory leak in my code (firefox).

Warning!: huge memory leak

Also ... does firefox have a frame rate cap? It looked like I can't get it past 21fps ... didn't test much though.

edit: hehe ... i'm a lazy sob ... :P ... it seems to be the .src = asd that causes a leak ... so do you guys know if there's an alternative that won't cause a leak? ... i guess I'm off to testing .appendChild and .removeChild ... :/

(Edited by Arthurio on 01-12-2008 16:31)

(Edited by Arthurio on 01-12-2008 16:31)

Out of the top of my head, I'd say Fx is not garbage collecting the many images generated.

Regarding the speed, you should store the RGB "strings", don't separate the component unless you have too. Also you could precompute a noise array containing, say, 256 random RGB "strings". Doing so raised the frame rate from 17 to 21 fps here in Opera 9.5b.

Browsers apply a minimum interval between each execution of JS code. It generally is around 10-20 ms. The fps caps is therefore around 67 fps.

Do you know of a way to force firefox to garbage collect the old images? Seems pretty hopeless because even closing the tab or window doesn't help . Unless I find a solution to the memory leak I can't take this script any further.

Dunno. It's never really been a problem for me. Does Neja leak like crazy in Fx2 ? It doesn't in Fx3b2.

FWIW, Opera 9.5b doesn't leak with your script.



(Edited by poi on 01-12-2008 17:31)

ff2 with neja takes max 150mb ... my little script with ff2 stops rapidly climbing at around 200mb ... weird... I'm installing ff3 now

edit: now my script takes max 160mb and neja max 110mb (ff3b2)

ff3b2 looks pretty bugged though ... managed to crash it 2 times already

(Edited by Arthurio on 01-12-2008 18:11)

What do you mean my script doesn't leak on opera 9.5b ... it does :P ... neja doesn't start at all though on my opera :S ...

Well the leaks aren't too bad ... at least they stop at some point. I'll try some things with canvas later and if nothing works I guess I'll just have to accept it.

ok ... less whining, more programming ...