OpenFL running slow on the Apple TV

#1

Now that I’ve got OpenFL running on the Apple TV I see that the performance are very low and I’m sure it’s not a hardware problem as I’ve deployed a couple of Unity based projects on the same box and they run fast as I’d have expected.

Here you can see the old BunnyMark demo (with the old Tilesheet stuff that HaxeFlixel still uses):

And here’s the latest BunnyMark. I either managed to get the wrong one or they both run at the same pace:

#2

I was probably using the old version of the BunnyMark

We got a stage problem though :smiley:
Same version of OpenFL, it’s just that the new BunnyMark is not using the Env class that checks for the screen density. I’m going to try to bring that in to see how it works.

#3

Did you get any FPS?

Perhaps the Apple TV is just not very fast, I’ve seen poor performance from Smart TVs (very poor), not sure where this lands

#4

I haven’t been able to work on it yesterday, sorry.
The CPU/GPU is the same as the iPhone 6, the A8, so it should be on par with the performance of that phone.

#5

It’s funny but the FPS is not showing and it’s probably due to this problem:

I’m going to have a deeper look at that issue later today.

Cheers!

#6

I fixed the problem with the FPS text. I’ll send a PR later.

  • With the latest BunnyMark I get 30 FPS at the beginning. When I increase the bunnies to 25.000 it gets to 25 FPS.
  • With the old version of BunnyMark I get 30 FPS at the beginning (500 bunnies). With 10.000 bunnies it drops to 7 FPS :smile:
#7

So Tilemap gives you the extra performance I assume?

Also what are the specs on AppleTV? Seems quite slow.

#8

Yes, Tilemap gives a big boost to performances.

Actually it’s the same chipset as the iPhone 6. It features the same A8: https://en.wikipedia.org/wiki/Apple_A8
But the Apple TV has 2Gb of LPDDR3 RAM (the iPhone 6 has just 1Gb)
The GPU is on the same chip and even though it’s not known for sure, it should be a PowerVR GX6450.

I still have to find a benchmark to run on the Apple TV. Apple hasn’t released many sample projects for tvOS yet.

I’m adding a link to the hxscout session when I run the old BunnyMark example using -Dnext
This is the version using Tilesheet (NOT Tilemap)

#9

Hmm, until we instrument more in OpenFL, all the hxt tells us is that the time is spent in “rendering”. I don’t see a ton of allocations or collections. There’s a ramp at ~40 seconds where the trace output is “1000, 1100, … 6000” – I assume it’s tracing how many bunnies are on the screen. It goes from ~30 fps down to about 8 fps during this time, all rendering:

Pasted image760×286 26.7 KB

The “rendering” instrumentation (for Next) is here: https://github.com/openfl/openfl/blob/018b432652405fb13344b4dab63e5541fcedabf3/openfl/display/Stage.hx#L1139-L1167

#10

The ramp up is when I added more bunnies, up to 6.000 of them.
TBH I think it’s good that it’s only a rendering issue. We can try to hunt down the problem. On the other hand, it might as well be an issue lying in SDL, don’t you think?

Has anyone got an SDL benchmark project that I can run to check the performances?

#11

Oh, I forgot, since Next is written in Haxe, you can look at the profiler stacks to see where time is spent in the rendering calls:

Pasted image767×466 51.4 KB

Perhaps not surprisingly, it’s all in SpriteBatch.renderTiles. (Of course, it doesn’t show you what’s inlined.) I wonder if it would be interesting to run it with --no-inline (is that a valid switch?)

#12

Thanks for the analysis @jeff_ward. I tried to compile the same example with the --no-inline switch and there’s some more info for you to have a look at: https://dl.dropboxusercontent.com/u/3098924/bunnymark-next-tilesheet-version-tvos-no-inline.hxt.zip

#13

What is needed to compile for tvOS? When I try it I get this error:

Do I need to install lime from github?

#14

I don’t know if hxcpp and lime have been released since my patches went in. If you want to give it a try you can set haxelib to use my repo for both lime and hxcpp (remember to use the tvos branches):


On top of that you also need to clone my version of SDL (tvos branch again) and replace the src/ and include/ folders in lime/project/lib/sdl
https://bitbucket.org/santinelli/sdl/src/3f20f7ff3cbfceb948fe293113cdf0a14d11126e?at=tvos

I’m still waiting for the guys at SDL to merge my tvOS changes into the main repo. And Lime is using the sdl-native project that is set to a specific revision of the SDL repo so you have to do a bit of copy & paste to get everything ready to deploy on the Apple TV.

#15

Thanks - this is what I get.

I installed everything per your instructions.

Then, once I try to compile something, I get "This version of hxcpp (/usr/lib/haxe/lib/hxcpp/git/) appears to be a source/developement version.
Before this can be used, you need to:

  1. Rebuild the main command-line tool, this can be done with:
    cd tools/hxcpp
    haxe compile.hxml
  2. Build the binaries appropriate to your system(s), this can be done with:
    cd project
    neko build.n
    "

