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
+1
Constants good enough for now. First pass doesn't really need
subclasses since the 4 constants we start with are virtual and somewhat
opaque, but we could put them in for grins if we want.
But, when we start making the different AA types selectable and
parameterized then I think we want
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
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
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 th
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
Also, the MSAA subclass might have:
public SampleMethod getSampleMethod(); // point, area, ?centroid?
public SamplePattern getSamplePattern(); // regular, sparse, stochastic
Also, static MsaaAA.get(params) returns the indicated object if there is
an implementation that supports those parameter
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 wrote:
> D'oh! I knew I should have been checking this list a bit. I hope this isn't
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
+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.
R
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
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 wrote:
> Thank y
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, // dis
ed message --
From: Scott Palmer
Date: Tue, Jul 23, 2013 at 9:33 PM
Subject: Re: API Change Proposal - Re: MSAA and Scene anti aliasing
To: Chien Yang
Is DEFAULT intended to defer to the settings in the system graphics drivers
(e.g. nVidia control panel) such that the precise settings used a
copying the list...
-- Forwarded message --
From: Scott Palmer
Date: Tue, Jul 23, 2013 at 9:33 PM
Subject: Re: API Change Proposal - Re: MSAA and Scene anti aliasing
To: Chien Yang
Is DEFAULT intended to defer to the settings in the system graphics drivers
(e.g. nVidia control
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 h
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.
- Chie
Yes, that's what the word "default" implies but clearly the DEFAULT in the
suggested enum does not mean that at all.
On 24 July 2013 07:37, Richard Bair wrote:
> Actually that is exactly what I was hoping DEFAULT would mean -- some kind
> of typical option for the particular platform (maybe eve
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 wrote:
> I am not sure I like the name of the value DEFAULT. To me "default"
> implies s
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 th
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 w
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
somethin
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 tec
ot 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@openj
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)
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 d
> 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
+1. Well said.
- Chien
Sent from my mobile phone. Please excuse my brevity.
On Jul 15, 2013, at 12:19 PM, Thor Johannesson
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
>
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,
boolea
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 re
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
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
Yea but there are multiple ways to implement anti aliasing besides msaa and a
read only attribute implies all we will ever do is msaa.
Perhaps having number of samples in the enum isn't right still. Or having it
return a sensible value if we ever implement AA techniques that don't have this
set
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
Jav
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 M
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
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
}
+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
38 matches
Mail list logo
