On 7/25/2013 9:24 PM, Richard Bair wrote:
Hi Petr,
We are in a separate thread discussing "jitter" where being able to
measure dropped frames is crucial. We have the PulseLogger class
which keeps track of this kind of information (at least, it measures
the amount of time spent in a particular pulse). There is a message
that sometimes displays about dropping a frame, but I don't know if
it captures the same cases as what you have captured here. Where did
you instrument to measure which frames were actually rendered?
Just a short comment here. I'm not sure it matters, but it seems there
is some misunderstanding here.
RT-26702 was the case, when a bug was in the mechanism used to measure
performance. We counted the number of rendered frames in Prism/Quantum,
but the number of frames really delivered to the screen was different.
The message about dropped frames is likely about dropping at
Prism/Quantum level, not at the Glass/CALayer level.
Petr's fix for RT-26702 addressed this problem, so more frame rendered
in Quantum are now displayed on the screen. That's why even if you see
FX perf counter now reports a lower number (comparing to what it did
before the fix), the actual number of frames displayed to the screen is
higher.
Thanks,
Artem
I need a reliable mechanism for measuring jitter. We're not running
full speed, so if I'm handling frames at less than 16ms per frame,
then I should never see any jitter, unless we have a loss of
synchronization between our pulse timer and the display. How can I
measure this reliably? Right now we have to just stare at our
monitors and see if something looks suspicious. I'd rather have a
fool-proof method of determining whether we're hitting each frame
right on target.
Any ideas?
Richard
On Jul 24, 2013, at 11:31 AM, Petr Pchelko <petr.pche...@oracle.com>
wrote:
Hello, Richard.
These changes fix the problem with dropping frames on Mac because
of locking between the render thread and UI thread.
I have made some measurements with Controls benchmark and GUIMark2.
The numbers without braces is the FPS rendered by Prism and the
braced numbers represent how many frames we are actually rendering
on the screen.
Test Fix No Fix
bitmap-1000 76.1 (76.0) 75.3 (44.1)
bitmap-3000 38.3 (38.1) 36.9 (31.2)
bitmap-5000 23.4 (23.2) 22.6 (18.4)
vector 31.6 (31.3) 31.8 (29.0)
CheckBox 79 (79) 67 (47)
As you could see, with the fix we almost never drop frames, all of them are
actually delivered to the screen. Prism performance is improved in some cases
too. These are not all the results, just examples to feel the difference.
With best regards. Petr.
On Jul 24, 2013, at 8:23 PM, Richard Bair <richard.b...@oracle.com> wrote:
The name of the issue is pretty ho-hum, but actually this was a huge amount of
work to get finished. Petr, Artem, or Steve, can you give us a run-down of the
performance impact of this change on Mac?
Thanks
Richard
On Jul 24, 2013, at 12:32 AM, hang...@oracle.com wrote:
Changeset: dd30604ab7d0
Author: Petr Pchelko <petr.pche...@oracle.com>
Date: 2013-07-24 11:24 +0400
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd30604ab7d0
RT-26702 Poor DisplacementMap effect performance on Mac
Reviewed-by: anthony, art, snorthov
! modules/graphics/src/main/native-glass/mac/GlassEmbeddedWindow+Overrides.m
! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.h
! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.m
! modules/graphics/src/main/native-glass/mac/GlassLayer3D.h
! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m
! modules/graphics/src/main/native-glass/mac/GlassOffscreen.h
! modules/graphics/src/main/native-glass/mac/GlassOffscreen.m
! modules/graphics/src/main/native-glass/mac/GlassView3D.m
