+1. Well said.
- Chien
Sent from my mobile phone. Please excuse my brevity.
On Jul 15, 2013, at 12:19 PM, Thor Johannesson <thor.johannes...@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.b...@oracle.com
>>> <mailto:richard.b...@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.rushfo...@oracle.com <mailto:kevin.rushfo...@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.b...@oracle.com <mailto:richard.b...@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
>
