Sorry, I have misspelled the method name. It's drawInCGLContext. It's in native Glass: GlassLayer3D.m line 153.
With best regards. Petr. On Jul 25, 2013, at 11:02 PM, Richard Bair <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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, [email protected] wrote: >>>>> >>>>>> Changeset: dd30604ab7d0 >>>>>> Author: Petr Pchelko <[email protected]> >>>>>> 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 >>>>>> >>>>> >>>> >>> >> >
