> 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
