Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
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 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 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 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
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
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 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 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 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 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 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 >> 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/GlassLayer
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
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 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 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 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 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 > 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 > >>> >> >
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
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 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 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 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 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 >>> >> >
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
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 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 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 >>> 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 >>> >> >
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
> What about on Windows, is there any impact there from this change or is it > truly just for Mac? No. This change affects only Mac. With best regards. Petr. On Jul 24, 2013, at 11:07 PM, Richard Bair wrote: > So this should impact the "jitter" you would see on mac. What about on > Windows, is there any impact there from this change or is it truly just for > Mac? Has anybody tried to measure for dropped frames on Windows? > > Richard > > On Jul 24, 2013, at 11:31 AM, Petr Pchelko 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 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 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 >>> >> >
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
So this should impact the "jitter" you would see on mac. What about on Windows, is there any impact there from this change or is it truly just for Mac? Has anybody tried to measure for dropped frames on Windows? Richard On Jul 24, 2013, at 11:31 AM, Petr Pchelko 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 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 >>> 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 >>> >> >
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
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 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 >> 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 >> >
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
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 > 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 >
hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
Changeset: dd30604ab7d0 Author:Petr Pchelko 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
hg: openjfx/8/graphics/rt: RT-26702: Poor DisplacementMap effect performance on Mac [Java code only, fixes potential drawing of garbage on first frame on OS X]
Changeset: 167bc510ce34 Author:snorthov Date: 2013-05-29 16:05 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/167bc510ce34 RT-26702: Poor DisplacementMap effect performance on Mac [Java code only, fixes potential drawing of garbage on first frame on OS X] ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/PresentingPainter.java ! javafx-ui-quantum/src/com/sun/javafx/tk/quantum/ViewPainter.java
