MSAA and Scene anti aliasing

[Chien Yang]

+1. Well said.

- Chien


Sent from my mobile phone. Please excuse my brevity.

On Jul 15, 2013, at 12:19 PM, Thor Johannesson <thor.johannesson at oracle.com> wrote:

> I think there should be a simple way to request full scene anti-aliasing to improve 3D rendering. And also an optional more advanced way to specify which type¡­
> 
> The current way of setting AA is nice simple hint.
> Scene(Parent root, @Default("-1") double width, @Default("-1") double height, boolean depthBuffer, boolean antiAliasing)
> 
> For the advanced variation, I think it might be premature. Considering there is an ugly workaround to specify number of samples for MSAA, with ¡°prism.multisample¡± system property.
> 
> Exposing too much detail selection too early will only lead to unnecessary complication.  The fact we are using MSAA for full scene anti-aliasing to improve the quality of 3D rendering is an implementation detail.
> For platforms that do not support MSAA or have high restrictions on memory then we might employ a different technique.  For example edge anti-aliasing by post processing.  Once that is in place it makes sense to provide more control to the user.
> 
> -Thor
> 
> On Jul 15, 2013, at 8:05 AM, Kevin Rushforth wrote:
> 
>> I am fine with an enum that represents the style of AA requested: NONE, MSAA, SOME_OTHER_AA, ...
>> 
>> It is the combining of number of samples into the enum that seems undesirable to me. I would prefer that be a separate Integer attribute.
>> 
>> -- Kevin
>> 
>> 
>> Mario Torre wrote:
>>> 
>>> At first I was about to reply a +1 to Kevin, but then I realised:
>>> 
>>> 1. This is indeed an area where people want to know the implementation details.
>>> 
>>> 2. An enum can be extended with different implementations, for example add a non MSAA to the mix.
>>> 
>>> The drawback is that the enum may grow just for the need to add a new property to the AA algorithm. I'm not sure how likely this is, but I didn't see that many actual implementations to consider that an issue.
>>> 
>>> If this is the case, one may have a descriptor object passed rather than an enum, so that external implementations may easily extend/replace the default code.
>>> 
>>> The descriptor could be an opaque type so that the code that needs to handle knows about it, but for users it still behaves like if it was an enum. In fact, the defaults may even be collected in an enum again.
>>> 
>>> Cheers,
>>> Mario
>>> 
>>> Il giorno 15/lug/2013 01:24, "Richard Bair" <richard.bair at oracle.com <mailto:richard.bair at oracle.com>> ha scritto:
>>> 
>>>   I know iOS gives at least two or three options. A single enum
>>>   seems cleaner than two properties (and yet another constructor!
>>>   Speaking of which it would be better if this were a mutable property).
>>> 
>>>   Is it that you don't like that some options can't be honored?
>>> 
>>>   On Jul 13, 2013, at 12:00 PM, Kevin Rushforth
>>>   <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>>>   wrote:
>>> 
>>>> I don't really like the single enum approach. I would prefer to
>>>   keep the existing MSAA boolean, and then, if needed, add a
>>>   separate attribute for requesting the number of samples; if
>>>   desired there could be a read-only attribute that returns the
>>>   actual number of samples used. Most chipsets give limited (or no)
>>>   control over the number of samples anyway so an enum doesn't seem
>>>   like a good fit.
>>>> 
>>>> -- Kevin
>>>> 
>>>> 
>>>> Gerrit Grunwald wrote:
>>>>> +1 for the enum approach...will make it easier to enhance for
>>>   future options...
>>>>> 
>>>>> Gerrit
>>>>> Am 12.07.2013 um 19:55 schrieb Richard Bair
>>>   <richard.bair at oracle.com <mailto:richard.bair at oracle.com>>:
>>>>> 
>>>>> 
>>>>>> Thor recently pushed an implementation for MSAA for those
>>>   cases when the feature is supported by the card and where a Scene
>>>   (or SubScene) is created with the antiAliasing flag set to true.
>>>   MSAA is "Multi-sampled Anti Aliasing", which means that the
>>>   graphics card, when configured in this mode, will sample each
>>>   fragment multiple times. The upshot is that 3D doesn't look as jaggy.
>>>>>> 
>>>>>> However this has an impact on performance (usually an extra
>>>   buffer copy or at the very least you will be sampling each pixel
>>>   multiple times so if you are doing something graphically intense
>>>   then that might push you over the edge where you start to see
>>>   performance degradation). Now multi-sampling can be 2x, 4x, etc.
>>>   The higher the multi-sampling value, the better the quality, and
>>>   the lower the performance.
>>>>>> 
>>>>>> I'm also bothered but the name "antiAliasing" because there
>>>   are many forms of anti-aliasing in the world and it isn't clear
>>>   which this is. I think perhaps we should instead have an enum. The
>>>   idea is that we can add to the enum over time with greater options
>>>   for how to perform the scene antialiasing.
>>>>>> 
>>>>>> public enum SceneAntiAliasing {
>>>>>>  DISABLED,
>>>>>>  DEFAULT,
>>>>>>  MSAA_2X,
>>>>>>  MSAA_4X
>>>>>> }
>>>>>> 
>>>>>> And then grow it over time to include potentially other
>>>   techniques. My thought here is that the implementation is going to
>>>   matter to folks. They're going to want to be able to make the
>>>   performance / quality tradeoff, and perhaps even the
>>>   implementation tradeoff (since different implementations may
>>>   provide somewhat different results). DISABLED turns it off,
>>>   obviously. DEFAULT allows us to pick what we think is the best
>>>   (might be different on different platforms. Desktop might go with
>>>   MSAA_16x or equivalent while iOS might be MSAA_2X). Then some
>>>   standard options.
>>>>>> 
>>>>>> Thoughts?
>>>>>> Richard
>