hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
richard.bair at oracle.com
Thu Jul 25 10:24:41 PDT 2013
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?
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.
On Jul 24, 2013, at 11:31 AM, Petr Pchelko <petr.pchelko at 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.bair at 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?
>> On Jul 24, 2013, at 12:32 AM, hang.vo at oracle.com wrote:
>>> Changeset: dd30604ab7d0
>>> Author: Petr Pchelko <petr.pchelko at 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
More information about the openjfx-dev