iOS: missing native font lib (a) in SDK directory

[Richard Bair]

> Obviously there's a lot going on with the move to gradle, but we are a few lines of Gradle build code away from JFX on iOS. I'm keen to find out just how well it will run. 

In the runs I've seen (not on RoboVM) the main bottleneck is in graphics rendering. We don't know specifically why yet, but we have a lot of ideas. Now that Tobi reports FX + RoboVM (including fonts!) is working, I'm eager to see the performance characteristics as well.

With the work you've done on the developer workflow and now that we've got an open build running on the device, we are going to need to get organized around measuring, reporting, and fixing performance issues encountered on the device. Likely some of it will be RoboVM related, but there is plenty of optimization to do in Prism as well.

We've learned a lot about embedded hardware over the last year or so. Some of the things we've learned:
	- It is almost *always* fill rate limited
	- Pixel shader complexity costs you
	- CPU -> GPU bandwidth is very limited

Solving the fill rate issue is huge. The Android team reckons that you can overwrite the same pixel maybe 2x before you start noticeably losing performance, 3x or more and you're dead. It doesn't even matter what it is you are doing per-pixel (could be simply filling each pixel with a solid color). The fact that you are running a pixel shader for 3x or 4x the number of pixels taxes the hardware.

So for example, right now I believe we are doing 3x overdraw before we even do anything. I think first we do a clear, then we fill with black, then we fill with the Scene fill color. Then we draw whatever you give us. Obviously this is not optimal!

For pixel shader complexity -- you can probably get away with more complex pixel shaders if they are only running 1x per pixel, but when they are running 3x or 4x per pixel then the complexity of the pixel shaders burns you. We did a lot of optimizations here already so hopefully we've got this one in good shape. But just something to be aware of.

The CPU -> GPU bandwidth problem is one that is systemic with all these mobile devices. Higher bus speeds == less battery life, so the devices are designed with low bus speeds and this makes transfer of data between CPU and GPU costly. Games will typically do all the transfer once up front (all the graphics assets for a level are loaded up front) and then during the game they are just adjusting the viewport & vertices (often in vertex shaders so as not to pass much data down to the card), etc. Right now we are doing a tremendous amount of communication with the GPU.  Ironing this out is the basis for the "super shader" (https://javafx-jira.kenai.com/browse/RT-30741).

I would recommend anybody interested in performance keep the "Open Performance Issues" filter on their JIRA dashboard. There is a link to 221 performance issues (most of which are ideas about things to do to improve performance). We also need to close the loop on the other issues we were discussing about jerkiness a couple weeks ago.

Richard