Re: API Change Proposal - Re: MSAA and Scene anti aliasing
Hi All,
Need to revive this thread, to remind everyone that anti-aliasing API change is
going in. And should be available in build b112.
See bug report for some further detail/discussion:
https://javafx-jira.kenai.com/browse/RT-31878
Initially only available anti-aliasing modes are BALANCED and DISABLED, as per
decision by Kevin and Richard. FASTEST and NICEST should come later.
The new class SceneAntialiasing should resembled below:
/**
* The JavaFX {@code SceneAntialiasing} class specifies the level of
* anti-aliasing desired. Scene anti-aliasing is primarily used when rendering
* 3D primitives, which are otherwise rendered aliased.
* p
* Note: In order for {@code SceneAntialiasing} to have an affect, the
underlying
* system must support:
* {@link javafx.application.ConditionalFeature#SCENE3D
ConditionalFeature.SCENE3D}
* and anti-aliasing.
* /p
* @since JavaFX 8.0
*/
public final class SceneAntialiasing {
/**
* Disables anti-aliasing
*/
public static final SceneAntialiasing DISABLED = new
SceneAntialiasing(DISABLED);
/**
* Enables anti-aliasing optimizing for a balance of quality and performance
*/
public static final SceneAntialiasing BALANCED = new
SceneAntialiasing(BALANCED);
...
private SceneAntialiasing(String value) { val = value; }
}
Note this is a potential breaking change, and the following constructors will
change!
Constructors remove:
public Scene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
-Thor
On Jul 24, 2013, at 2:37 PM, Chien Yang wrote:
Thank you for the feedback! We decided to drop DEFAULT in favor of BALANCED.
So here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system setting available
that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available
that results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic. After
listening to the feedback and an internal discussion, we would like to
propose a minor change to the API for supporting scene anti-aliasing. We
intentionally choose not to expose the number of samples and techniques used
in this release, but this doesn't preclude future addition when the time is
right for more options. This change will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics
driver has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting
available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available
that results in best visual quality
}
Thanks,
- Chien
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
I agree, however I would prefer a single class over subclasses if
possible. I have added Jim's proposal to the JIRA for consideration.
https://javafx-jira.kenai.com/browse/RT-31878
Thanks,
- Chien
On 7/31/2013 3:21 PM, Kevin Rushforth wrote:
This seems cleaner in terms of extensibility. I think we can wait on
adding anything other than the public static finals for this release,
but plan to extend it using something like what Jim suggests.
-- Kevin
Richard Bair wrote:
Personally I liked this approach. It was like an enum in ease of use
but much more extensible in the future when we add more anti-aliasing
types and twiddles.
Richard
On Jul 31, 2013, at 1:36 PM, Jim Graham james.gra...@oracle.com wrote:
D'oh! I knew I should have been checking this list a bit. I hope
this isn't too late to have any impact...
As an intermediate solution this is fine, but when we want to get
into providing settings for MSAA and FSAA and other algorithms I
think classes are more flexible than enums. How about this solution:
package javafx.?
public class SceneAntialiasing {
public static final SceneAntialiasing DISABLED;
public static final SceneAntialiasing BALANCED;
public static final SceneAntialiasing FASTEST;
public static final SceneAntialiasing NICEST;
public static SceneAntialiasing[] getAvailableTechniques() { }
SceneAntialiasing() { /* package private constructor! */ }
}
public class MsaaAntialiasing extends SceneAntialiasing {
MSaaAntialiasing(int numsamp) { /* package private */ }
public int getNumSamples();
}
public class FsaaAntialiasing extends SceneAntialiasing {
FsaaAntialiasing(int numsamp) { /* package private */ }
public int getNumSamples();
}
Note that there are ways for the system to construct these objects
without providing public constructors so that these become
statically defined by the system.
What about Anisotropic filtering? Is that considered a form of AA,
or an option on top of AA?
...jim
On 7/24/2013 3:07 PM, Chien Yang wrote:
Thanks for the help! I was of 2 minds about it; alphabetical or
logical.
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
BALANCED, // enables anti-aliasing using optimal system setting
available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available that results in best visual quality
}
- Chien
On 7/24/2013 2:49 PM, Richard Bair wrote:
Just to be picky, I would put DISABLED first in the list. It seems
more consistent to have the only OFF mode to be first and then all
the rest of the options (which happen to then have ordinals 0)
will be some form of ON mode.
Richard
On Jul 24, 2013, at 2:37 PM, Chien Yang chien.y...@oracle.com
wrote:
Thank you for the feedback! We decided to drop DEFAULT in favor
of BALANCED. So here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system
setting available that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available that results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this
topic. After listening to the feedback and an internal
discussion, we would like to propose a minor change to the API
for supporting scene anti-aliasing. We intentionally choose not
to expose the number of samples and techniques used in this
release, but this doesn't preclude future addition when the time
is right for more options. This change will be tracked by
RT-31878 (https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height,
boolean depthBuffer, boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height,
boolean depthBuffer, SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying
graphics driver has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at
the moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system
setting available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system
setting available that results in better frame rate
NICEST
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
I'm pretty confident we'll want different sub-types as we go along (CSAA, MSAA,
FXAA -- there are a lot of different ways to do full-scene anti-aliasing and I
bet that they will have different parameters for controlling their various
algorithms), but we can cross that bridge later.
Richard
On Jul 31, 2013, at 4:36 PM, Chien Yang chien.y...@oracle.com wrote:
I agree, however I would prefer a single class over subclasses if possible. I
have added Jim's proposal to the JIRA for consideration.
https://javafx-jira.kenai.com/browse/RT-31878
Thanks,
- Chien
On 7/31/2013 3:21 PM, Kevin Rushforth wrote:
This seems cleaner in terms of extensibility. I think we can wait on adding
anything other than the public static finals for this release, but plan to
extend it using something like what Jim suggests.
-- Kevin
Richard Bair wrote:
Personally I liked this approach. It was like an enum in ease of use but
much more extensible in the future when we add more anti-aliasing types and
twiddles.
Richard
On Jul 31, 2013, at 1:36 PM, Jim Graham james.gra...@oracle.com wrote:
D'oh! I knew I should have been checking this list a bit. I hope this
isn't too late to have any impact...
As an intermediate solution this is fine, but when we want to get into
providing settings for MSAA and FSAA and other algorithms I think classes
are more flexible than enums. How about this solution:
package javafx.?
public class SceneAntialiasing {
public static final SceneAntialiasing DISABLED;
public static final SceneAntialiasing BALANCED;
public static final SceneAntialiasing FASTEST;
public static final SceneAntialiasing NICEST;
public static SceneAntialiasing[] getAvailableTechniques() { }
SceneAntialiasing() { /* package private constructor! */ }
}
public class MsaaAntialiasing extends SceneAntialiasing {
MSaaAntialiasing(int numsamp) { /* package private */ }
public int getNumSamples();
}
public class FsaaAntialiasing extends SceneAntialiasing {
FsaaAntialiasing(int numsamp) { /* package private */ }
public int getNumSamples();
}
Note that there are ways for the system to construct these objects without
providing public constructors so that these become statically defined by
the system.
What about Anisotropic filtering? Is that considered a form of AA, or an
option on top of AA?
...jim
On 7/24/2013 3:07 PM, Chien Yang wrote:
Thanks for the help! I was of 2 minds about it; alphabetical or logical.
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
BALANCED, // enables anti-aliasing using optimal system setting
available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available
that results in best visual quality
}
- Chien
On 7/24/2013 2:49 PM, Richard Bair wrote:
Just to be picky, I would put DISABLED first in the list. It seems more
consistent to have the only OFF mode to be first and then all the rest
of the options (which happen to then have ordinals 0) will be some
form of ON mode.
Richard
On Jul 24, 2013, at 2:37 PM, Chien Yang chien.y...@oracle.com wrote:
Thank you for the feedback! We decided to drop DEFAULT in favor of
BALANCED. So here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system setting
available that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available that results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic.
After listening to the feedback and an internal discussion, we would
like to propose a minor change to the API for supporting scene
anti-aliasing. We intentionally choose not to expose the number of
samples and techniques used in this release, but this doesn't preclude
future addition when the time is right for more options. This change
will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
Sorry let me be clear. Having a class vs an enum was my preferred approach and
I'm glad with Jim's nudge it looks like we'll go there. Having just the few
predefined constants as a starting point I think is good, and we can add
sub-types and more goodness in the future.
Richard
On Jul 31, 2013, at 4:47 PM, Richard Bair richard.b...@oracle.com wrote:
I'm pretty confident we'll want different sub-types as we go along (CSAA,
MSAA, FXAA -- there are a lot of different ways to do full-scene
anti-aliasing and I bet that they will have different parameters for
controlling their various algorithms), but we can cross that bridge later.
Richard
On Jul 31, 2013, at 4:36 PM, Chien Yang chien.y...@oracle.com wrote:
I agree, however I would prefer a single class over subclasses if possible.
I have added Jim's proposal to the JIRA for consideration.
https://javafx-jira.kenai.com/browse/RT-31878
Thanks,
- Chien
On 7/31/2013 3:21 PM, Kevin Rushforth wrote:
This seems cleaner in terms of extensibility. I think we can wait on adding
anything other than the public static finals for this release, but plan to
extend it using something like what Jim suggests.
-- Kevin
Richard Bair wrote:
Personally I liked this approach. It was like an enum in ease of use but
much more extensible in the future when we add more anti-aliasing types
and twiddles.
Richard
On Jul 31, 2013, at 1:36 PM, Jim Graham james.gra...@oracle.com wrote:
D'oh! I knew I should have been checking this list a bit. I hope this
isn't too late to have any impact...
As an intermediate solution this is fine, but when we want to get into
providing settings for MSAA and FSAA and other algorithms I think classes
are more flexible than enums. How about this solution:
package javafx.?
public class SceneAntialiasing {
public static final SceneAntialiasing DISABLED;
public static final SceneAntialiasing BALANCED;
public static final SceneAntialiasing FASTEST;
public static final SceneAntialiasing NICEST;
public static SceneAntialiasing[] getAvailableTechniques() { }
SceneAntialiasing() { /* package private constructor! */ }
}
public class MsaaAntialiasing extends SceneAntialiasing {
MSaaAntialiasing(int numsamp) { /* package private */ }
public int getNumSamples();
}
public class FsaaAntialiasing extends SceneAntialiasing {
FsaaAntialiasing(int numsamp) { /* package private */ }
public int getNumSamples();
}
Note that there are ways for the system to construct these objects
without providing public constructors so that these become statically
defined by the system.
What about Anisotropic filtering? Is that considered a form of AA, or an
option on top of AA?
...jim
On 7/24/2013 3:07 PM, Chien Yang wrote:
Thanks for the help! I was of 2 minds about it; alphabetical or logical.
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
BALANCED, // enables anti-aliasing using optimal system setting
available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available
that results in best visual quality
}
- Chien
On 7/24/2013 2:49 PM, Richard Bair wrote:
Just to be picky, I would put DISABLED first in the list. It seems more
consistent to have the only OFF mode to be first and then all the rest
of the options (which happen to then have ordinals 0) will be some
form of ON mode.
Richard
On Jul 24, 2013, at 2:37 PM, Chien Yang chien.y...@oracle.com wrote:
Thank you for the feedback! We decided to drop DEFAULT in favor of
BALANCED. So here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system setting
available that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available that results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic.
After listening to the feedback and an internal discussion, we would
like to propose a minor change to the API for supporting scene
anti-aliasing. We intentionally choose not to expose the number of
samples and techniques used in this release, but this doesn't
preclude future addition when the time is right for more options.
This change will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
public SubScene(Parent root,
Re: Fwd: API Change Proposal - Re: MSAA and Scene anti aliasing
Hi Scott,
This isn't in the plan for JavaFX 8. I'm not sure how feasible it
is to access this information from different GPU vendors and across
platforms (desktop and embedded).
- Chien
On 7/23/2013 6:33 PM, Scott Palmer wrote:
copying the list...
-- Forwarded message --
From: Scott Palmer swpal...@gmail.com
Date: Tue, Jul 23, 2013 at 9:33 PM
Subject: Re: API Change Proposal - Re: MSAA and Scene anti aliasing
To: Chien Yang chien.y...@oracle.com
Is DEFAULT intended to defer to the settings in the system graphics drivers
(e.g. nVidia control panel) such that the precise settings used are defined
outside the scope of JavaFX and could vary between otherwise identical
systems based on the settings the user has selected somewhere else?
If so perhaps something like SYSTEM, USER, or UNSPECIFIED ,make sense.
On Tue, Jul 23, 2013 at 9:14 PM, Chien Yang chien.y...@oracle.com wrote:
Well, I personally think that might be over stretching. :-) FAST and
NICEST will behave no difference on a platform that can't support AA. For
such platform we will have to cover in the API specification.
- Chien
On 7/23/2013 2:37 PM, Richard Bair wrote:
Actually that is exactly what I was hoping DEFAULT would mean -- some
kind of typical option for the particular platform (maybe even disabled on
some!).
Richard
On Jul 23, 2013, at 1:41 PM, Felix Bembrick felix.bembr...@gmail.com
wrote:
I am not sure I like the name of the value DEFAULT. To me default
implies some kind of typical option for the particular platform which
could conceivably be very different on each platform. For example, on my
Windows super-computer with ultra fast GPU the default would logically
be
something like 16x whereas on my iPhone I would expect the default to be
using only 2x. The comment for DEFAULT implies that it's really more of
a
BALANCED or MODERATE setting that would have the same characteristics on
each platform.
On 24 July 2013 06:29, Chien Yang chien.y...@oracle.com wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic.
After listening to the feedback and an internal discussion, we would
like
to propose a minor change to the API for supporting scene
anti-aliasing. We
intentionally choose not to expose the number of samples and techniques
used in this release, but this doesn't preclude future addition when the
time is right for more options. This change will be tracked by RT-31878
(
https://javafx-jira.kenai.com/browse/RT-31878https://**
javafx-jira.kenai.com/browse/**RT-31878https://javafx-jira.kenai.com/browse/RT-31878
):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics
driver has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the
moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting
available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available
that results in best visual quality
}
Thanks,
- Chien
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
Thank you for the feedback! We decided to drop DEFAULT in favor of
BALANCED. So here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system setting
available that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available that results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic.
After listening to the feedback and an internal discussion, we would
like to propose a minor change to the API for supporting scene
anti-aliasing. We intentionally choose not to expose the number of
samples and techniques used in this release, but this doesn't preclude
future addition when the time is right for more options. This change
will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics
driver has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the
moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting
available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available that results in best visual quality
}
Thanks,
- Chien
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
Thanks for the help! I was of 2 minds about it; alphabetical or logical.
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
BALANCED, // enables anti-aliasing using optimal system setting available
that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
- Chien
On 7/24/2013 2:49 PM, Richard Bair wrote:
Just to be picky, I would put DISABLED first in the list. It seems more consistent
to have the only OFF mode to be first and then all the rest of the options (which
happen to then have ordinals 0) will be some form of ON mode.
Richard
On Jul 24, 2013, at 2:37 PM, Chien Yang chien.y...@oracle.com wrote:
Thank you for the feedback! We decided to drop DEFAULT in favor of BALANCED. So
here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system setting available
that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic. After
listening to the feedback and an internal discussion, we would like to propose
a minor change to the API for supporting scene anti-aliasing. We intentionally
choose not to expose the number of samples and techniques used in this release,
but this doesn't preclude future addition when the time is right for more
options. This change will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics driver
has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting available
that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
Thanks,
- Chien
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
+1 on having DISABLED be first.
-- Kevin
Richard Bair wrote:
Just to be picky, I would put DISABLED first in the list. It seems more consistent
to have the only OFF mode to be first and then all the rest of the options (which
happen to then have ordinals 0) will be some form of ON mode.
Richard
On Jul 24, 2013, at 2:37 PM, Chien Yang chien.y...@oracle.com wrote:
Thank you for the feedback! We decided to drop DEFAULT in favor of BALANCED. So
here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system setting available
that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic. After
listening to the feedback and an internal discussion, we would like to propose
a minor change to the API for supporting scene anti-aliasing. We intentionally
choose not to expose the number of samples and techniques used in this release,
but this doesn't preclude future addition when the time is right for more
options. This change will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics driver
has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting available
that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
Thanks,
- Chien
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
I am not sure I like the name of the value DEFAULT. To me default
implies some kind of typical option for the particular platform which
could conceivably be very different on each platform. For example, on my
Windows super-computer with ultra fast GPU the default would logically be
something like 16x whereas on my iPhone I would expect the default to be
using only 2x. The comment for DEFAULT implies that it's really more of a
BALANCED or MODERATE setting that would have the same characteristics on
each platform.
On 24 July 2013 06:29, Chien Yang chien.y...@oracle.com wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic.
After listening to the feedback and an internal discussion, we would like
to propose a minor change to the API for supporting scene anti-aliasing. We
intentionally choose not to expose the number of samples and techniques
used in this release, but this doesn't preclude future addition when the
time is right for more options. This change will be tracked by RT-31878 (
https://javafx-jira.kenai.**com/browse/RT-31878https://javafx-jira.kenai.com/browse/RT-31878
):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics
driver has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the
moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting
available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available
that results in best visual quality
}
Thanks,
- Chien
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
We are way past the feature freeze date for this release. The objective
now is to ensure the API is clean and doesn't preclude future options.
Currently MSAA is the only supported technique and specifying the number
of samples will require additional API which we aren't ready to commit.
- Chien
On 7/23/2013 2:04 PM, Felix Bembrick wrote:
Exactly.
I think we need to come up with a word that implies that it's really a
balance of quality and speed. That's why I suggested BALANCED but I am
hoping we can do even better than that.
As an aside, why did you decide to not expose the setting of either
the AA type or number of samples? I would have though that serious
graphics developers would really like to have such options available
to them.
On 24 July 2013 06:58, Chien Yang chien.y...@oracle.com
mailto:chien.y...@oracle.com wrote:
Yes, very good point, we struggled with the DEFAULT value too. It
doesn't really convey the in between value of FAST and NICEST.
- Chien
On 7/23/2013 1:41 PM, Felix Bembrick wrote:
I am not sure I like the name of the value DEFAULT. To me
default implies some kind of typical option for the
particular platform which could conceivably be very different on
each platform. For example, on my Windows super-computer with
ultra fast GPU the default would logically be something like
16x whereas on my iPhone I would expect the default to be using
only 2x. The comment for DEFAULT implies that it's really more
of a BALANCED or MODERATE setting that would have the same
characteristics on each platform.
On 24 July 2013 06:29, Chien Yang chien.y...@oracle.com
mailto:chien.y...@oracle.com wrote:
Hi all,
We appreciate all the feedback you have contributed to
this topic. After listening to the feedback and an internal
discussion, we would like to propose a minor change to the
API for supporting scene anti-aliasing. We intentionally
choose not to expose the number of samples and techniques
used in this release, but this doesn't preclude future
addition when the time is right for more options. This change
will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height,
boolean depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height,
boolean depthBuffer, boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height,
boolean depthBuffer, SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height,
boolean depthBuffer, SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying
graphics driver has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries
at the moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system
setting available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system
setting available that results in better frame rate
NICEST // enables anti-aliasing using maximum system
setting available that results in best visual quality
}
Thanks,
- Chien
Re: MSAA and Scene anti aliasing
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
Re: MSAA and Scene anti aliasing
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
Re: MSAA and Scene anti aliasing
+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
Re: MSAA and Scene anti aliasing
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
Re: MSAA and Scene anti aliasing
The problem is that once we commit to an API we can't change it later. And the simple and nice API of today can become the clumsy API of tomorrow. If you are fairly sure you never expose any other antiAliasing type, then keep the API we have. Otherwise use a enum instead of a boolean (and I don't think the API will be any less nice or simple because of it). Adding a antialiasing type property later is possible but I would try to avoid it possible. Felipe On Jul 15, 2013, at 1:12 PM, Chien Yang wrote: +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
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.b...@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
RE: MSAA and Scene anti aliasing
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-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Scott Palmer Sent: Monday, July 15, 2013 3:03 PM To: Richard Bair Cc: openjfx-dev@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.b...@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
Re: MSAA and Scene anti aliasing
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:
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
Re: MSAA and Scene anti aliasing
What if the type of AA is not MSAA?
How about having one method to select the type of AA (i.e. through an
enum) and another to set the additional properties (such as number of
samples).
Alternatively you could have just a single method
(configureAntialiasing()?) that did both...
- Original Message -
From: Kevin Rushforth
To:Gerrit Grunwald
Cc:openjfx-dev@openjdk.java.net Mailing
Sent:Sat, 13 Jul 2013 12:00:42 -0700
Subject:Re: MSAA and Scene anti aliasing
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 :
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
Re: MSAA and Scene anti aliasing
Hi Richard,
Yes, I agree an enum is probably better than a boolean for
controlling the visual quality of a rendered scene. As a matter of fact
we did explore using enum is earlier 3d discussions but decided to go
with boolean due to concerns of complexity we aren't ready to handle for
JavaFX 8.0. There is quite a few anti-aliasing techniques and MSAA is
just one that is easy to implement at the moment. The number of samples
can range from 0 to 16 (or more in the future) and max samples is device
dependence. If we were to put this detail information/control into an
enum, it can turn ugly pretty fast. Also what if the selected technique
or number of samples is not support on the device? We will probably have
to provide some query mechanisms too.
The other approach, that may be doable for this release, is to let user
tell us what is preferred, and we will pick the level the device is
capable of supporting:
public enum SceneAntiAliasing {
DISABLED, // prefer performance over quality
DEFAULT, // Help me to decide
NICE, // good mix of performance and quality
NICEST // prefer quality over performance
}
What do you think?
- Chien
On 7/12/13 10:55 AM, Richard Bair wrote:
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
Re: MSAA and Scene anti aliasing
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
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:
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
Re: MSAA and Scene anti aliasing
+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:
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
Re: MSAA and Scene anti aliasing
totally agree on this, if I could clone myself we would have FXAA shaders :P
-J
On 7/12/2013 10:55 AM, Richard Bair wrote:
public enum SceneAntiAliasing {
DISABLED,
DEFAULT,
MSAA_2X,
MSAA_4X
}