Once I do that I get an error message: Error: In file included from ./lib/sdl/src/SDL_hints.c:21:
In file included from ./lib/sdl/src/./SDL_internal.h:34:
lib/sdl/include/SDL_config.h:52:2: error: Wrong SDL_config.h, check your include path?
#error Wrong SDL_config.h, check your include path?

And then if I try to compile after that, I’ll get this error: Error: Source path “/usr/lib/haxe/lib/hxcpp/git/lib/AppleTV/libstd.appletvos-64.a” does not exist

So should I have generated the libs before copy/past your SDL mods?

#16

I think this could be helpful to other developers willing to play around with tvOS.
I’m going to go over this with you just like if I had to do it from scratch.

I’m assuming you have Haxe 3.2.0 installed on a Mac. I’m still on Yosemite so I do not know if El Capitan could bring issues to my workflow.

First thing we get hxcpp running:

git clone https://github.com/tanis2000/hxcpp.git
cd hxcpp
git checkout tvos
cd ..
haxelib dev hxcpp hxcpp
cd hxcpp/tools/run
haxe compile.hxml
cd ../build
haxe compile.hxml
cd ../hxcpp
haxe compile.hxml
cd ../../project
neko build.n
cd ../..

Next up is our copy of SDL and Lime

hg clone https://[email protected]/santinelli/sdl
cd sdl
hg update tvos
cd ..
git clone https://github.com/tanis2000/lime.git
haxelib dev lime lime
cd lime
git checkout tvos
git submodule init
git submodule update --recursive
cd project/lib/sdl/include
mv configs ../
cd ..
rm -rf include
rm -rf src
cp -R ../../../../sdl/include ./
cp -R ../../../../sdl/src ./
mv configs include/
rm include/SDL_config.h
lime rebuild tools -v -clean
lime rebuild tvos -v -clean

At this point you should be able to go to your project folder and do an openfl update tvos -v -clean to get the XCode project for tvOS.

Let me know if that works for you or if you encounter any problem.

Cheers!

1 Like
#17

Thanks so much for that, unfortunately it does not seem to be working just yet.

First,

haxe compile.hxml
cd …/project <<<< Should be two levels up, I think

neko build.n
cd …/…

But more importantly, when I try to build the tools, this is what I get:

lime rebuild tools -v -clean

Error in building thread
g++ -Ilib/sdl/include/ -Ilib/sdl/include/configs/mac/ -DHAVE_LIBC -DUSING_GENERATED_CONFIG_H -DTARGET_API_MAC_CARBON -DTARGET_API_MAC_OSX -D_THREAD_SAFE -mmmx -msse -msse2 -c -fvisibility=hidden -stdlib=libstdc++ -O2 “-I/Users/hak88/Documents/workspace/test/hxcpp/include” -DHX_MACOS -m64 -Wno-parentheses -Wno-unused-value -Wno-format-extra-args -DHXCPP_M64 -DHXCPP_VISIT_ALLOCS -DHXCPP_API_LEVEL=0 -x c ./lib/sdl/src/SDL_error.c "-o/Users/hak88/Documents/workspace/test/hxcpp/project/lime/project/obj/darwin64/d1952bb7_SDL_error.o"
Error: In file included from ./lib/sdl/src/SDL_error.c:21:
In file included from ./lib/sdl/src/./SDL_internal.h:34:
lib/sdl/include/SDL_config.h:52:2: error: Wrong SDL_config.h, check your include path?
#error Wrong SDL_config.h, check your include path?
^
1 error generated.

So this is the exact same error I had before. Any idea how to fix this?

#18

Well, I don’t know much about the in’s and out’s of rendering, but here’s normal (with inlining):

And here’s what’s revealed without, aka --no-inline:

So the time is mostly being spent in fillVertices, with significant time from there also in ArrayBufferIO.set calls - not sure if that’s helpful, obvious. or otherwise. :smile:

#19

I know why it’s failing. I made you replace the whole project/lib/sdl/include.
You should actually first move the project/lib/sdl/include/configs somewhere safe.
Then you can remove the old include folder and replace it with the one from my SDL repo.
Next copy the configs back there.
And finally remove the include/SDL_config.h

This should solve your issue.

Let me know if it works. Cheers!

1 Like
#20

Getting real close.

I think what needs to be added to your script is this in the end:

lime rebuild hxcpp tvos

else, you do not have the libs in hxcpp you need.

After that, compile seems possible, however I can’t really tell yet, as I’m searching for the right cable right now to connect to my appleTV.

It seems, compiling to the simulator is not possible so far, build fails, while compiling to a binary with openfl fails on the certificate step. Xcode does not want to compile for me without the TV connected, So I’ll get a cable now and will report back