I just confirmed that this works.  Nice job!  Maybe I will start using chrome again

I think you (aww, I think English lacks of respectful "you" word...) can post it by yourself. I'm too new to Pixeljoint, for submitting news.


Wow, thanks. Didn't thinked about any rewards for my small job.

Fun fact: I loosed 5$ for creating that extension. Because Google takes that price for publishing in Chrome Web Store. I don't think it's a big price, but in Russia 5$ is more expensive, than in other countries (and I talk about not-central Russia).

Okay. But extension works not as good as I want. GIF parsing still slow (because Javascript haven't byteArray and all data parsed from ASCII. And Javascript itself much slower than inline code) and takes tons of memory.


No-no. I'm talked about it only as fun fact. All job done only for 1 reason - make people happy while they using Chrome.
Most of my friends, told me, that I'm idealist, and didn't request gain in most of my works. So, I'll try to fix it.
*Edited by jal*
If it's necessary, I can create a web page with this information.

Edited by jalonso - 21 October 2013 at 4:34pm

There might be a small bug in the extension.
In some pieces when you zoom to view if the art has a transparent (mask) background then the zoom view shows the color being masked. Is this to be expected in some pieces only?
This piece does it
http://www.pixeljoint.com/pixelart/81449.htm

Edited by jalonso - 25 October 2013 at 8:03am

I feel your pain, I struggled with the GIF spec when I implemented animation in Grafx2.
Timing weirdness is the fault of web browser, who all chose different ways of not following the GIF spec. If you want to mimic Chrome's current behavior, you have to convert timings of 0 and 1 to be both = 10 (hundredth of seconds).
If you still have problems with BG color / Transparent color / Disposal method, I can probably help. I also have somewhere a small collection of GIF images that use different combinations of all these options.

Don't bother with RestorePrevious : I don't think any web browser actually implements it, so if somebody puts such GIF in a web page, it already displays as broken.
Speed : The only trick I can think is something you are maybe already doing : GIF frames can be "differences", but you should build a complete image of each frame in memory. This way, you can skip frames if the display is not fast enough to display them as fast as requested.

I dug back the origins of my sample images :
http://www.pixeljoint.com/pixelart/50153.htm (classic with transparent BG)
http://www.pixeljoint.com/pixelart/63475.htm (BG is not transparent)
http://www.pixeljoint.com/pixelart/63454.htm (BG is not transparent, uses delta-compression IIRC)
http://www.pixeljoint.com/pixelart/63865.htm (preview image, all blinking frames have zero-duration: Shame on you Jinn for abusing the GIF format !)
http://www.pixeljoint.com/pixelart/71438.htm (BG is not transparent, I had problem with the color of hands/feet)
(140Kb animation warning) http://www.pixeljoint.com/pixelart/21653.htm
(740Kb animation warning) http://www.pixeljoint.com/pixelart/56897.htm
The last two were made by Stickman using a program that saves GIF animations with one of the two DisposalMethods that don't clear ('default' and 'do not dispose'), following frames replace the smallest rectangle that has any modification compared to the previous frame.

Wow, this was a big update. So, version passed from 1.1 to 1.4. And for good reason.
First of all, I'm fixed bug, that really slows down GIF processing (My fault: I used Array.concat instead of Array.push.apply). Now it works many times faster.
* Rewrited almost all code, so JPG/PNG and GIF processors not so separate in code. (And this gives me a basis to add in-page image scaling)
* Added switch button between canvas/original images to context menu (right click). That was a reason, why extension now requires "tabs" permission. Content Scripts didn't allowed to manipulate with context menus and I'm need to create bridge between content script and background page. (Sending data between background page and content scripts requires "tabs" permission)
* GIF viewing works now much better and (I hope) shows all images correclty (exclude images, that use Disposal Method 3, but to gifs, that uses this method extensions will show next message: )
* If GIF image have over 1048576 pixels in total (1024x1024 image) parsing will stops and shows alert, that parsing can produce lagspikes, so user must activate parsing manually.
Alert! After update, Chrome will disable extension and requests you to approve extension permissions again, because I added "tabs" permission to manifest (explained "why" earlier).

Oh, I have small offer (not sure, that I'm used right word) to Pixeljoint: I can provide code, that replaces zoomed image to canvas, while user presses zoom buttons on Chrome.

Updated to 2.3.0. Now work much faster and with full in-page viewing feature support!

Well. Long time no updates. But now extension finally has restored in WebStore and fully usable (previous version is broken, because of new Webkit version, that removed hacky gif rendering on canvas).
Extension also fully rewritten on Haxe and using my own gif image decoding highly optimized for less memory usage.
Version 3.0.0:
Fully rewritten extension. Nuff said :D