MSAA and Scene anti aliasing

[Kevin Rushforth]

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
>     >>>
>