Re: JavaFX 8 Progress
Hi Mark, I know it is not necessarily helpful to post comments along the lines of this aint working without suggesting viable alternatives but given that I am not privy to Oracle's strategic plans for Web Start or Java in the browser and not privy to the internal technological limitations of such functionality I can only highlight the situation as perceived by the end user and also by the developer. I think it's true that most commercial developers of Java/JavaFX applications will probably want to deploy their software as native bundles or through an app store in preference to Web Start. This may be because their are security issues with Web Start apps that don't effect locally deployed apps and also because of the other issues with Web Start that I referred to. Also, there are some limitations with Web Start in terms of versioning such as: 1. What if I want to install a specific version? 2. What if I *don't* want to install the version currently offered through the Web Start link because it is not compatible with my system configuration or with other software? 3. How do I roll-back to a previous version if I want to? Your comments on corporate deployment are spot on though. However, there are other options for updating software that do not require Web Start. Indeed, many applications *not* written in Java are able to update themselves through a Check for updates menu option or similar. Surely Java/JavaFX applications could be updated in the same way? I recall there was a discussion on this list earlier this year on this very subject with links to 3rd-party auto-updating mechanisms and discussions on Oracle's own plans in ths area. If such a mechanism is developed then *all* JavaFX applications could make use of it and then what would be the need for Web Start? Corporations utilise thousands of applications not written in Java that have the ability to update themselves so why not Java/JavaFX applications too? Cheers, -jct - Original Message - From: Mark Fortner To:Daniel Zwolenski Cc:mike.ehrenb...@barchart.com Ehrenberg , openjfx-dev@openjdk.java.net , JeremyJongsma Sent:Thu, 18 Jul 2013 14:30:16 -0700 Subject:Re: JavaFX 8 Progress I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
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
