iOS iPad2/3 textureatlas multi-threading

Starling Forum » Miscellaneous » Announcements

iOS iPad2/3 textureatlas multi-threading

(14 posts) (8 voices)

Started 10 months ago by marcumw
Latest reply from wrench

Tags:

gpu TextureAtlas

marcumw

Novice Bird
Joined: May '12
Posts: 8

Here is my first attempt at an iOS iPad2/3 Starling app "DataFizz" accepted into appstore:
http://itunes.apple.com/app/datafizz-s-p500-free/id522441571. Actually the original app was cpu the latest update incorporates Starling. Thanks Dan! It was a pleasure working with the framework. I also went a little hogwild with the tweenmax library.

It's more a "sketch" or "case-study" in interactive data visualization. My biggest challenge was balancing the single-threaded-ness of Adobe Air with the slow load time of texture atlases during start-up in a mobile environment. Maybe Adobe will be rolling out multi-threading soon for Air??

Posted 10 months ago #
Josh Tynjala

Feathers Guru
Joined: Feb '12
Posts: 2,471

The Adobe AIR 3.4 and Flash Player 11.4 betas currently available on Adobe Labs support ActionScript Workers in the desktop runtimes. Workers are not yet available for AIR on mobile, though, but Adobe has said that they will be coming in a future release.

Posted 10 months ago #
Daniel

Primary Feather
Joined: Jan '10
Posts: 2,445

Congratulations on your app! I'm still only iPad 1 owner, so I can't try it out -- but the screenshots look great, I'm sure it contains nice animations. =)

It would be great if you could add the game to the showcase of Starling-powered apps!
http://wiki.starling-framework.org/games/start
Thanks in advance!

Posted 10 months ago #
wrench

Senior Bird
Joined: Jun '12
Posts: 176

Digging out an old thread, but I'm coming to the final stages of a project that I've been working on with Starling and am having the same issues as marcumw was having when loading TextureAtlases and them freezing the UI. Has anyone got any tips on pseudo multithreading the TextureAtlas generation that they'd like to share...?

Posted 3 months ago #
Daniel

Primary Feather
Joined: Jan '10
Posts: 2,445

If you're using ATF textures, there's now a "async" argument in the "fromAtfData" method. That should make it a little better!

If you use the AssetManager, this will already be done for you. It also decodes PNG files in the background when you load them from a file/URL, so you might get a better result if you use that.

Posted 3 months ago #
wrench

Senior Bird
Joined: Jun '12
Posts: 176

@Daniel - thanks for the tips, I'm actually using atf for one of my backgrounds (the quality of alpha rendering is fairly ho hum so am only able to use it for that) and am using the async property when creating the texture from it.

I'm using a reasonably complex mixture of a static TextureAtlas (a .png file) two DynamicTextureAtlases (so I can keep some of the rapid prototyping workflow I enjoy with the Flash IDE) coupled with Away3D (I've got a coverflow effect which isn't currently possibly in Starling... bring on the Sprite3D Class!

I started using Starling before the AssetManager was around, but am aware of the image decoding policy property you speak of. In my experience it's not the loading of the png into the app, but the upload and creation of the texture that freezes the UI and takes the time.

Obviously creating the TextureAtlas at runtime from emibap's class is causing a lot of the UI freeze upon app init, so I'd like to take a look at creating a pseudo threaded version of that class as well.

I'll report back with the speed difference in app initialisation when using two dynamic textureatlases compared to converting them to two atf files instead. I'd expect it to be a lot faster, but just how much will be interesting. The app currently takes just on 5 seconds to become "active".

Posted 3 months ago #
wrench

Senior Bird
Joined: Jun '12
Posts: 176

Ok, I've knocked out a single spritesheet to replace the two dynamic atlases I was creating and have just tested loading it in as a png initially.

Remarkably it only shaves about 1 second off the time it takes for the app to launch and become responsive. Could be because the png is being embedded and so the app is loading it into memory, might possibly get better mileage out of loading it at runtime. The locking of the UI still occurs, so the spinning loading disc is still stuck on frame 1.

Loading that same spritesheet in as an atf (which I believe loads asynchronously) doesn't seem to have any effect on app load time or the locking of the UI.

So I guess I need to be looking elsewhere for the UI locking I'm experiencing. I am doing a lot of instantiating of views at app startup which I'm guessing is where the CPU is spending a lot of it's time.

Posted 3 months ago #
alex_h

Moderating Bird
Joined: Feb '10
Posts: 190

Hey wrench, have you tried using Adobe Scout to analyse what your app is doing? It's pretty amazing the amount of useful info you can get out of it! You should be able to work out what processes are making your app seize up if you get Scout on the case.

Posted 3 months ago #
wrench

Senior Bird
Joined: Jun '12
Posts: 176

Hehe, I knew that follow up was coming

Yes, yes I have used Scout (was on the pre-release for 6 months) but am now at the final stages of the project I'm on so will fire it up again (now that atf and static spritesheets haven't solved my problem) and see what I can see.

Posted 3 months ago #
tastychutney

Moderating Bird
Joined: Aug '12
Posts: 120

Wrench, make sure you're loading both the ATF file asynchronously from disk (if that's where you're getting it from -- I highly recommend it), and telling the GPU to load it asynch as well:

this.texture = Texture.fromAtfData(this.urlLoader.data, 1, false, atfCompleteCallback);

Note the asynch callback function (atfCompleteCallback). This causes the ATF data to be uploaded to the GPU asynchronously.

Posted 3 months ago #
wrench

Senior Bird
Joined: Jun '12
Posts: 176

@tastchutney - thanks for the tips, but I'm already adding the texture using the async callback (and the atf is actually an embedded asset in the app)

Posted 3 months ago #
FBB

Competent Bird
Joined: Jul '12
Posts: 40

Well this is more of user experience solution than a "good" solution, but usually what I do is load textures inside an EnterFrame 1 by 1 and I skip 1 frame between them. Then I usually create sometime of loading system (a bar), this way it gives the illusion that the UI isn't frozen... it does not shave anytime from loading, but at least it does not give that awfull sensation that the app has crashed.

Posted 3 months ago #
tomph

Senior Bird
Joined: Feb '12
Posts: 91

@wrench, have you tried to disable mipmaps when creating your atlases? This shaved off more than 50% boot time on my game.

Posted 3 months ago #
wrench

Senior Bird
Joined: Jun '12
Posts: 176

@tomph - Yep!

I actually edited emibap's Dynamic Texture Atlas code to disable the mipmap generation, and it did knock the app bootup from around 8 seconds to around 5 seconds.

Posted 3 months ago #

RSS feed for this topic

Reply

You must log in to post.