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 <[email protected]> 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 <[email protected]>:
>
>> 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 <[email protected]>
>> 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 <[email protected]> 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
>> >
>>
>>
>
