very poor performance on iOS :(

[Richard Bair]

Sadly, not much. There is a reasonable chance that the VM is playing a large role here, as 27ms for CSS for a single button is pretty bad, but unfortunately there isn't enough information in the logger to nail down exactly what is the issue. If you have a build environment setup, you can try to add pulse logger statements in other parts of the code to get a finer-grained understanding of where the time is going. For example, if you can put timing traces around exactly where the OGL present happens (when he card goes and acts on all the stuff we've told it about) then we could tell if the time is being spent on the Java side or the GL side.

The "Painted" metric includes both. You can see how it is used in ViewPainter#doPaint.

I'm not sure the right place to instrument to get just the time GL spends, but I think if you put the timer around this block in PresentingPainter then it would be right. I'm not certain though, somebody from the graphics team?

                if (vs.getDoPresent()) {
                    if (!presentable.present()) {
                        disposePresentable();
                        sceneState.getScene().entireSceneNeedsRepaint();
                    }
                }


On Jul 24, 2013, at 3:03 PM, Tobias Bley <tobi at ultramixer.com> wrote:

> Hi Richard and Niklas,
> 
> here are the results of pulseLogger for a simple click of a ToggleButton in a StackPane:
> 
> PULSE: 3 [12259ms:306ms]
> T1 (1 +27ms): CSS Pass
> T1 (28 +0ms): Layout Pass
> T1 (28 +0ms): Waiting for previous rendering
> T1 (29 +0ms): Copy state to render graph
> T7 (56 +1ms): Dirty Opts Computed
> T7 (60 +241ms): Painted
> Counters:
> 	Nodes rendered: 3
> 	Nodes visited during render: 3
> 
> 
> So how can we interpret these results?
> 
> Best,
> Tobi
> 
> 
> Am 24.07.2013 um 21:06 schrieb Niklas Therning <niklas at therning.org>:
> 
>> Please try running with perfLogger and also Instruments. As I've pointed out before RoboVM is in early stages of development. It doesn't do release builds yet. Virtually nothing has been done yet to optimize things for speed. So my guess is that you will find that a lot of time is spent in RoboVM code. Also, AFAIU the Oracle guys have run this on iOS internally and have seen decent performance (can someone confirm?). That would also suggest that RoboVM is the problem at the moment.
>> 
>> /Niklas
>> 
>> 
>> On Wed, Jul 24, 2013 at 5:13 PM, Richard Bair <richard.bair at oracle.com> wrote:
>> Unfortunately, I'm one of those stuck waiting for the apple developer portal to come back online in order to renew my apple developer subscription, so I can't actually try this out myself.
>> 
>> Have you tried running with the perfLogger (I included instructions and how to understand the output in another thread yesterday). If you can show the output from the perf logger that would at least give some guidance as to where the time is being spent.
>> 
>> Richard
>> 
>> On Jul 24, 2013, at 5:16 AM, Tobias Bley <tobi at ultramixer.com> wrote:
>> 
>> > Hi,
>> >
>> > i would like to start a discussion about the performance of JavaFX8 on iOS (via RoboVM). If you make a little app with just one toggle button and run it on iPhone4 (not simulator), the JavaFX rendering is very slow. So the button press is painted with a really noticeable delay. I don’t understand this behavior because I thought JavaFX rendering is very good and optimized using hardware accelerated OpenGL code???
>> >
>> > Best regards,
>> > Tobi
>> >
>> 
>> 
>