iOS gradle script doesn't work anymore
Hi, When I try to build OpenJFX for iOS the following error occurs: * Where: Build file '/Applications/Developer/Java/open-jfx-bitbucket/openjfx-8-graphics-rt/build.gradle' line: 460 * What went wrong: A problem occurred evaluating script. Error: missing tool packages: [ios-libs-05.tgz] What’s happen? Best regards, Tobi
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: Making Color Final (and Paint too, for all intents and purposes)
+1
In practice I agree with Richard that this should not cause any issues
for applications.
-- Kevin
David Ray wrote:
+1
David
Sent from my iPhone
On Jul 12, 2013, at 3:15 PM, Richard Bair richard.b...@oracle.com wrote:
I have two different changes I might want to make, both of which are definitely incompatible for subclasses, but are otherwise source compatible.
public abstract class Paint {
Paint() { } // --- Add this package constructor. Anybody who subclassed
Paint will die
}
public final class Color extends Paint { … } // Added final
Nobody can do anything useful today by subclassing Paint. Each Paint subclass
has hardcoded support in the graphics pipeline. If you were to subclass Paint
with WackyPaint and use it in the scene graph, it would do absolutely nothing
(except maybe explode in the graphics pipeline someplace). Likewise, if you
extend Color with WackyColor, it will only be used as a Color object.
Color however does have non-final methods (blast!) which somebody could
override. Now, they could do nefarious things with it (as far as the graphics
pipeline is concerned), but other than logging when somebody called a method,
there is nothing else they could do by overriding (since Color is immutable),
except for the deriveColor method which could be reimplemented in a reasonable
manner, although the platform will never call your method so it doesn't do you
much good.
Both of these *should* have been final / effectively final when defined in the
first place, and we've made subclassing these classes sufficiently worthless by
other methods (other final methods plus the way the pipeline works) that nobody
should really be broken but such a change. Besides which, we added a new
abstract method in the last release which essentially breaks any subclasses in
a binary manner (they would have to update their code), and I'm about to do it
again while fixing https://javafx-jira.kenai.com/browse/RT-31565.
Anybody with major heartburn let me know now, 'cause its going down!
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
