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
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
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
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,
--
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
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, //
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
+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.
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
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.
-
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
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
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
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
, 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
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)
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
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
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
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
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
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,
+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
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
}
24 matches
Mail list logo
