Issues with GIF Codec in zView - Solved by Lonny Pursell!

When Zorro coded the picture gallery application 'zView', he created one of the most interesting and enjoyable applications for higher end Ataris. A number of common, and less common picture formats could be accessed and viewed from an attractive thumbnail gallery. This worked especially well with an upgraded desktop, so the more attractive that your front end was, then zView gained beauty points along with it.

Amongst these, was a displayer codec for animated GIF's, which I found almost by accident. I pronounced this 'well good'. This codec generally worked, but with several potential bugs or outright failures that were included at no extra cost. When Zorro abandoned further work on zView, these were not resolved.

They are described below. There may be other smaller issues still lurking, but these are the main four areas of issue.

1. The most common problem was with the GIF animating, but displaying with a 'snowy' background, almost as if it was being shown with additional white noise. Sometimes this was constant, but often only one or two frames of the whole animation were affected this way.

2. A smaller but still significant number displayed a perfect static picture, without animating at all.

3 I also found a minority which displayed but with a messed up display, as if what used to be called the vertical hold on analogue TV's was not working correctly.

4. The most frustrating issue was that some GIFS crashed zView completely. These were generally of a larger file size, which led me to suspect an 'out of memory' problem. It tended to be more of an issue on memory constrained systems such as the Aranym virtual machine, but not so on the more generously stocked live hardware, such as a CT60.

After a long time of hit and miss, and tolerating these foibles, a GFA-coding hero, Lonny Pursell, sometimes known as 'LP' came on the scene, with a view to improving the state of zView and adding to it. His loving creation of several new codecs, for even more obscure Atari specific formats is touched on elsewhere, however, one of the things he managed to do was to tidy up most of the issues with the animated GIF codec.

The following part of the article is part derived from public postings on Atari Forum, and part from emails between myself and Lonnie, (Myself sourcing raw material for Lonnie to test and resolve.)

Snowy GIFS.

Lonny resolved this one quickly, as he found a bug in the transparent colour handling that was used to render the background.

Static GIFS.

This one is best explained in Lonny's own words.

"The particular gif CiH sent me had 0ms set for all frame delays."

"For the technical bits, the problem really is with zView, it does some maths on the frame delay and determines it can't be animated, so it shows the first frame and that's that. I don't think Zorro expected zero as a frame delay."

"This is a typical problem with GIF creators and they upload them like that. After googling it for a while I discovered how the web browsers deal with it, usually by setting some minimum frame delay in such a way that it don't make the cpu hit 99% load.

"However, there was some controversy over what that minimum value should be and it might vary from browser to browser. What I did was watch it in Firefox and then tweaked the frame delay until it looked like it was running the same speed. I ended up at 10ms which was discussed. Anyway, the updated codec checks the delay of each frame, any frame set to 0ms is upped to 10ms. This makes zView happy and thus it now animates."

Jumbled display.

Lonny fixed the issue with the faulty display. It used interlaced and non- interlaced frames in the same file. The first frame was interlaced but the rest were not. Somehow this was not sorted out correctly when zView was coded originally.

Memory hoggers.

Lonny refers to a specific GIF file, which is seemingly small, but we discover maybe this is not the case. Again, this goes down better in his own words.

"The example GIF that seems small is actually made from 153 frames. Assuming a 256 colour mode, take 383x272 in bytes, then multiply that by 153 frames. You also have to keep in mind that the codec decodes the whole thing at once, before zView even requests an image to convert into a bitmap. Effectively the whole lot is in ram twice. It's definitely not the most ram efficient scheme, but that's how it works. I'm pretty sure that this GIF is ok, but you need a crap load of ram to load it."

"Also zView doesn't do any fancy delta display methods, or anything that would reduce the ram. It will convert all 153 frames to full bitmaps in the current video mode."

Quite a few larger GIF's decline to play on a 64MB emulated memory, via Aranym. More favourable results can be expected with a CT60 class or similar, with two to eight times the fastRAM available. Otherwise, short of a complete recode, this is one we're stuck with.

In conclusion, for all his work for the Atari scene generally, but especially for his recent work on zView, Lonny gets a 'Hero of the Atari Scene' special service award!

CiH - With Lonny Pursell - August 2015 for Maggie 25th Anniversary issue.

Back to the Seriousness.