Can you point me at the code? I'm in graphics, and I've done a search in the whole of rt and I don't see CALayer drawInGLContext anywhere in the code. (I did both an IDEA case insensitive recursive search and also a grep -r on the command line)
Thanks Richard On Jul 25, 2013, at 11:26 AM, Petr Pchelko <petr.pche...@oracle.com> wrote: > Hello, Richard. > >> Where did you instrument to measure which frames were actually rendered? > Actually, I've made a bit of hacking to get this and my solution is not > cross-platform. > > On Mac each time the [CALayer drawInGLContext] is called we are rendering a > frame to the screen. And this is reliable - if we've exited this method the > frame must be on the screen. So I've added a counter into this method which > calculates the average number of method calls per second and logs it. In > production this counter was removed. Of course external tools could be used, > like OpenGL profiler, but I suppose that's not what you want. > > Also, on Mac we have a flag in native which represents if the frame was > delivered or not. So, using that flag, it is quite easy to add a logger which > would warn you that a frame was dropped. Nothing could be done in Java for > this, because we have a complex processing in native code and frame drops > happen there. > > I have no idea how it could be done on other platforms, because I am familiar > with this area only on the Mac. > > With best regards. Petr. > > On Jul 25, 2013, at 9:24 PM, Richard Bair <richard.b...@oracle.com> 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? >> >> 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 >>>>> >>>> >>> >> >
