MSAA and Scene anti aliasing

Mon Jul 15 17:27:05 PDT 2013

The discussion on choice of anti-aliasing algorithms reminds be me of the cipher suite setup for the jce, which represents this kind of information using String tokens.
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html

There you end up with stuff like =>
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_RSA_WITH_AES_256_CBC_SHA256
... ad infinitum

It's kind of similar because you are choosing an algorithm (or combination of algorithms) and various combinations of key lengths, hash lengths, etc.

For the cipher suite stuff, the implementation just punts completely on attempting to provide something which is type safe.
Instead, the cipher suite is just an opaque string token.
You can enumerate at runtime what are the available cipher suites (in code).
You can have different implementations which support different cipher suites.
If the user requests a cipher using a string which is not known to the currently enabled security providers, the cipher request will throw an exception.
There is a subset of known cipher suites which must be present in all implementations.
What is available in any given release for an implementation can be found be consulting the technote documentation (as linked above).

You can lookup a cipher algorithm without specifying the fully qualified string and let the underlying implementation make a best guess for stuff you don't specify.
For example Cipher.getInstance("DES/CBC/PKCS5Padding"), or just Cipher.getInstance("DES").
So for an antialiasing sample if you didn't want to be specific about the number of samples,  you could specify MSAA, and if your did want to be specific, use MSAA_8.

It works OK and has allowed a flexible specification of algorithms in the jce for years.
It does lack a discoverability aspect though, i.e. your IDE is not going to hint you what the available cipher suites are. 
The cipher suites don't show up with appropriate documentation in javadoc.
Instead you need try to dig up the obscure technote documentation on the internet (later revisions of the jce class javadoc have been a bit better in linking to this technote).
A sample of what the javadoc ends up being for an approach like this is:
http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html#Cipher%28javax.crypto.CipherSpi,%20java.security.Provider,%20java.lang.String%29

JCE is an older api created before enums existed, but I'm not sure you would realize this level of flexibility with an enum.

There are tradeoffs for just using a String to represent this information versus other typesafe options.
I'm not recommending this approach, just submitting it for consideration.

Regards,
John

-----Original Message-----
From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Scott Palmer
Sent: Monday, July 15, 2013 3:03 PM
To: Richard Bair
Cc: openjfx-dev at openjdk.java.net
Subject: Re: MSAA and Scene anti aliasing

I would vote for option b)
Use a full class that can be extended later as needed.  You don't have to use it like an enum. It could be a container for configuration parameters, possibly including the enum that says the antialiasing mode, but with separate fields (or maybe even just a single map) to supply the additional details e.g. x2, x4, x16.
I also find that mixing the kind of antialiasing with the parameters in a single enum is smellier than keeping those things distinct, but I don't like methods with a lot of parameters either.  You could supply simple static fields or methods to get a class configured for the common cases so it could be used as easily as an enum.

Scott

On 2013-07-15, at 4:45 PM, Richard Bair <richard.bair 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…
> 
> 
> I agree it should be nice and simple. It should also allow us the freedom to make it better in the future. I think that adding a secondary property to refine what is meant by the first property is not a good idea for the following reason. As our API stands today it is not possible to later add any API without cluttering things up. Specifically this is because we require you to specify anti-aliasing at the time the scene is constructed. Ostensibly this is because it is easier for our implementation. I think this is wrong (and the fact that we expose a read only property for anti-aliasing is going to come back to bite us if we ever attempt to make it a read-write property). But suppose we decide that no, it really should be read-only for all time. In that case, in 8.1 we decide to add more API that lets you specify various details about the implementation, such as the algorithm to use. Now we have to add yet another constructor with yet more parameters to be able to specify this additional constraint.
> 
> This is bad.
> 
> What we can do is either of the following:
>    a) Make anti-aliasing a full read-write property and get it out of the constructor
>    b) Change it to an enum (or class) so we can grow it over time
> 
> Making it a read-write property (a) would at least allow us to add another read-write property in the future (which is inevitable) without adding more and more constructors. Once upon a time the root node of a Scene was immutable and thus we had to have a non-empty scene constructor. That is no longer the case and we should be striving to make Scene something that could be completely configured dynamically (after all, we should be able to detach and chuck the peer and create a new one on demand -- if we can't, that's a failing in our implementation, not in the API). As such, it really is a bad idea for us to be adding new read-only properties here.
> 
> Separate from that discussion is the one around whether it should be a boolean or an enum. I think a boolean is short-sighted because it is inevitable that we are going to need to expose additional choices to developers. So that means we will, at a minimum, need two properties instead of one to configure the antialiasing strategy. It isn't the end of the world. Using a full class to define the AA approach is also possible (if null, no AA, otherwise it is an implementation of SceneAntiAliasing which could be MSAA or whatever, package private constructor, fixed set of types, various properties can grow on those different types over time, etc). Using a full class probably provides the most flexibility but is more cumbersome. Using an enum is just as easy programatically as a boolean, offers the opportunity to grow it over time, but isn't as flexible as using a class.
> 
> Once we ship this API we have to live with it forever, and I have a very strong feeling that we are going to be modifying this in the future, because as it stands it isn't that useful (only in the short term).
> 
> I think making this a read-write property now is a must-do, because you can't change it later (at least, you can't change the property method to return a full property, it has to remain a read-only property forever for binary compatibility reasons).
> 
>> 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.
> 
> We don't have to do anything prematurely. An enum with two options is perfectly acceptable in the first go-around. The question is, how are we going to handle growing this API in the future. Two properties in this case is uglier than one.
> 
> Richard