[Rev 03] RFR: 8217472: Add attenuation for PointLight

[Nir Lisker]

On Wed, 5 Feb 2020 13:48:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> We have a few performance tests in apps/performance, but I don't know how up to date they are. They might give you a starting point on how to measure FPS, but really the harder part is going to be coming up with a workload -- a scene with a number of Shape3Ds with large triangles (so that they are fill-rate limited) and 1-3 lights, etc -- that you can use to measure rendering performance without measuring overhead. Typically you want a scene that is rendering continuously in the < 30 fps range, and more like 10 fps to minimize the overhead even more.
>> 
>> Before we figure out whether we need to double the number of shaders (which was one of the ideas that I had as well), we need to know how much of a problem it is. Is it < 2% performance drop on typical cases on a variety of machines or it is a 25% drop (or more likely somewhere in between). If the perf drop is negligible, then it isn't worth doubling the shaders. If it is significant, then we probably need to.
>> 
>> If we do need to double the shaders, I wouldn't do it based on the maxRange being infinite, rather I would do it based on whether attenuation is being used. That way the existing shaders would be unchanged, while the new shader would deal with both attenuation and the maxRange test.
>> 
>> Hopefully, there won't be enough of a perf hit to require doubling the shaders, but we need to be able to measure it.
>> 
>> For functional testing, in addition to the simple API tests, we want to make sure that the basic rendering is working with and without attenuation. Some sort of visual test where you verify that attenuation is / isn't happening as well as testing the cutoff. I wouldn't get too fancy with these...just a sanity test.
> 
> Looks like the `jcheck` bot removed the `rfr` label because the CSR isn't complete. An incomplete CSR should be treated the same way as an insufficient number of reviewers. I filed [SKARA-262](https://bugs.openjdk.java.net/browse/SKARA-262) to track this.

I've taken the sample app and enlarged the box to fill the whole range of the lights in an attempt to have many pixels rendered for few vertices. I measured 90-115 fps during continuous animation with this patch, and 100-120 before it. I measured the fps using an external app called BandiCam.

Will do more tests this week.

-------------

PR: https://git.openjdk.java.net/jfx/pull/43