search

Yanrishatum / yagp

Yet Another Gif Parser
MIT License
25 stars 3 forks source link

Works on Android #2

Open ashes999 opened 9 years ago

ashes999 commented 9 years ago

I tried loading a 640x346 gif (38 frames) on my Android device. Runs and displays quite well. I would send a pull request for the README.md, but I'm not sure what else needs to be done (eg. you have to make a platform-specific test txt file).

Also, I see around ten copies of this error message when I build for Android:

SVGData.hx:117: Warning, unknown transform:translate(5.7143)

However, it does run and display quite beautifully on my (low-end) phone.

Thanks for such a great library!

Yanrishatum commented 9 years ago

Actually, GifPlayer not optimized to use on mobile platforms, because it uses BitmapData.setPixels/fillRect/copyPixels methods when renders next frame. For better speed you may need to use GifRenderer and render entire gif to spritemap, and then use it for Tilesheet (but it's more expensive in memory usage).

The test txt files are just comparation between haxe-gif library and speed test, how fast image will take to process.

I don't know why this warning appears, I think it's from OpenFL's BitmapData implementation or something like that. I'm not have an Android device, so can't test it. (Yep, cave man, using typical old mobile phone)

ashes999 commented 9 years ago

The other issue I noticed is what appears to be a memory leak: if I keep switching back and forth between two FlxStates (HaxeFlixel), the animation starts getting choppier and choppier and choppier.

Rendering to a spritesheet won't work. In my case, my image is large enough (640x346) that I can't fit more than a couple of images in without running over the texture size limit (1024x1024 is the smallest) -- which is why I turned to animated GIFs instead of spritesheets.

Overall, I'm quite happy with the results.

Is it possible to scale the playback up or down? I use HaxeFlixel, so the rest of my game scales nicely to my device screen.

Yanrishatum commented 9 years ago

Hm. Maybe it's because of rendering issues. As said in GifPlayer description - it's a fast and dirty implementation. It's may be an error in GifPlayerWrapper, which assumes, that ENTER_FRAME event will be sent even if DisplayObject not added to display list. (behaviour of Flash)

If you use GifPlayerWrapper, you simply can use scaleX/scaleY. If you have your own wrapper to GifPlayer, you probably need to scale it yourself as you need it to be scaled. (GifPlayer only provides a BitmapData, displaying it is a work of wrapper)

Yanrishatum commented 9 years ago

The other issue I noticed is what appears to be a memory leak: if I keep switching back and forth between two FlxStates (HaxeFlixel), the animation starts getting choppier and choppier and choppier

Can you check it with last version? It's probably fixed.

ashes999 commented 9 years ago

I checked the latest version, and I can still reproduce the leak.

It may be my imagination, but I think it's degrading more slowly now than before.

Yanrishatum commented 9 years ago

The only reason I can imagine - bugged disposing of BitmapData. When frame uses Dispose Method: Restore Previous, new BitmapData will be created to be used when frame will be disposed, but I call dispose() method right after disposing frame. You can modify it, to store this BitmapData's, and generate them only once, and reuse them in future.

ashes999 commented 9 years ago

Sorry, I'm not following.

Thanks for trying to fix this.