The physically correct rate for light attenuation is 1/r^2, where r is the distance between the surface and the point light. We used to use a 1/r equation. This is common in colorspace-oblivious rendering since after taking into account that in sRGB a color channel of x produces an amount of light proportional to about x^2.2, the effective attenuation is 1/r^2.2 which is pretty close to 1/r^2. In a979351 the equation was changed from 1/r to 1/r^2. I doubt this was a good idea since now the effective attenuation is an excessive 1/r^4.4. In a linear colorspace we would obviously want to use 1/r^2.

With the introduction of sRGB/linear colorspace, there is the question of how to make a dynamic light API that will give consistent results between the colorspaces. The idea from the current version of #1687 seems OK: a 0-1 RGB color which is interpreted as sRGB, and an intensity which should always be interpreted as linear. Then we could use the formula convertToSRGB(color)/r^2 for the linear colorspace, and if we want to get identical results in the sRGB colorspace, color / r^(2 / 2.2) = color / r^0.90909. To make this API, unfortunately we will have to undo the changes to the 0.56 branch which got rid of the separate 'intensity' argument in favor of unbounded r/g/b.