Re: RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly

[Mike Hearn]

On Wed, 13 Oct 2021 23:59:40 GMT, Phil Race  wrote:

> On an external (non-retina) monitor JavaFX LCD text on macOS is painful on 
> the eyes.
> Retina diminishes it rather than cures it.
> 
> The problem is a mix of a couple of things
> 1) CoreText no longer generates LCD glyphs (except perhaps if you change some 
> system settings at your own risk)
> 2) Prism's LCD shader assumes it got LCD glyphs and makes sub-pixel 
> positioning adjustments that turn greyscale
> glyphs into multi-coloured glyphs that weren't meant to be ...
> 
> The fix here is to just disable LCD by default on macOS as is already done 
> (eg) on iOS
> This ripples through to make everything use grey scale even if you asked for 
> the LCD (which you can't have)
> It also means if you REALLY want it (and perhaps are tweaking those magical 
> settings) you can have it back
> by just specifying -Dprism.lcdtext=on
> 
> Also it means the pieces of support for this on macos are still there if 
> Apple ever bring it back (unlikely).
> Not that much code would be removed anyway .. a fair amount of it is needed 
> for Windows and Linux.

I can't comment on the JBS bug, but I'm not sure this is actually fixed. I 
upgraded to JavaFX 18 and the bug is still there. Setting `-Dprism.lcdtext=off` 
fixes it. I'm not sure why, because the change to do this by default seems 
simple enough.

-

PR: https://git.openjdk.java.net/jfx/pull/642

Re: Questions ad JavaScript in JavaFX' WebEngine

[Mike Hearn]

The WebKit binding code is some of the more complex code in JavaFX. Rather
than try to extend the script tag you could instead look at the code for
the  tag and the old support for Netscape-style plugins.

https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebCore/plugins

I've looked at this in the past to investigate embedding of arbitrary
JavaFX nodes into a web page. It doesn't look particularly unfeasible as
there's still a lot of old code lying around that used to do exactly that,
it's just not used much anymore. However wiring it up to the Java level
would require a fairly adventurous programmer with good knowledge of C++,
rendering engines and JavaFX internals.




On Mon, May 11, 2020 at 14:17:07, Rony G. Flatscher  wrote:

> On 09.05.2020 17:23, Kevin Rushforth wrote:
>
> WebEngine uses WebKit's JavaScriptCore as its JavaScript engine. The
> sources are in the jfx repo, along with the JavaFX-specific classes that
> implement the two-way Java <--> JavaScript bridge. Other than the public
> API docs for WebEngine, which you referred to in your message, there isn't
> any documentation of the interface.
>
> OK, thank you very much, this is reassuring! :)
>
> What sort of information are you looking for?
>
> Well, as event handlers and script tags in HTML have a type attribute that
> allows to denote script languages other than JavaScript, I am interested in
> evaluating what WebEngine/WebView allows for to support this with any of
> the Java script engines.
>
> ---rony
>
> On 5/8/2020 7:01 AM, Rony G. Flatscher wrote:
>
> Wondering which JavaScript engine gets referred to in WebEngine [1].
>
> In case it is currently (JavaFX 14) Nashorn [2], what happens after
> Nashorn gets removed from the next [3] version? In case it is WebKit's
> JavaScriptCore [4] where can one study the interface from WebEngine to it?
>
> ---rony
>
> [1] WebEngine:  class-use/WebEngine.html>
> [2] Nashorn: 
> [3] Nashorn removal from JDK 15: 
> [4] JavaScriptCore: 
>
>

Re: Remove JavaFX JPMS enforcement

[Mike Hearn]

Maybe openjfx.io needs more maintainers? I opened a PR against that repo
some days ago and it's not been looked at. The JavaFX docs are certainly a
weak point right now, given that the Java 8 era docs aren't really being
maintained, and aren't open source, and the main docsite isn't really
actively worked on either.



On Tue, Apr 21, 2020 at 03:04:10, Bruno Borges 
wrote:

> One thing I do miss in openjfx.io website in terms of documentation is
> the definition of a jmods file and the sdk.
>
> For new developers looking at the download page, it's really not simple to
> figure it out.
>
> On Mon, Apr 20, 2020, 15:55 Kevin Rushforth 
> wrote:
>
> As of JDK 9, there are a few places in JavaFX that assume the JavaFX
> modules are, in fact modules. While it would likely be technically possible
> to find them all, and make modifications that will allow running JavaFX
> either on the classpath or on the module path, I am not in favor of that. I
> think it would be a step backwards. For one thing, we would lose the
> encapsulation that the module system provides, and applications would be
> able to access internal packages without so much as a warning that it's not
> public API. Also it would increase the testing burden, since that would be
> one more mode in which it would need to be tested to ensure that it doesn't
> break.
>
> I tend to agree with those who say that this is mostly a documentation
> issue. I suppose it's also a bit of a tooling problem, since first class
> support for modules is still in progress in various IDEs and build tools
> (gradle, maven, etc). The support in the IDEs is pretty good now, and
> gradle 6.4 reportedly has full support for modules. Someone with more
> familiarity with Maven can comment about their module support.
>
> -- Kevin
>
> On 4/20/2020 10:31 AM, Michael Paus wrote:
>
> Oh I see. You are obviously not familiar with the fact that the JDK has a
> built-in test
> which checks whether the JavaFX graphics module is on the module path when
> you
> try to launch an application main class which is derived from the JavaFX
> Application class.
> If you try this and the graphics module is not on the module path the
> launch will fail
> with an error message. That's the only reason why JavaFX programs cannot
> be launched
> completely on the classpath and that's where all the trouble starts. If
> you circumvent this
> test with the trick, I have mentioned before, everything becomes nice and
> easy.
>
> So for me there are only two questions.
> 1. Is there any proof of a technical reason why JavaFX could not run
> correctly on the classpath?
> 2. If there is no such reason, then why do we torture all the newbies with
> the "intricacies" of the
> module system instead of just removing this barrier?
>
> As I said before, I have not found any such problem in all the time since
> JavaFX was separated
> from the JDK, so this test seems to be quite artificial to me but of
> course I may be wrong. That's
> why I asked here.
>
> Am 20.04.20 um 17:25 schrieb Ty Young:
>
> I'm a bit confused here. if you don't want JPMS then you should be able to
> run everything on the classpath like normal. Netbeans at least doesn't
> force modules wtih Maven. Or is reflection disabled on classpath as of Java
> 9 too unless you have a module-info?
>
> Michael
>
> Am 18.04.20 um 12:58 schrieb Ty Young:
>
> On 4/18/20 5:01 AM, Michael Paus wrote:
>
> Getting started with JavaFX is made overly complicated by the fact that
> the use of the
> module system is enforced by some code in the JDK. Especially for
> beginners, who just
> want to get some small program running, this is almost always a big source
> of frustration.
> It is not very good marketing for JavaFX to make these initial steps such
> a pain. If you
> need some evidence for this statement, then just follow JavaFX on
> Stackoverflow or similar
> sites (and also this mailing list). Almost every day you can read
> frustrated posts from
> helpless people who would just like to get some JavaFX project running but
> are failing
> because they get lost in the module system jungle.
>
> Speaking as a long time JavaFX user(literally since Java 8), I have mostly
> disagree that the JPMS is hurting JavaFX.
>
> That said, I don't think the frustration is misplaced. What you say is
> true(Netbeans mailing list is fill of JavaFX issues) and the end user is
> *NOT* to be blamed here.
>
> Rather, I think what's to blame is poor documentation, JavaFX requiring
> absurd runtime module VM arguments, and poor/buggy IDE support.
>
> Starting with documentation, JavaFX uses reflection for things like
> TableView(everyone's favorite) and CSS style sheets. While this may be
> obvious for people who are more experienced, those who are not may be very
> confused when they get an onslaught of error messages regarding reflection.
> Better documentation on what requires reflection, why, and how to enable it
> would be useful.
>
> Likewise, the notice about having to include 

Re: Remove JavaFX JPMS enforcement

[Mike Hearn]

Possibly - I posted this because, being ultimately still a product of the
Java group at Oracle, I'm sceptical JavaFX will become *less* dependent on
the module system when the trend has been to use it more.

So there are at least two usability problems:

1 - needing additional downloads and new JVM flags to use JavaFX as modules
rather than ordinary JARs

2 - needing to open packages to JavaFX so it can reflect over them (not a
problem if your app runs on the classpath, but can hit you the moment you
use a component that's been modularised)

The first one has a few workarounds/solutions but what I do is go with the
flow and prepare my own JDK using jlink, which has JavaFX baked in like it
did before. I use a variant on this script:

https://gist.github.com/mikehearn/b18842d45181ac150ec9e6d0b2bb1e24

The output is a JDK directory I can point my IDE at. It's seen as a normal
JDK, but like in Java 8 JavaFX is now fully baked in and available by
default. Because it's already on the module path no special JVM flags are
required.

Probably someone (me?) should upload JDKs for each platform that are "fully
baked" like this.

That leaves the second problem, for which there's no good solution with the
current JFX API. Dependency injectors fundamentally don't mix well with
JPMS. Using Lookup objects is a backwards compatible addition that would
remove part of the pain of using modules with JavaFX because you'd no
longer need to remember to add special incantations to a module-info.java to
enable reflection - incantations which might change between JFX versions as
reflection uses are added or changed.





On Mon, Apr 20, 2020 at 15:06:16, Michael Paus  wrote:

> This is deviating quite a bit from the original issue of this thread,
> isn't it?
>
> As a side note: MethodHandles are not supported by GraalVM native image
> and so this would probably collide with the attempts to get JavaFX running
> on Android/iOS.
>
> Am 20.04.20 um 11:28 schrieb Mike Hearn:
>
> With respect to reflection, it seems like the module system really wants
> you to use Lookup capabilities rather than "open" modules to reflection.
> That is, JFX could be changed to use
>
> var objects = FXMLLoader.load(MethodHandles.lookup(), new URL(""));
>
> The semantics of a Lookup are that it grants whoever holds the object the
> same access rights as whoever created it. Thus if an object creates a
> Lookup and gives it to a framework, that framework can access anything the
> object could itself access.
>
> The lookup object would then be used to do reflection rather than the
> classical reflection API. With this change the API would guide you to a
> form that always works, regardless of module configuration.
>
> Due to its nature as a GUI toolkit JFX often needs to reflect over user
> code. It may be worth considering a deeper upgrade in which a Lookup object
> is provided during application startup, and passed in to the framework e.g.
> the Application class. Lookup objects can be 'teleported' so JFX components
> that wish to work with user GUI code generically can then fetch a Lookup
> from a central place. However, this wouldn't allow overriding of access
> control (i.e. FXMLLoader that takes such a lookup and teleports it to the
> right class for access, wouldn't be able to access private fields, because
> the original place where the lookup was created also couldn't).
>
>

Re: Remove JavaFX JPMS enforcement

[Mike Hearn]

With respect to reflection, it seems like the module system really wants
you to use Lookup capabilities rather than "open" modules to reflection.
That is, JFX could be changed to use

var objects = FXMLLoader.load(MethodHandles.lookup(), new URL(""));

The semantics of a Lookup are that it grants whoever holds the object the
same access rights as whoever created it. Thus if an object creates a
Lookup and gives it to a framework, that framework can access anything the
object could itself access.

The lookup object would then be used to do reflection rather than the
classical reflection API. With this change the API would guide you to a
form that always works, regardless of module configuration.

Due to its nature as a GUI toolkit JFX often needs to reflect over user
code. It may be worth considering a deeper upgrade in which a Lookup object
is provided during application startup, and passed in to the framework e.g.
the Application class. Lookup objects can be 'teleported' so JFX components
that wish to work with user GUI code generically can then fetch a Lookup
from a central place. However, this wouldn't allow overriding of access
control (i.e. FXMLLoader that takes such a lookup and teleports it to the
right class for access, wouldn't be able to access private fields, because
the original place where the lookup was created also couldn't).

Re: [EXTERNAL] Explanation of different scaling factors anywhere?

[Mike Hearn]

I'm afraid I disagree. My eyesight isn't great and I like to zoom web apps
to sizes that most designers would consider wrong/bad/absurd, at least when
possible. How far I can go depends a lot on the app. Many modern desktop
apps feel far too dense and with fonts that are uncomfortably small for me.
I much prefer desktop/JavaFX apps for various reasons, but in this regard
the web wins - I can blow the sizes up nice and big, and things mostly just
work. Hence my interest in replicating this feature.

It's annoying because it feels like it's surely possible and even easy, but
that the knowledge of how to do it probably only exists in the heads of
five people. JavaFX can scale widgets to handle variable dpi, scale
transforms and other features. This one doesn't seem like a stretch. I'd
rather get an authoritative tip before diving into Glass to try and reverse
engineer it all from the code.




On Thu, Jan 30, 2020 at 16:59:54, Michael Paus  wrote:

> I am wondering whether this kind of scaling should actually be done on an
> application basis. On desktop computers this is normally achieved via some
> system setting of the monitor scaling. I think most people just want a
> consistent scaling across all applications and so there is just no need in
> general for an individual scaling. Just for very specific cases this may be
> useful, e.g., to scale the text size of an editor window in Eclipse where
> this can be done like in a browser via Cmd+/-. In a browser you only need
> this feature because web-sites are so inconsistent in their styling, which
> is normally not the case for desktop applications.
>
> Just my two €ent
>
> Am 30.01.20 um 17:29 schrieb Mike Hearn:
>
> Yes, a scale transform doesn't affect layout. That's the issue. Browser
> zoom scales fonts, images and widgets but in a way that affects layout
> bounds, not only render bounds.
>
> As far as I can tell there's no way to do a zoom or scale that affects
> layout bounds with the public JavaFX API. Exploring why not and what could
> work is how I ended up getting a bit lost in the weeds of all the different
> scale factors. It *feels* like one of them should be applicable if only it
> was public API. But I can't quite figure out which or how exactly it'd
> work. If nobody else has ever examined this task (it seems not) then I
> guess I can just compile my own JFX and experiment with forcing the
> different factors and ratios to see what happens. I'm not sure the results
> would be stable or portable though.
>
> On Tue, Jan 28, 2020 at 11:09:04, Tom Schindl 
> wrote:
>
> I think that can not work because layouts don't take the scale factor into
> account nor does stuff like ScrollView but i could be wrong.
>
> Tom
>
> On 27.01.20 17:29, David Grieve wrote:
>
> Wouldn't this just be a scale transform?
>
> -Original Message-
> From: openjfx-dev  On Behalf Of
> Mike Hearn
> Sent: Monday, January 27, 2020 11:00 AM
> To: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
>
> Hello,
>
> A feature I often miss when using non-web GUIs is support for browser
> style zooming. In JavaFX it is quite easy to specify all font sizes in
> terms of "ems", relative sizes ("largest") or percentages and then adjust
> the base font size on a root node inside key handlers. This works OK but
> doesn't do much for images or other controls, and of course most JavaFX GUI
> code specifies sizes in terms of pixels.
>
> There are various scaling factors applied to pixel sizes. There is the
> per-node scaling transform, but this doesn't affect layout so isn't
> comparable to what browsers do. There's a per-screen DPI, there's a
> "platform scale", there's a
> "render scale" and then there's a "ui scale". These seem related to
> hidpi/retina support and are all internal (for the purposes of this
> question I'm happy to modify JavaFX itself).
>
> Render scale seems to affect resolution without affecting positions or
> layout, so that's not quite what I want. UI scale sounds promising but
> isn't documented and I couldn't quite figure it out by reading the code,
> though I could just fiddle with it and see what happens.
>
> It feels like someone probably explored this before now. Is there a way to
> effectively expand the size of every node without altering the size of the
> containing viewport, to get browser-style layout affecting zoom? If not,
> has anyone explored the complexity of the modifications required?
>
> thanks,
> -mike
>
> --
> Tom Schindl, CTO
> BestSolution.at <http://bestsolution.at/> <http://bestsolution.at/> EDV
> Systemhaus GmbH Salurnerstrasse 15. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
>

Re: [EXTERNAL] Explanation of different scaling factors anywhere?

[Mike Hearn]

Yes, a scale transform doesn't affect layout. That's the issue. Browser
zoom scales fonts, images and widgets but in a way that affects layout
bounds, not only render bounds.

As far as I can tell there's no way to do a zoom or scale that affects
layout bounds with the public JavaFX API. Exploring why not and what could
work is how I ended up getting a bit lost in the weeds of all the different
scale factors. It *feels* like one of them should be applicable if only it
was public API. But I can't quite figure out which or how exactly it'd
work. If nobody else has ever examined this task (it seems not) then I
guess I can just compile my own JFX and experiment with forcing the
different factors and ratios to see what happens. I'm not sure the results
would be stable or portable though.




On Tue, Jan 28, 2020 at 11:09:04, Tom Schindl 
wrote:

> I think that can not work because layouts don't take the scale factor into
> account nor does stuff like ScrollView but i could be wrong.
>
> Tom
>
> On 27.01.20 17:29, David Grieve wrote:
>
> Wouldn't this just be a scale transform?
>
> -Original Message-
> From: openjfx-dev  On Behalf Of
> Mike Hearn
> Sent: Monday, January 27, 2020 11:00 AM
> To: openjfx-dev@openjdk.java.net
> Subject: [EXTERNAL] Explanation of different scaling factors anywhere?
>
> Hello,
>
> A feature I often miss when using non-web GUIs is support for browser
> style zooming. In JavaFX it is quite easy to specify all font sizes in
> terms of "ems", relative sizes ("largest") or percentages and then adjust
> the base font size on a root node inside key handlers. This works OK but
> doesn't do much for images or other controls, and of course most JavaFX GUI
> code specifies sizes in terms of pixels.
>
> There are various scaling factors applied to pixel sizes. There is the
> per-node scaling transform, but this doesn't affect layout so isn't
> comparable to what browsers do. There's a per-screen DPI, there's a
> "platform scale", there's a
> "render scale" and then there's a "ui scale". These seem related to
> hidpi/retina support and are all internal (for the purposes of this
> question I'm happy to modify JavaFX itself).
>
> Render scale seems to affect resolution without affecting positions or
> layout, so that's not quite what I want. UI scale sounds promising but
> isn't documented and I couldn't quite figure it out by reading the code,
> though I could just fiddle with it and see what happens.
>
> It feels like someone probably explored this before now. Is there a way to
> effectively expand the size of every node without altering the size of the
> containing viewport, to get browser-style layout affecting zoom? If not,
> has anyone explored the complexity of the modifications required?
>
> thanks,
> -mike
>
> --
> Tom Schindl, CTO
> BestSolution.at <http://bestsolution.at/> EDV Systemhaus GmbH
> Salurnerstrasse 15. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

Explanation of different scaling factors anywhere?

[Mike Hearn]

Hello,

A feature I often miss when using non-web GUIs is support for browser style
zooming. In JavaFX it is quite easy to specify all font sizes in terms of
"ems", relative sizes ("largest") or percentages and then adjust the base
font size on a root node inside key handlers. This works OK but doesn't do
much for images or other controls, and of course most JavaFX GUI code
specifies sizes in terms of pixels.

There are various scaling factors applied to pixel sizes. There is the
per-node scaling transform, but this doesn't affect layout so isn't
comparable to what browsers do. There's a per-screen DPI, there's a
"platform scale", there's a "render scale" and then there's a "ui scale".
These seem related to hidpi/retina support and are all internal (for the
purposes of this question I'm happy to modify JavaFX itself).

Render scale seems to affect resolution without affecting positions or
layout, so that's not quite what I want. UI scale sounds promising but
isn't documented and I couldn't quite figure it out by reading the code,
though I could just fiddle with it and see what happens.

It feels like someone probably explored this before now. Is there a way to
effectively expand the size of every node without altering the size of the
containing viewport, to get browser-style layout affecting  zoom?  If not,
has anyone explored the complexity of the modifications required?

thanks,
-mike

DropShadow effect kills gfx responsiveness OS-wide

[Mike Hearn]

I'm on macOS High Sierra with a very new and very high end MacBook Pro.

I have a pretty basic GUI that uses translucency fairly aggressively. I
added a DropShadow effect to some nodes, which looks great, but to my great
surprise this one line of code kills the UI performance not of my app, but
other apps on the same machine, specifically:

   - I can see the frame rate of the dock's zoom animation is lower
   - Chrome becomes nearly unusable. Opening a new tab goes from nearly
   instant to sluggish, this is very noticeable if you watch the tab in the
   tab strip itself expand. It goes from smooth and fast to being able to see
   the individual frames.

Stopping my app immediately restores the other apps to full framerate. So
presumably, the DropShadow shader is triggering some slow path not only in
JavaFX but the GPU or driver itself. I've experimenting with caching and
that speeds up scrolling of nodes with drop shadows in my own app, but the
OS-wide slowdown remains.

Has anyone seen anything like this before? I'm suspecting that I'll need to
render my own drop shadow effect using static bitmaps to work around it.

I don't have access to the OpenJDK bug tracker so I can't file a bug report
for this and I'm not sure how to reproduce it reliably. It's the first time
I noticed it.

Re: JavaFX 11 is released

[Mike Hearn]

Excellent work, congratulations to everyone involved and the new site is
wonderful.

Re: Is JavaFX going to truly be a community project?

[Mike Hearn]

I believe you're over-thinking this Pedro. A quote from Margaret Thatcher
springs to mind:

"They are casting their problems on society and who is society? There is no
> such thing! There are individual men and women and there are families and
> no government can do anything except through people and people look to
> themselves first."


Her point was that when someone says "the community should do this", that's
an abstraction - the community is nothing more than people, sometimes
individuals and sometimes organised into companies. Gluon and Oracle are
both clearly critical parts of the JavaFX community and that's a good
thing. I'm not sure why it would be off-putting. After all, JavaFX is based
on Java and the Java community is mostly made of companies too (Oracle, Red
Hat, Intel, Azul etc).

Perhaps the JavaFX community will get more organised with time - I believe
the "community-ness" feeling would be significantly enhanced with simple
things like a JavaFX website. Perhaps you can contribute such a thing, as
it would not involve core JavaFX hacking?

Re: Docs hosting for Java 11?

[Mike Hearn]

Thanks!

Re: Docs hosting for Java 11?

[Mike Hearn]

Well, I'm not thinking about my needs here - I've already learned the
framework. I'm more wondering how people will learn and get the tools for
JavaFX development in future. Up until Java 11 you could at least go to a
single website, click on fairly obvious links, end up at the Java 8 docs
for JavaFX and start learning. Post Java 11  where do users go? A wiki
page? That seems rather hard to find.

Given the Oracle has graciously open sourced so much of the Oracle JDK for
OpenJDK, I wonder if there's any chance of the docs being open sourced too
so they can be reformatted, refreshed and put onto a new website by the
community? It seems a shame to let them bit-rot.



On Fri, Aug 31, 2018 at 19:21:56, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> Ah, OK. As far as I know, the FX 8 non-API docs aren't going anywhere, but
> as you note they also aren't being updated.
>
> They are not under an open-source license. You would need to read the
> license to see what the terms of use are and whether that would meet your
> needs.
>
> -- Kevin
>
>
> On 8/31/2018 9:36 AM, Mike Hearn wrote:
>
> I was actually referring to all the docs that *aren't* JavaDocs, like the
> tutorials, the CSS reference, the getting started guides, interop guides
> etc.
>
> As far as I know they haven't been updated since Java 8, however the API
> is backwards compatible so they are still useful learning materials. I am
> also not sure if they're open source licensed though.
>
> It would be a huge pity and a big drag on adoption if the community had to
> effectively produce an all new set of non-API docs _from scratch_.
>
>

Re: Docs hosting for Java 11?

[Mike Hearn]

I was actually referring to all the docs that *aren't* JavaDocs, like the
tutorials, the CSS reference, the getting started guides, interop guides
etc.

As far as I know they haven't been updated since Java 8, however the API is
backwards compatible so they are still useful learning materials. I am also
not sure if they're open source licensed though.

It would be a huge pity and a big drag on adoption if the community had to
effectively produce an all new set of non-API docs _from scratch_.

Docs hosting for Java 11?

[Mike Hearn]

As JavaFX is being removed in Java 11, presumably the docs that come with
it won't be hosted by Oracle/openjdk.net  anymore.
And this is a problem because the way you get JavaFX and its tools will no
longer be obvious to newcomers, who won't have read this list or know that
it's on Maven.

Are there any plans to take the existing set of docs here:

https://docs.oracle.com/javase/8/javase-clienttechnologies.htm

which despite not being updated for a while are still fine, and moving them
to a new OpenJFX website somewhere? openjfx.org works but is sitting on a
domain park page, and javafx.org is owned but doesn't resolve or load.

Re: WebView and WebGL

[Mike Hearn]

>
> (And yes, the current JavaFX 3D features are extremely rudimentary and not
> particularly useful. I don't expect them to be ever enhanced. They're
> effectively "frozen". It's a harsh call but I think they were a mistake
> from day one. We need a completely different alternative).
>

I somewhat agree, but at the time - lacking something like ANGLE - there
was no alternative. And it's sufficient to be able to put a UI surface onto
a cube and spin it around, and other simple but effective animation
techniques. As macOS has showed you don't need a full blown 3D engine to
make good use of a GPU: just tasteful use of basic shapes, animations and
shader effects gets you a long way, and FX does support those.

Re: Update on FX plans for JDK 9

[Mike Hearn]

>
>   JDK-8091107: Add java.awt.Desktop support to javafx
>   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX (FX
> equivalent for JEP 272)
>

Exposing platform APIs is a big deal for anyone who wants to make an app
that really benefits from being on the desktop. Doing things like handling
files, registering URL handlers etc was a big PITA in my app. Definitely +1
to supporting these cases better.


>   JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer
> for non-applet Stage
>

It's unclear from this description or the bug what the benefit of doing
that would be. Performance?


>   JDK-8145154: Provide public API support for PerformanceTracker
> functionality
>   JDK-8090763: Public API for Glass's robot functionality
>

For testing and so on, public APIs seem lower priority to me. A developer
can always override Jigsaw from the command line and use whatever internal
APIs are needed. Breakage is less of a concern because it's under the
control of the developer.

The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a
slick auto update system. Shipping apps that can't update themselves in
2015 is unacceptable even for corporate deployments.

Re: Future of JavaFX

[Mike Hearn]

I'm pretty surprised by this thread.

Guys, JavaFX is a widget toolkit. That's it, that's all it is. GUIs haven't
changed that much in their general design and capabilities for decades now,
probably the last major 'innovations' being things like the MS Office
Ribbon.

JFX has all the capabilities I'd hope for in a widget toolkit, plus a lot
more. As a bonus it's open source and cross platform, with a full time team
of developers. Just take a moment to appreciate that for a second! What's
the competition? Qt and that's about it, right?

Software can always be better, but this hysteria over "zomg oracle is
abandoning us!" doesn't seem justified. Even if all Oracle did from now on
was fix bugs and keep it working as the underlying platforms evolve, OK,
it's an open source library with people paid to fix bugs. That's still
better than many of the open source libraries I depend on!

But they aren't just fixing bugs, they're also making enhancements. Yes,
Java 9 is going to be boring because Jigsaw is forcing Team FX to go pay
off some technical debt by making previously private-but-used APIs public.
OK, fine, that amounts to new features for all 3 of you that weren't
cheating previously ;)

Beyond that, the fact that "draggable tabs" is the most user visible
feature planned says to me what I already felt  - JavaFX is pretty mature.
It'd be nice if Scene Builder was being officially distributed again, and I
find the decision not do so baffling (perhaps they're assuming IDE makers
will take it off their hands), but the app is still out there and still
works. I suspect once the Jigsaw changes are finished off further
enhancements will be things like better performance, maybe some new
effects, etc. Nice to haves but not essentials.

IMO the biggest pain-point now isn't even GUI related stuff, it's the lack
of a modern replacement for Java Web Start. I made UpdateFX to try and fill
this hole but it's not as good as something that a skilled full time dev
with 6 months on hand would make.


On Sat, Dec 5, 2015 at 9:56 AM, Markus KARG  wrote:

> JavaFX support for multi-resolution images is really a killer feature, as
> it simply is ridiculous how small images render on HiDPI that are scaled
> for LowDPI.
>
> For JDK 10, I'd kindly ask to review the list of essentials that I sent
> you some months back by personal mail.
>
> -Markus
>
> -Original Message-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf
> Of Kevin Rushforth
> Sent: Mittwoch, 2. Dezember 2015 01:29
> To: openjfx-dev@openjdk.java.net
> Subject: Re: Future of JavaFX
>
> Just to chime in on a couple of points that have been raised in this
> discussion...
>
> * We are interested in working with the OpenJFX community to improve
> JavaFX. In particular: if you find a bug, file it (via bugs.java.com if
> you don't have a JBS account); if you want to contribute a patch to fix the
> bug, we'd love to review it; if you have an idea for an improvement, file
> it as an RFE (enhancement) and start up a thread on the mailing list.
> Larger features need a JEP, but smaller improvements do not.
>
> Please be aware that as part of the OpenJDK community, we are bound by the
> processes of the OpenJDK, including the need for a signed OCA in order to
> contribute, and before you can get a JBS account. If you are dissatisfied
> with those processes and policies, then I invite you to discuss it on the
> disc...@openjdk.java.net alias, and not here.
>
>
> * While we aren't planning a huge number of features in JDK 9, we are
> delivering some interesting improvements. Jigsaw is the big release driver
> and most of our effort on JavaFX is to align with that. For those of you
> who weren't at JavaOne, here is a list of things that are currently planned
> for JDK 9:
>
> - A modularized JavaFX (into 6 core modules + deploy, swing interop, swt
> interop)
>
> - JEP 253 -- Control Skins & additional CSS APIs (proper support for
> third-party controls)
>
> - High DPI enhancements (full support on Windows; add support for Linux)
>
> - Public API for commonly used methods from internal packages:
> * Nested Event Loop
> * Pulse Listener
> * Platform Startup
> * Text API (HitTest, etc)
> * Static utility functions (under investigation)
>
> - New versions of WebKit and GStreamer
>
> And here is an incomplete list of things we are thinking about for after
> JDK 9, possibly in an update release. In fact, the recently proposed JDK
> 9 slip [1] makes it possible to consider pulling a few of them into JDK 9,
> so let us know which ones you consider most important:
>
> - Provide a JavaFX equivalent for JEP 272 / AWT ‘Desktop’ API
>
> - Make UI Control Behaviors public
>
> - UI Control Actions API
>
> - Public Focus Traversal API
>
> - JavaFX support for multi-resolution images
>
> - Draggable tabs
>
> - Image IO
>
>
> -- Kevin
>
> [1]
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html
>
>
>

Re: Java & JavaFX on mobiles

[Mike Hearn]

Re: AOT.

At the JVMLS summit there was a talk on a HotSpot AOT compiler mode. It's
being worked on, however, as a commercial feature.

RoboVM provides an AOT compiler for iOS.

Re: Fwd: HostServices on Linux Ubuntu 14.04 trusty

[Mike Hearn]

I believe the issue it is has a hard-coded name of programs to invoke, and
that list isn't always accurate for every Linux host system.

On Sat, Sep 26, 2015 at 4:04 PM, John Maton  wrote:

> Stefan
> I confirm that works for me on all platforms, Windows/Mac/Ubuntu, thanks
> again
> (for the record HostServices does not work on Ubuntu 10.4).
> Regards,
> John Maton
>
> On Sat, Sep 26, 2015 at 11:48 AM, Stefan Fuchs  wrote:
>
> > Hi,
> >
> > this works for us on all platforms, including Ubuntu 14.04
> >
> >  // Desktop methods must be executed on the Swing Event Thread
> >  SwingUtilities.invokeLater(() -> {
> >  Desktop.getDesktop().open(pdfFile);
> > });
> >
> > Regards,
> >
> > Stefan
> >
> > To: Rahman USTA 
> >>
> >>
> >> My problem is getHostServices().showDocument does nothing at all in
> Ubuntu
> >> 10.4
> >>
> >> Have you tried using Desktop?
> >> as in
> >> if(Desktop.isDesktopSupported()) Desktop.getDesktop().open(docFile);
> >>
> >> That also works for me on Windows and Mac but causes a system crash in
> >> Ubuntu so I am no better off.
> >> Regards
> >> John Maton
> >>
> >>
> >> On Sat, Sep 26, 2015 at 11:08 AM, Rahman USTA  >
> >> wrote:
> >>
> >> I have similar issue. When using host services to show document in
> >>> directory services, in Linux environment it shows documents in Web
> >>> browser,
> >>> not in directory service.
> >>>
> >>> Thanks
> >>> 26 Eyl 2015 11:47 tarihinde "John Maton"  yazdı:
> >>>
> >>> Good morning all,
> >>>
>  I am using getHostServices().showDocument to display documents, such
> as
>  .pdf files.
>  This works find on all versions of Windows I have tested and on Apple
>  Macs,
>  but I have a test user running Linux Ubuntu 14.04 trusty where it does
>  not
>  work (does nothing).
>  Is there some library/resource which must be installed on Ubuntu to
> make
>  HostServices work?
>  thanks in advance for any comments,
>  John Maton
> 
> 
> >
>

Re: Blur effect on live scene?

[Mike Hearn]

That seems like a great summary Jim, thanks.

Re: Blur effect on live scene?

[Mike Hearn]

Yes, it can be done, and I have done this in my app. Take a look here:

https://github.com/vinumeris/lighthouse/blob/master/client/src/main/java/lighthouse/Main.java#L474

I do it by taking a snapshot, then blurring that, then cross-fading, then
replacing it with a live blur effect once done. I found this gave better
frame rates than the simpler way of just animating the blur property of a
blur effect, with very little visual degradation.

Be aware that this won't work well on software pipelines, so I use some
internal API to detect that and use a lighter weight effect instead.

You can download a binary of the app from
https://www.vinumeris.com/lighthouse if you want to see the effect in
action (press one of the buttons at the top to trigger it).

Re: Can we use JavaPackager and a get full JRE?

[Mike Hearn]

UpdateFX has code that can restart a javapackager packaged process, look
here:

https://github.com/vinumeris/updatefx/blob/master/api/src/main/java/com/vinumeris/updatefx/UpdateFX.java#L60

It's not beautiful but it works. You could extract the code and use it in
your app: UpdateFX is Apache licensed.

Re: Results of review of private JavaFX API for consideration to make public in JDK 9

[Mike Hearn]

If there were to be an API for getting basic graphics device data, what
would that look like and would it be hard to write?

My app uses some internal APIs not listed above to query the pixel scale
and whether we're using software/hardware graphics, to reduce usage of some
expensive effects. These are just booleans, essentially.

On Fri, Aug 7, 2015 at 11:51 AM, Benjamin Gudehus hasteb...@gmail.com
wrote:

 Hi Jonathan,

 thanks for the summary!

 pull up your sleeves and work with us to get the API into a shape where it
 is good enough to commit to as public API

 I'd like to help with the public API for profiling and performance tracking
 (mainly PulseLogger, maybe PerformanceTracker).

 These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil,
 and com.sun.javafx.application.PlatformImpl. As most of these classes are
 just a collection of self-contained methods, it is quite likely that a
 number of these methods will find public API alternatives in a new class

 Sounds good. TestFX has a dependency to
 com.sun.javafx.application.ParametersImpl to provide the ability to test
 multiple different `Application`s. It currently depends on private fields
 and methods of internal classes.

 Robot: A good API to make public, but not a small API, so the scope is
 possibly too great for JDK 9.

 The headless testing feature in TestFX has dependencies to
 com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the
 AWT robot, the normal testing mode needs no access to the internal APIs.

 The screenshot feature in headless testing depends on
 com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels.

 Additionally we also need access to com.sun.glass.ui.PlatformFactory in
 order to activate Monocle on desktop systems.

 --Benjamin

 On Fri, Aug 7, 2015 at 1:10 AM, Jonathan Giles jonathan.gi...@oracle.com
 wrote:

  Hi all. In April of this year a discussion began when news broke that
 with
  JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while
  back I posted a request to openjfx-dev for people to send me their JDeps
  output so that it could be analysed and used to inform our decisions
 around
  which API we should try to promote into public API. The response was very
  useful (and I should note: its too late now, please don't send me anymore
  JDeps files), and I believe we have the beginnings of a plan on how to
 move
  forward.
 
  Before I outline the plan, please note that this discussion would ideally
  _not_ devolve into a feature requests discussion. What we are wanting to
  talk about today is simply API that exists in the com.sun.* package
  namespace which we can conceivably bring out of this namespace for JDK 9.
  Developing new API is expressly out of scope (unless it is related to
  simplifying or wrapping the com.sun.* API).
 
  Another important point - UI control skins and a lot of very useful CSS
  API are being made public under JEP 253 [2]. A lot of the skin code has
  already been cleaned up, simplified, documented, etc, and will be merging
  into a repo very soon. I'll also post a separate post about JEP 253 soon.
 
  So, what does my JDeps analysis show (ignoring UI Controls and CSS usage,
  which has been largely resolved by JEP 253)? I can sum it up in the
  following categories:
 
  == 'Toolkit' API ==
  A lot of people use a small amount of API from Toolkit, such as the API
  for nested event loops, to fire a pulse, and to add / remove pulse
  listeners. Based on this analysis, the current thinking is to add API
 into
  the javafx.application.Platform class to enable the first two use cases
  above (nested event loops and pulse firing). The third use case needs
 more
  engineering effort, and is a far less common use case, so isn't being
  considered for JDK 9.
 
  == 'Traversal' API ==
  This API lives in com.sun.javafx.scene.traversal, and is quite useful
 when
  writing custom controls to ensure that keyboard traversal puts the focus
 in
  the right node at the right time. My ControlsFX open source project is a
  common (ab)user of this API, so I have a vested interest in making this
  public. Having said this, the API is actually in quite good shape, and it
  is possible with just a little JavaDoc work it could make the move into
  javafx.scene.traversal.
 
  == 'Collections Event' API ==
  There exists classes in com.sun.javafx.collections that are quite useful
  if you create your own custom ObservableList implementation and want to
  fire events at certain times. In my analysis there are only two projects
  using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent
  point is that this code is quite easy to reproduce, so, whilst I would
 like
  to see this API public, it doesn't seem to make sense for JavaFX 9.
 
  == 'Utils' API ==
  There exists three classes that are quite commonly used by people for the
  various utility methods contained within. These classes are
  com.sun.javafx.util.Utils, 

Re: Another JavaFX Application Thread

[Mike Hearn]

That seems like a roundabout way to do things.

The web tells me:  The asciidoctor.js project is a direct port of
Asciidoctor from Ruby to JavaScript using the Opal Ruby-to-JavaScript cross
compiler

Why don't you use JRuby and run the original Asciidoctor code directly in a
background thread? That way, no webview is needed and it can all be done in
the background.

Re: RejectedExecutionException

[Mike Hearn]

Race free shutdown in multi-threaded programs is always very hard. At
Google some programs and libraries simply didn't support it: for servers,
the cost in terms of bugs and extra code was deemed to outweigh the
benefits, so the only supported way for a process to end was for it to be
killed.

JavaFX does not have that luxury. It must be able to shut down cleanly
without races. In this case, the message is probably harmless: who cares if
a render job doesn't complete if you're busy tearing down process state? So
perhaps Quantum should just set a custom reject handler that ignores the
issue instead of throwing.


On Mon, Aug 3, 2015 at 4:10 PM, Tom Eugelink t...@tbee.org wrote:

 Working on a new skin for JFXtras Agenda... What is JavaFX trying to tell
 me with this exception?

 java.util.concurrent.RejectedExecutionException: Task
 com.sun.javafx.tk.quantum.PaintRenderJob@33cf88 rejected from
 com.sun.javafx.tk.quantum.QuantumRenderer@1133212[Terminated, pool size =
 0, active threads = 0, queued tasks = 0, completed tasks = 30]
 at
 java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
 at
 java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
 at
 java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
 at
 java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
 at
 com.sun.javafx.tk.quantum.QuantumRenderer.submitRenderJob(QuantumRenderer.java:218)
 at
 com.sun.javafx.tk.quantum.QuantumToolkit.addRenderJob(QuantumToolkit.java:467)
 at com.sun.javafx.tk.quantum.ViewScene.repaint(ViewScene.java:140)
 at
 com.sun.javafx.tk.quantum.PaintCollector.renderAll(PaintCollector.java:435)
 at
 com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:526)
 at
 com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:505)
 at
 com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$400(QuantumToolkit.java:334)
 at
 com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$47/14510047.run(Unknown
 Source)
 at
 com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:95)
 at com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
 at
 com.sun.glass.ui.win.WinApplication.lambda$null$145(WinApplication.java:101)
 at com.sun.glass.ui.win.WinApplication$$Lambda$43/19282349.run(Unknown
 Source)
 at java.lang.Thread.run(Thread.java:745)

Simple equivalent to display: none?

[Mike Hearn]

One common layout task that seems harder than necessary in JavaFX is to
temporarily remove a node from the scene graph, without having to actually
mess about with the parent container. In HTML you can do use #foo {
display: none; } to hide something temporarily. In JFX you have to remove
from the parent container's child nodes list, and then remember where it
was so it can be put back later.

The visible property is nearly good enough except that it doesn't affect
layout. Setting both visible and managed to false can sometimes work but
seems indirect.

Is there any appetite for a boolean display property that makes layout
managers ignore/skip the child and also makes it invisible?

Re: JavaFX features in JDK 9

[Mike Hearn]

Be fair, chaps. WebGL is not exactly accessible.

Desktop Linux is an extremely niche platform. JFX is open source. If
someone wants accessibility support on Linux, they can certainly contribute
patches to implement it.

The JDK9 plan looks OK to me. It doesn't sound exciting but support
Jigsaw actually translates to a fairly large set of new features, as stuff
that had to be done by hacking the internals before will finally get
surfaced with proper documented APIs. It'll make the developer experience
more pleasant.

With respect to things like support WebRTC or support WebGL -
seriously? WebRTC is useful for exactly one kind of app, video chat. It
seems to have been driven primarily so Google could make a Skype competitor
inside Gmail without having to make a downloadable plugin. There are
already many competing video call apps that work fine.

As for WebGL, you can already do OpenGL from within Java just fine. Being
able to do arbitrary GL within an FX scene graph would be nice for some
apps, but of course, on Windows you'd really need to be using Direct3D or
some kind of performance-hurting translation layer as WebGL itself uses.

If I had a single wish it'd be for better rich text support, like a rich
text editor component (maybe based on Tomas Mikula's work). I know that
WebKit can be used to do this but it's always been sort of glitchy and what
you get out is HTML which then can't be rendered easily in a regular
TextView. Unlike many of these other suggestions such a component would be
useful for business apps, and a basic one seems achievable in a reasonable
budget especially if it's based on Tomas' existing code.


On Tue, Jun 30, 2015 at 1:13 PM, Jack Moxley j...@moxley.co.uk wrote:

 Maybe it should its aspirations a little higher, especially with the
 advent of unity, webgl or even scenegraph impls such as jmonkeyengine that
 do.

 Sent from my iPhone

  On 30 Jun 2015, at 09:42, Felix Bembrick felix.bembr...@gmail.com
 wrote:
 
  coughJavaFX has *never* claimed to be write once, run anyway/cough
 
 
  On 30 Jun 2015, at 18:13, Mike mikeg...@gmail.com wrote:
 
  coughwrite once, run anywhere/cough
 
  This about sums it up!
 
 
 
  On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley j...@moxley.co.uk
 wrote:
 
  coughwrite once, run anywhere/cough
 
  Sent from my iPhone
 
  On 29 Jun 2015, at 21:45, Michał Zegan webczat_...@poczta.onet.pl
  wrote:
 
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Does it mean platform support for linux won't be implemented now, or
  at all?
  I usually use windows, but still depend on that support because I
  sometimes use linux, so I am interested about that.
 
  W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze:
  There is public API in 8u40 to support accessibility. Applications
  using standard JavaFX controls can, for example, use the
  accessibleText property to define the text that the screen reader
  will speak or the accessibleHelp property to provide a more
  detailed description. These properties have reasonable defaults,
  but can be overridden by applications. Additionally, if you use the
  labelFor property to point to a Control that the Label is
  associated with, the accessibility framework will use that when the
  screen reader is active.
 
  Custom controls can override the queryAccessibleAttribute,
  executeAccessibleAction, and notifyAccessibleAttributeChanged
  methods.
 
  As for platform support, we currently support Windows and Mac
  platforms. We have no plan to make FX accessible on Linux .
 
  -- Kevin
 
 
  Michał Zegan wrote: I saw it, and it seems promising, but: first,
  there is probably, or I heard it wrong? no public api for making
  accessibility related stuff... Also, I believe there is no linux
  accessibility bridge as opposed to windows and mac. And I do not
  know if I am wrong, or when this is going to be implemented.
 
  W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze:
 
  JavaFX accessibility is already implemented and was delivered
  in JDK 8u40.
 
  -- Kevin
 
 
  Michał Zegan wrote: What about accessibility work? Work on it
  has been started, but not sure if it is still targetted for
  9.
 
  W dniu 2015-06-27 o 20:16, Mike pisze:
 
 
  a lot of FULL blown Webrtc support and building
  something in Javafx (like Scene Builder) that Proves
  Webrtc support would be awesome. Ditto to Webgl
  support.
 
  On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth
  kevin.rushfo...@oracle.com
 
 
  wrote:
 
  Hi Felix,
 
  Sorry for the delay. Most of us were still pretty
  focused on 8u60, but we are turning our attention to
  JDK 9 now.
 
  The focus for JDK 9 is Jigsaw. The currently planned
  big features (JEPs) for FX in JDK 9 are these:
 
  JEP 253: Prepare JavaFX UI Controls  CSS APIs for
  Modularization JEP 257: Update JavaFX/Media to Newer
  Version of GStreamer
 
  Related to Jigasw, we intend to look into new API for
  heavily used internal methods / classes since they
  will no longer be accessible otherwise. We 

Bug report: HostServicesFactory on Linux needs a more complete browsers list

[Mike Hearn]

The file HostServicesFactory.java (I cannot find it in the JFX8+ repo)
contains this line of code, for Linux. It should be re-arranged and
extended for better compatibility:

- static final String[] browsers = new String[]{google-chrome,
firefox, opera, konqueror, mozilla};

+ static final String[] browsers = new String[]{xdg-open,
gnome-open, google-chrome, chromium, firefox, opera,
konqueror, mozilla};

Re: Integrated vs. Discrete Graphics on OS X

[Mike Hearn]

The relevant Apple dev doc is here:

https://developer.apple.com/library/mac/technotes/tn2229/_index.html

Essentially it involves setting flags on the GL pixel format. Then you can
receive a callback from the OS either via NSOpenGLView or an old C style
callback which tells you that the active GPU has changed. I haven't read
the JFX Mac GL code so I don't know what APIs it's using. In the callback
you are meant to re-query GL capabilities and redraw, I think.

There's also some extra work required if you use pbuffers or GL textures
instead of framebuffer objects. I don't know which JFX uses.

Re: Integrated vs. Discrete Graphics on OS X

[Mike Hearn]

I believe the tricky part is not setting the magic flag in your Info.plist
file but rather handling the GL context changes on the fly. It
requires/would require some code in the Mac GL specific part of JavaFX.
Otherwise if you force it to integrated then some other app causes a switch
to discrete, the app might die because its GL surface just vanished.

On Mon, May 25, 2015 at 5:30 PM, Scott Palmer swpal...@gmail.com wrote:

 I've noticed that it is not possible to run a Java GUI app (Swing or
 JavaFX) on a MacBook Pro without it activating the discrete graphics and
 therefore reducing battery life.

 I believe it is automatically triggered by the use of OpenGL.  Unless you
 explicitly code for the integrated adapter, I don't think you can use
 OpenGL without the discrete adapter kicking in.  It would be nice if
 packaged app bundles done with the javapackager had an entry in the
 Info.plist that would signal that the application does not require the
 discrete adapter.

 This appears to already be filed as a JDK bug at
 https://bugs.openjdk.java.net/browse/JDK-8041900 but it doesn't look like
 it is getting much attention.  Is it likely to be addressed for 9 or an 8uX
 release?


 Regards,

 Scott

Re: slightly ot: java9 runtime images

[Mike Hearn]

Do you actually need JAR signatures anyway? The JVM is bundled, it's not
like you have to pass some system security policy beyond Gatekeeper/Windows
code signing.

Re: JDK 1.8.0 33/40, diacritics and file problems

[Mike Hearn]

 I thought Mac OS X has a standard normalization for unicode filenames.
 Linux just treats whatever it gets as bytes so it is up to the software
 creating the file. Am I correct?


Looks like you are:

https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#UnicodeSubtleties

So HFS+ does define a normalization form, which is apparently something
very close to but not identical to NFD. Good to know.

Re: JDK 1.8.0 33/40, diacritics and file problems

[Mike Hearn]

 They were rsynced from Mac OS X.


I said *original* app. Rsync is not the original app and most likely does
not attempt to re-encode or re-normalise Unicode strings.


 I feared that. In the end it might be even reasonably doable, if I can
 take advantage of some preconditions... for instance: is it safe to assume
 that, given a specific instance of a filesystem, everything is
 encoded/normalised in the same way?


Probably not. Most software that handles unicode does not do code point
normalisation. Hence my emphasis on what app created the file name in the
first place.

Re: Enhancements to 3D for JFX9?

[Mike Hearn]

 this may mean, people who do this must work with a patched JDK in the
 future.


Right. But I think that's going to be more and more common in future. If
you rely on people installing proprietary stuff like JWS or applets then
it's a bleak future, as the way forward is clearly bundled JREs.

At some point I suspect someone will make a kind of WebStart Next
Generation without Oracle and start distributing a custom build of OpenJDK
+ their own platform/distribution stuff.

For example, a JRE that updates itself via Omaha on Windows would clearly
be superior to Oracle's solution:

   https://code.google.com/p/omaha

Combined with a more modern app store like approach rather than JNLP or
applets and that'd be a winner, I think.

Re: Off topic: named parameters

[Mike Hearn]

I don't know about JEP submission process, but you'd first have to solve
the problem that when Java added serialization of parameter names to class
files in Java 8, the OpenJDK devs explicitly decided *not* to expose them
for the JDK itself, on the grounds that they didn't want parameter names to
become part of the API. That's why you have to pass -parameters to javac to
get the new feature.

Adding named parameters to the Java language is probably a fair bit of
work. You'd need to build consensus for it on the relevant mailing lists
and with the relevant people first, before even getting to the JEP stage I
guess. An easier path: figure out how to get parameter names as part of the
JDK API and then work with the JetBrains Kotlin team. Kotlin is a very very
Java compatible JVM language, and it already supports named parameters by
default so they don't have the same hangups about the API compatibility
aspect. The Kotlin compiler routinely uses annotation data from Java
classes already so that's not a big leap either.

I suspect what it will take to get the JDK folks happy with exporting
parameter names by default is the ability to overload methods that differ
only by parameter names, so if you have a method with bad names then you
can add an overload with good names. However this would require a (much
smaller) change to the Java language, changes to javac, changes to how the
JVM does method linkage (possibly?) and so on.

Another possible plan of attack would be to calculate API diffs over time
and measure how often parameter names are actually changed. My guess is
not often. If you can prove that they're worried about a relatively
uncommon problem then perhaps the JDK maintainers can be convinced to make
parameter names a part of the API, perhaps after an API cleanup pass to
find obviously bogus names and fix them.

Alternatively, given that Java is open source, you can of course go ahead
and make your own version of the JRE that exports this data by default.
Then you accept the possibility of upstream breaking your code and just
swallow it.

On Tue, Apr 21, 2015 at 9:52 AM, Tom Eugelink t...@tbee.org wrote:

 Totally off topic, I apologise, but the subscribers to this list are the
 type of people who may have the experience I seek.

 I've been trying to pitch the concept of named parameters for Java 9, but
 somehow my JEP is never picked up. I emailed it in twice. Has anyone ever
 successfully handed in a JEP?
 https://tbeernot.wordpress.com/2013/09/29/the-java-9-named-parameter-pitch/

 Tom

Re: Private APIs not usable in Java 9?

[Mike Hearn]

I guess a good place to start would be to eliminate usage of private APIs
from scene builder. I understand that it doesn't seem to be supported any
more but it'd be extremely weird and embarrassing for Oracle if the UI
builder tool broke on Java 9 given all the work that went into it.
On 9 Apr 2015 9:54 am, Jonathan Giles jonathan.gi...@oracle.com wrote:

 For what it is worth, investigations are underway in relation to UI
 control skins and behaviors. It's too early for anything definitive to
 announce, but it is not inconceivable that com.sun.javafx.scene.control.skin
 may become javafx.scene.control.skin, more or less (with a lot of work
 cleaning up, etc).

 In terms of behaviors, some investigations are already underway in
 RT-21598, but these too are only early, and fall under the bigger project
 of getting UI controls and CSS APIs into a jigsaw-friendly form for JDK 9
 (which is a huge undertaking, and community support will be useful and
 sought at the appropriate time).

 Thanks,

 -- Jonathan

 On 9/04/2015 5:39 p.m., Tom Schindl wrote:

 Hi,

 in SWT on JavaFX (most likely NOT a common useage of JavaFX):
 -
 I had to reside to private-API when it comes to:
 * text calculations where there is no public API for things like
FontMetrics, TextLayout, ...
 * For some of the direct drawing code I had to use com.sun.javafx.geom.*
 * For some operations I had to access the com.sun.glass.ui.Robot 
com.sun.glass.ui.Application
 * I had to get access to the VirtualFlow

 To implement custom controls e.g. CodeEditor:
 -
 * com.sun.javafx.scene.control.skin.BehaviorSkinBase
 * com.sun.javafx.scene.control.behavior.KeyBinding
 * com.sun.javafx.css.converters.InsetsConverter
 * com.sun.javafx.css.converters.PaintConverter
 * com.sun.javafx.scene.text.HitInfo

 So to summerize the most lacking API is in the font/text rendering space
 and to get public access to VirtualFlow would be a nice to have!

 Tom


 On 08.04.15 18:44, Phil Race wrote:

   it's not strictly JFX-only.

 Its not remotely FX only, in fact I could argue FX is not so affected,
 as being relatively new it does not have 20 years of accumulation
 of people using internal APIs that the larger JDK does, often dating from
 when there were no suitable public APIs. There still remains some
 of that with sun.misc.Unsafe as pointed out which will indeed be
 inaccessible in modular mode. But the FX list isn't really the place
 for that discussion. The jigsaw-dev is the appropriate list. FX
 is simply bound by the rules that are set there.

 There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
 transition.

 Also remember FX is open source. You can propose patches !
 If there are specific APIs that are missing from FX that are suitable
 to be *supported* public APIs then those could be considered here (this
 list).

 -phil.

 On 4/8/2015 9:28 AM, Mike Hearn wrote:

 sed -i 's/private/public/g' ;)

 The whole notion of a strongly enforced private keyword is IMHO dumb
 when
 not using sandboxing. The number of gross hacks that occur in an
 attempt to
 work around overly strict enforcement of this stuff is crazy. The D
 compiler has a special flag that disables visibility enforcement when
 compiling unit tests, and that's a good idea, but why not go all the way
 and just make accessing of private state a compiler warning a la
 deprecated?

 I also need to use private JFX APIs. I think any real JFX app does,
 way too
 much basic stuff relies on it. Heck, the number of popular Java
 libraries
 that depend on sun.misc.Unsafe is huge. If Java 9 stabs us in the back
 in
 this regard then I will just write a simple tool that flips
 private-public
 either at the source level or via bytecode editing, and see what
 happens :-)


 On Wed, Apr 8, 2015 at 6:14 PM, Robert Krüger krue...@lesspain.de
 wrote:

  Hi,

 I hope this is not too off-topic, because although it came up in a JFX
 context it's not strictly JFX-only.

 Someone from our team recently had a chat with a high-ranking regional
 Oracle representative who gave a talk on the state of JFX. Our guy
 explained our situation (evaluating JFX to migrate our swing-based
 product,
 feeling it's in principle the right technology but still having
 show-stopping limitations like RT-36215) and the Oracle guy offered to
 relay our concrete questions to the right people, which he did.

 The answer we got contained one thing that really was a bit of a
 shock and
 I would like someone to either confirm this or clear up a
 misunderstanding.

 The statement was that private APIs will not be available in JDK 9
 due to
 modularity restrictions. If that is the case and we no longer have the
 ability to build temporary workarounds using private APIs (which in our
 case is controllable as we ship the JRE with our product), I would
 probably
 have to stop any development going into the direction of JFX

Re: Private APIs not usable in Java 9?

[Mike Hearn]

 For the benefit of the devs on the list, could you please point out what
 private APIs you currently need to use?  That way we can make sure proper
 JIRAs are filed and we can connect those to actual real-world problems.


e.g. handling a double click of a file on MacOS is impossible without using
private APIs currently. I think a bug is filed already, but I don't know
the number.

Learning if you're on the software pipeline or GL/D3D pipelines also
requires internal APIs. This is useful for winding back animations on
hardware/pipelines that can't take it.

Finding the current pixel scale of the screen, same.

I don't know if it counts but I find myself relying on or overriding
undocumented rules in modena.css somewhat frequently. For example the
edge-to-edge rule for ScrollPane. Of course, jigsaw will not break that.

I think AquaFX has to use internal APIs in various places though I don't
remember why.

Those are the examples from my (quite small) app.

Re: Review Request: RT-39975 - AppCDS support for packager

[Mike Hearn]

The bug is restricted - intentional?

I'm guessing this is class data sharing and would make startup of packaged
apps faster?

On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen chris.ben...@oracle.com
wrote:

 +1

 On Mar 30, 2015, at 3:11 PM, Danno Ferrin danno.fer...@oracle.com wrote:

  Kevin, Chris, please review
 
  jira: https://javafx-jira.kenai.com/browse/RT-39975
  webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/

Re: Review Request: RT-39975 - AppCDS support for packager

[Mike Hearn]

Do you have any stats on the perf improvement? My understanding of CDS is
that it was primarily meant to reduce memory usage on systems where
multiple Java apps are running on the same JRE simultaneously. I guess that
won't apply to packaged apps so the only benefit can be startup time.

On Tue, Mar 31, 2015 at 3:59 PM, Chris Bensen chris.ben...@oracle.com
wrote:

 Correct!


 On Mar 31, 2015, at 4:41 AM, Mike Hearn m...@plan99.net wrote:

 The bug is restricted - intentional?

 I'm guessing this is class data sharing and would make startup of packaged
 apps faster?

 On Tue, Mar 31, 2015 at 12:52 AM, Chris Bensen chris.ben...@oracle.com
 wrote:

 +1

 On Mar 30, 2015, at 3:11 PM, Danno Ferrin danno.fer...@oracle.com
 wrote:

  Kevin, Chris, please review
 
  jira: https://javafx-jira.kenai.com/browse/RT-39975
  webrev: http://cr.openjdk.java.net/~shemnon/RT-39975/webrev.00/

Re: What are the plans for Java9?

[Mike Hearn]

 One of the major pain points I see is that the java-packager does not
 support to set a splash-screen


Does your app really need one? My laptop can throw a Stage onto the screen
in about 500msec. Then you can just show your own splash whilst the app
loads ...

Re: 8u40 is released

[Mike Hearn]

Hi Kevin,

Scene Builder source code is available in the OpenJFX repo under the BSD
 license, but separate binaries are no longer being released as of 8u40.


I'm a bit confused what this means.

People who want to use Scene Builder are expected to compile it themselves
from now on? Does that really make sense? Presumably the idea here is that
SB will be integrated into IDEs and will no longer have any purpose as a
standalone app, but I'm not sure we're ready to go there yet - the last
time I tried the SB integration into IntelliJ it was extremely basic and
far below the experience of the dedicated app.

As just one example, UI design benefits a lot from maximal screen space.
IDE embeddings often don't provide that.

Re: 8u40 is released

[Mike Hearn]

That's great Johan, but .. what does this mean, exactly? Is SB
effectively dead at this point? Short of some horrifically convoluted
corporate politics I can't understand why Oracle would develop an
application but not provide downloads of it. Does this mean SB won't be
upgraded past 8u40?

I mean - I don't think it's unreasonable of me to be surprised by this, and
I thought I followed JFX development pretty closely. What's the story here?

On Wed, Mar 4, 2015 at 11:39 AM, Johan Vos jo...@lodgon.com wrote:

 Oracle stated that they won't release new binaries for SceneBuilder, but
 since the code is open-source and BSD licensed, third parties and the Java
 Community in general can create binaries based on the SceneBuilder sources.
 This is what we did at Gluon (http://gluonhq.com), and the result can be
 downloaded at http://gluonhq.com/products/downloads/
 This download is based on the latest 8u40 source code in OpenJFX. It
 includes the 8u40 Controls (e.g. Spinner, Dialogs).

 Hope this is helpful.

 - Johan

 2015-03-04 16:31 GMT+01:00 Mike Hearn m...@plan99.net:

 Hi Kevin,

 Scene Builder source code is available in the OpenJFX repo under the BSD
  license, but separate binaries are no longer being released as of 8u40.


 I'm a bit confused what this means.

 People who want to use Scene Builder are expected to compile it themselves
 from now on? Does that really make sense? Presumably the idea here is that
 SB will be integrated into IDEs and will no longer have any purpose as a
 standalone app, but I'm not sure we're ready to go there yet - the last
 time I tried the SB integration into IntelliJ it was extremely basic and
 far below the experience of the dedicated app.

 As just one example, UI design benefits a lot from maximal screen space.
 IDE embeddings often don't provide that.

Re: 8u40 is released

[Mike Hearn]

Hey Jonathan,

If you let us know who does make these decisions, we will happily repeat
our questions to them :) Mark Reinhold perhaps?

I mean, I appreciate that GUI libraries are probably not a prime driver of
sales for Oracle, but as an enterprise focused company I assume management
understands the value of being able to do long term planning around any
tool or API.

WRT 8u60+9, I read that 8u60 is going to be a bug fix only release with no
new features at all. I don't know how to read that, as JavaFX does not seem
especially buggy to me, and previously it seemed that rich text might
feature. It feels that manpower put on JFX is indeed being reduced.

Perhaps a business opportunity for someone who wants to be the next
Trolltech :-)

Re: 8u40 is released

[Mike Hearn]

 2349 Unresolved Bugs seems buggy to me:

 https://javafx-jira.kenai.com/issues/?jql=issuetype%20%3D%20Bug%20AND%20resolution%20%3D%20Unresolved


Any software project always has lots of unresolved issues in the issue
tracker, though, especially something as large as a UI toolkit. Qt has
about 15,000 open issues:

https://bugreports.qt.io/browse/QTWEBSITE-628?jql=status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened%2C%20Accepted%2C%20Reported)

Actually 2349 bugs feels suspiciously low to me . I suspect it reflects
more that the JFX user community is quite small rather than the true number
of bugs in the product :-)

I certainly encountered a few bugs when writing my own app, but they were
all easy to work around and so far they were all fixed in 8u40. Perhaps my
experience is atypical.

I agree that SB is probably something that can be well maintained by the
community at this point, especially with commercial backing from Gluon.

Re: 8u40 is released

[Mike Hearn]

 This is what we did at Gluon (http://gluonhq.com), and the result can be
 downloaded at http://gluonhq.com/products/downloads/


Thanks Johan! Looks like Gluon is the Trolltech equivalent I just wished
for - that was fast :-)

From your blog post, it sounds like you're planning to fork SB or at least
maintain a patch set on top of it. So I guess you have reason to believe SB
upstream is a dead project at this point?

If you let me know when you have a public repository, I'll take a look at
contributing an integration of UpdateFX and CrashFX. Users would still need
to re-download the app to upgrade the JVM across major releases but other
changes could be pushed easily to all users in the background.

I'm also interested in making it more keyboardable, in particular shortcuts
for wrapping/unwrapping would be useful and ability to insert controls
based on an auto complete of the name.

Re: HEADS-UP: [9] New WebKit + compiler upgrade for FX 9

[Mike Hearn]

I see, thanks for the background Anton. I haven't used WebView in my own
app (partly because it's security sensitive) so didn't realise how
integrated the control is! That's indeed a very impressive level of
integration.

It's possible I'm over-thinking this. Disabling JavaScript is probably
enough to satisfy many use cases with acceptable levels of security.

Alternatively, occasionally I look around for a pure-Java HTML/CSS
rendering engine. But most of the ones I've found are quite primitive.

Re: HEADS-UP: [9] New WebKit + compiler upgrade for FX 9

[Mike Hearn]

 The changeset patch is 185 Mbytes and touches 11,688 files including
 added, removed, modifiled files. I tried generating a webrev, but it is
 just too big and unweildy to upload (over 1.6 GBytes).


A 185 megabyte patch!? That is .. mind boggling. I don't envy you guys!

Couple of questions:

1) I'm curious if there are plans to sync with WebKit upstream more
frequently from now on to try and reduce the pain of upgrades. As WebKit is
so complex and security sensitive, and not sandboxed in the same way as
Chrome, regular updates seem vital for security. Of course this doesn't
matter if you are just rendering your own content but for displaying
potentially hostile content, it seems important.


2) Have you considered using Blink instead, perhaps that way you would get
the sandboxing tech from Chromium? Or does the WebKit JFX uses now have
cross-platform sandboxing in it as well?


Thanks!

Re: Question/feedback regarding Windows Hi DPI support and how it will affect applications

[Mike Hearn]

 Finally, it would be nice to get information about the actual screen DPI.
 In my tests Screen.getDpi always returns 96, regardless of what it actually
 is...


You can reflectively access Screen.getPixelScale() to learn if you're on
Retina. Of course, don't expect to swap out the JRE for a newer one
automatically if you do this (I bundle so it's not so problematic).

WRT Jim's questions:

- Would seeing non-integer event coordinates break your code?

No.

- Would seeing non-integer window sizes and positions break your code?

No. I serialize window co-ordinates to disk so the main window appears in
the same place and size across app restarts, but I just checked and I'm
saving them as doubles so it would just work.

- Would non-integer screen sizes break your code?

No.

- If we provide a flag or scale factor on the screens to indicate that the
dimensions provided are in pixels and you must convert your desired window
sizes by the indicated scale factor in order to know how big to make your
window - how much impact would that have?

You mean like Screen.getPixelScale()?

Honestly I find this stuff confusing. Re-defining pixel to mean something
other than dot on a screen matrix breaks my entire lifetime's mental model
of how screens work. I'd almost prefer to just specify everything in terms
of some abstract unit like an 'em' and then not think about pixels at all,
though I realise that isn't compatible with how the JavaFX API works. The
notion of screen vs stage pixels is likely to be especially confusing.

Why do the Linux packages go into /opt?

[Mike Hearn]

javapackager makes debs that install things into /opt, which means they
aren't on the path. Is there a reason for this choice rather than making
FHS-compliant packages that install into /usr?

thanks!

Re: How to handle file open requests on MacOS

[Mike Hearn]

What is Application.getApplication() here? The JavaFX Application class
does not have a setOpenFileHandler method. Is that a Mac-specific API?

It's too bad that 8u40 won't have this. Being able to easily open double
clicked files is pretty basic. Perhaps post 8u40 the JFX team could go
through Scene Builder and identify everywhere it relies on internal APIs or
custom magic and suck it into the core API, as then you'd have confidence
that an app of real complexity can be done entirely with documented stuff.

Re: How to handle file open requests on MacOS

[Mike Hearn]

Scene Builder doesn't do it this way - AFAICT you're only allowed to have
one such event handler registered with the OS and JavaFX already registers
one ... it just doesn't expose the resulting Java events via public API.

On Mon, Jan 5, 2015 at 6:50 PM, Danno Ferrin danno.fer...@oracle.com
wrote:

 Oh, yes.  Mac has it's own Applicaiton class.  Here's the imports for the
 second file...

 import com.apple.eawt.AppEvent;
 import com.apple.eawt.Application;
 import java.io.File;
 import java.util.List;
 import javax.swing.SwingUtilities;

 The com.apple.eawt stuff is shipped with Oracle JRE and JDK, but like I
 said in my previous mail you need to pass a flag to the compiler to turn
 off it's index and read the jar.

 The JavaDoc has gone MIA though --
 https://bugs.openjdk.java.net/browse/JDK-8027638 but you can peruse the
 source code to see the details, it's all OpenJDK -
 http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/564bca490631/src/macosx/classes/com/apple/eawt

 On Jan 5, 2015, at 10:43 AM, Mike Hearn m...@plan99.net wrote:

  What is Application.getApplication() here? The JavaFX Application class
 does not have a setOpenFileHandler method. Is that a Mac-specific API?
 
  It's too bad that 8u40 won't have this. Being able to easily open double
 clicked files is pretty basic. Perhaps post 8u40 the JFX team could go
 through Scene Builder and identify everywhere it relies on internal APIs or
 custom magic and suck it into the core API, as then you'd have confidence
 that an app of real complexity can be done entirely with documented stuff.

Re: How to handle file open requests on MacOS

[Mike Hearn]

OK, then I might switch (or maybe not, as my current solution works ...)

BTW I noticed that the javapacker ISS changes put the file association
entries into HKEY_CLASSES_ROOT. Doing this results in an error half way
through setup if you don't run the installer with admin privs. The current
installer setup runs just fine with lowest privs, so it'd be perhaps nicer
to put the registry entries under HKEY_CURRENT_USER\SOFTWARE\Classes
instead:

http://support.microsoft.com/kb/257592

On Mon, Jan 5, 2015 at 8:59 PM, Danno Ferrin danno.fer...@oracle.com
wrote:

 This code works inside of a JavaFX application too, just tried it locally.


 You may be thinking of an older iteration of the apple application
 listener classes or perhaps the native level of the code.

 On Jan 5, 2015, at 11:04 AM, Mike Hearn m...@plan99.net wrote:

 Scene Builder doesn't do it this way - AFAICT you're only allowed to have
 one such event handler registered with the OS and JavaFX already registers
 one ... it just doesn't expose the resulting Java events via public API.

 On Mon, Jan 5, 2015 at 6:50 PM, Danno Ferrin danno.fer...@oracle.com
 wrote:

 Oh, yes.  Mac has it's own Applicaiton class.  Here's the imports for the
 second file...

 import com.apple.eawt.AppEvent;
 import com.apple.eawt.Application;
 import java.io.File;
 import java.util.List;
 import javax.swing.SwingUtilities;

 The com.apple.eawt stuff is shipped with Oracle JRE and JDK, but like I
 said in my previous mail you need to pass a flag to the compiler to turn
 off it's index and read the jar.

 The JavaDoc has gone MIA though --
 https://bugs.openjdk.java.net/browse/JDK-8027638 but you can peruse the
 source code to see the details, it's all OpenJDK -
 http://hg.openjdk.java.net/jdk8u/jdk8u40/jdk/file/564bca490631/src/macosx/classes/com/apple/eawt

 On Jan 5, 2015, at 10:43 AM, Mike Hearn m...@plan99.net wrote:

  What is Application.getApplication() here? The JavaFX Application class
 does not have a setOpenFileHandler method. Is that a Mac-specific API?
 
  It's too bad that 8u40 won't have this. Being able to easily open
 double clicked files is pretty basic. Perhaps post 8u40 the JFX team could
 go through Scene Builder and identify everywhere it relies on internal APIs
 or custom magic and suck it into the core API, as then you'd have
 confidence that an app of real complexity can be done entirely with
 documented stuff.

3D shape not clipped by ScrollPane properly?

[Mike Hearn]

I have a ScrollPane into which I put a Pane with a min width/height, and
then I place a Button and a Sphere. For both of them I use setLayoutX/Y to
move them around.

Now when I scroll the ScrollPane I can see it move the button around
correctly, and the sphere, but the sphere is able to draw over the
scrollbars. It's not being clipped like the Button is.

I have not configured any special cameras or the like.

Do 3D objects clip differently to 2D objects? If so, why?

Re: [8u40]: Review request for RT-39489: Latest 10.10.2 beta update causes NSTouch exceptions continually

[Mike Hearn]

What happens to existing jfx apps once 10.10.2 starts rolling out? Do they
all break?! I didn't see much discussion of the scope of this issue in the
bug report.

On Mon, Dec 1, 2014 at 9:44 PM, Morris Meyer morris.me...@oracle.com
wrote:

 Kevin and David,

 Please review this patch for the issue added with the 10.10.2 software
 patch that deals with part of the NSTouch interface changing.

 --morris

 JIRA - https://javafx-jira.kenai.com/browse/RT-39489
 WEBREV - http://cr.openjdk.java.net/~morris/RT-39489.01/

Re: What Scene Builder needs YESTERDAY!

[Mike Hearn]

FWIW I've found Scene Builder to work pretty well and haven't missed
animation support. Doing it at the code level was good enough. And yes I
have built things in Flash, a long time ago. Perhaps my standards are
lower, as mostly in the last few years when doing UI work I've been stuck
with HTML :-) Scene Builder and FXML are pure bliss compared to that!

My main Scene Builder gripe is simply that it could use more keyboard
shortcuts, in particular for wrap in. But that's relatively minor.

For animation, before a fancy all-singing all-dancing timeline editor, a
few more utilities in the API would go a long way. The animated bind
function I posted before is one I've been using a lot. Mostly you have
observable state in your model classes which of course don't animate, and
you want the UI to animate between states, so an animated bind type
construct is exactly what's wanted. It would make little sense to have a
more powerful animations framework that didn't work in this way, given that
most JavaFX apps are binding data to UI and back again.




On Mon Nov 24 2014 at 4:20:14 PM Manfred Karrer m...@nucleo.io wrote:

 I have a longtime backgroud in Flash and Flex development and a bit if
 iOS, so I would like to add here my 5 cents.

 My first impression and experience with Scene Builder was kind of: Is this
 meant serious? It cannot be that Oracle release such a product in year 2014
 when other platform had shipped well working UI - WYSIWYG editors more then
 10 years ago. Sorry I don't want to be rude, but that was my first reaction.

 Beside that it is (at least on mac) pretty buggy and not 2 way compatible
 (if you continue to edit in FXML you soon get to the point where you cannot
 open it in Scenebuilder anymore because it does not support all what the
 compiler supports). That leads either to a very cautious and restrictive
 usage of FXML or that you use it just initially for the first UI prototype
 and then later don't use it anymore and have the annoying workflow to
 compile and run the app to see visual changes.

 I know that a really well working WYSIWIG editor is a challenge, and so
 far the only 2 which really worked well from my experience was the Flash
 IDE (I did not use later versions anymore so no idea how it is today) and
 Xcode. The Flex editor had more or less the same problems like Scene
 Builder (in the teams I worked it was considered as a toy).

 One general problem is as soon you have 2 development paths (visual and
 xml) it tends that one gets lost behind from proper support of the vendor.
 Xcode and early Flash IDE made the radical decision to have only an visual
 editor, the workflow does not involve xml editing when you reach the limits
 of the editor. That forced the visual editors that they need to make it all
 possible, which worked for both platforms pretty well. Of course the Flash
 IDE was too limited on the coding side and had another direction, but XCode
 combined both worlds in a pretty good way.

 I am not expecting to have support for animations. Thats another hard
 challenge and I am not sure if that should not be left out to some external
 tools.
 I just would be happy to have an visual editor that really represents
 correctly what i will see when its compiled and which sticks in sync when
 the UI gets more complex and integrated with the projects code base (here
 Scene Builder lacks a lot!).

 But beside that, another disappointment for me was (coming from Flex) that
 it is pretty slow (for a such a fast runtime like Java). It feels for me
 same slow like Flex was, but the Flash runtime used by Flex is a much, much
 slower then Java, so how can it be that a Java based UI framework is not
 min. 10 times faster?

 Flex used code generation so all was compiled, otherwise it would have
 been completely unusable (slow).
 JavaFX use reflection and interprets FXML at runtime which introduces 2
 performance penalties:
 - The runtime loading (takes 50-200 ms depending on the size of the FXML)
 - The parsing and reflection based interpretation which takes another
 50-200 ms (not so sure about that, as in that time the inclusion in the
 scene graph is included as well, but if the layout or rendering is so slow,
 then that is another question why).

 Every delay larger then 50 ms is very clear visible to the user, resulting
 in an UI which just does not feel snappy.
 In my current app I use caching to avoid at least the slow loading (after
 the initial load). I will probably convert all FXML when the UI is final to
 java code to get rid of the second performance penalty. But that of course
 is not a satisfying situation!
 Hopefully some code generation projects gets mature enough to be really
 useful in complex UIs or Oracle take JavaFX serious enough to put more
 effort on that.

 Conclusion:
 You can see in the UI how well the tools have supported the work process.
 If its a pain and a lot of work to get simple stuff done the UI looks like
 that.
 Flash was very good on that 

Re: Embedding Mac native widgets into a Scene

[Mike Hearn]

Alternatively, I wonder how hard it is to access the underlying features
directly rather than try to use the real edit widget. Like, perhaps it's
possible to access autocorrect via JNA or equivalent.

On Fri, Oct 31, 2014 at 2:52 PM, Stephen F Northover 
steve.x.northo...@oracle.com wrote:

 Hi Mike,

 Embedding native controls in FX runs afoul of the whole
 lightweight/heavyweight issue.  I had a hack of this once using SWT native
 controls and I was able to have them appear on Windows because HWND
 clipping was honored but on Mac, FX drew on top of the native control.  Mac
 was changed to use CALayers way back for JDK7 and this also made things
 more complicated.

 Having said all that (from memory), for iOS, there was some work that
 overlayed an iOS text control in order to use the native keyboard control.
 The control was created when editing started and then disposed when editing
 ended.  This would obviously have the same lightweight/heavyweight issues
 while editing was happening and a host of other smaller problems (wrong
 font, jumping, scrolling etc).

 One possible way for this to really work would be to get the native
 control to render to a texture and get JavaFX to draw the texture. That is
 just the painting side of the equation.  Events would need to be delivered
 to this non-painting control as well.  There are operating system calls on
 Mac that you can use to paint a control to an image so it is in theory
 doable but a ton of work.

 Steve


 On 2014-10-31, 9:48 AM, Mike Hearn wrote:

 JavaFX provides a great set of widgets that are pretty complete, but a few
 lag behind behind their native counterparts on some platforms. This is
 especially noticeable with the Mac text field widget, which has things
 like
 integrated spelling/grammar checking, auto correct, services, speech
 recognition and so on.

 WebKit manages to expose all this functionality despite that HTML is not
 the native Mac UI framework. So I am wondering how hard it is for JFX to
 do
 the same. However, I know very little about how WebKit does this or how
 easy it'd be to replicate in the Java world. Are there any experts on the
 list who could comment?

Embedding Mac native widgets into a Scene

[Mike Hearn]

JavaFX provides a great set of widgets that are pretty complete, but a few
lag behind behind their native counterparts on some platforms. This is
especially noticeable with the Mac text field widget, which has things like
integrated spelling/grammar checking, auto correct, services, speech
recognition and so on.

WebKit manages to expose all this functionality despite that HTML is not
the native Mac UI framework. So I am wondering how hard it is for JFX to do
the same. However, I know very little about how WebKit does this or how
easy it'd be to replicate in the Java world. Are there any experts on the
list who could comment?

Re: Why would most FontAwesome icons work but not one?

[Mike Hearn]

 I've noticed this with some icons, double check that the font file
 you're using in FontAwesomeFX does actually contain the icon,
 FontAwesome seems to add new icons even in minor releases.


It's the same JAR on all three platforms, and Windows is the only one it
fails on. I don't think it can be this ...

Re: Mirrored observable collections

[Mike Hearn]

Someone got in touch with me today and pointed out a bug in this code, but
it was already fixed by me some time ago. I've refreshed the gist with the
latest versions of these classes, but the upstream project is now fully
open source. You can get the latest code here:

https://github.com/vinumeris/lighthouse/tree/master/common/src/main/java/lighthouse/threading

I should probably turn this into a little self contained library at some
point.

Re: How do I find out why the render loop is running?

[Mike Hearn]

Well, this was a pain in the ass. The cause is indeed
ProgressBar/ProgressIndicator. It turns out that they can leak animations
even when removed from the scene graph or their parents are made invisible.
I filed:

https://javafx-jira.kenai.com/browse/RT-38894

I now have a bunch of hacks to set the progress bar/indicators I have to
non-indeterminate when they're no longer visible or just before they are
removed from the scene graph, to let them clean up. I don't know why this
is required because I can see the code is trying to do the right thing, but
for whatever reason it does not seem to work reliably.

I figured out what's running by taking a look at
Toolkit.getToolkit().getMasterTimer().receivers every so often. A healthy
(idling) app that isn't using up battery should have just a single entry
inside a button click handler. If there are more, it means the app is
animating even if nothing on the screen is changing.

Re: How do I find out why the render loop is running?

[Mike Hearn]

 So you are using opacityProperty() and not visibleProperty(), so my
 exact workaround would not work anyway.


I did originally put some code into animatedBind to set visible == false
when opacity == 0.0 and vice versa, but it didn't seem to solve the
animation leak so I took it out again.

BTW animatedBind is a useful utility. It makes it much easier to make cool
animations that adjust as the data model changes. Here it is:

https://gist.github.com/mikehearn/f639176566d735b676e7

Something like that should be in the framework really.

Re: How do I find out why the render loop is running?

[Mike Hearn]

 2) A control, such as a ProgressIndicator, that uses animation to display
 changes (even if the control is scrolled off the screen)

 One common control animation that is easily overlooked is a text cursor,
 which is animated to blink - when the control has focus.


That would only cause one pulse per second or so, right?

Separating observable data structures out into a separate library?

[Mike Hearn]

Observable data structures are a useful and general abstraction, which
JavaFX deploys to great effect. Combined with the mirroring techniques I
posted about a few months ago I found them to be a good way of combining
background work and network-updated state with GUI apps.

For this reason, they'd also be useful outside of JavaFX, like on Android.
So I have a couple of questions:

   1. Are there license reasons why the JFX Observable* framework can't be
   used in for example Android apps? How does the JFX license affect this?

   2. If the JFX observables framework could be separated out from JFX
   itself, would there be any appetite for a Java 6 compatible version that
   resided in some separate mavenable library?

Lighthouse

[Mike Hearn]

I've open sourced the JavaFX app I was working on for the past six months
or so. Lighthouse is a Bitcoin crowdfunding application that uses some of
the more novel features of the Bitcoin protocol to allow middleman free
fund raising.

There's a video of it in action here:

http://blog.vinumeris.com/2014/09/12/lighthouse-alpha-now-open-source/

and some screenshots here:

https://github.com/vinumeris/lighthouse

Additionally I've open sourced UpdateFX, which is an auto update engine
that provides some interesting features:

https://github.com/vinumeris/updatefx

It's kind of rough still but if anyone is looking for an alternative to the
existing update engines out there, take a look.

I just wanted to say thanks to the OpenJFX team for your help and support
this summer. I've very much enjoyed working both with you all and the
framework you've created. I believe JavaFX is a surprisingly good fit for
the Bitcoin community, because we suffer quite badly from the limitations
and problems of web apps. HTML5 + decentralisation don't mix very well. A
plain old desktop app works better, and JavaFX is a good way to build such
things.

thanks,
-mike

Re: Tagging UI control

[Mike Hearn]

I've not encountered one, but building such a thing should be quite
straightforward. You could use CSS to create a text-area like rectangle
with an HBox inside it, and then have a no-border textedit that simply
expands to fill the available space. When the user presses enter you create
an appropriately styled label with the contained text and insert it to the
left of the edit in the hbox. Tweak CSS and spacing and you have a basic
tagging control.

On Mon, Sep 8, 2014 at 10:02 AM, Robert Krüger krue...@lesspain.de wrote:

 Hi,

 how would one go about implementing (i.e. use which api) a tagging
 control (e.g. like http://xoxco.com/projects/code/tagsinput/) in JFX
 or is this already available in an existing extension library?

 Is this easily done with a bit of text parsing and CSS magic or as
 fiddely as building a rich text editor or does it even make sense to
 build this by integrating a web component and using an existing
 javascript-based solution (which feels a bit odd)?

 Thanks in advance for any opinions/pointers.

 Robert

Image decoding - native or java?

[Mike Hearn]

If I load image bits into an Image how is the decoding done? Is this using
native code and if so there is a way to swap out the decoding engines for
ones written in Java? I see native image libraries in my JRE lib directory
so I suspect the answer is, they're decoded in C.

I ask because I'm loading images provided by third parties of unknown
providence into my app (images embedded in files users may open), and I
know it's been a while since the last round of image decoding bugs but I'd
feel better if I knew there was no possibility of all the usual C exploits
happening.

Re: outstanding resource locks

[Mike Hearn]

I see this message quite frequently. What sort of things do you need in
these bug reports?


On Tue, Sep 2, 2014 at 5:38 PM, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:

 Any time you see this message, it isn't your fault. Rather this is a bug
 in the JavaFX runtime. Please file a JIRA.

 -- Kevin



 Mario Ivankovits wrote:

 Hi!

 Is there anything further I can do to see which resources are locked so I
 can see if this is my fault and to release them properly?
 How to interpret this output?

 Thanks for any info.

 Outstanding resource locks detected:
 ES2 Vram Pool: 76.571.592 used (28,5%), 76.571.592 managed (28,5%),
 268.435.456 total
 118 total resources being managed
 average resource age is 540,5 frames
 57 resources at maximum supported age (48,3%)
 6 resources marked permanent (5,1%)
 2 resources have had mismatched locks (1,7%)
 2 resources locked (1,7%)
 79 resources contain interesting data (66,9%)
 0 resources disappeared (0,0%)

 Outstanding resource locks detected:
 ES2 Vram Pool: 141.193.956 used (52,6%), 141.193.956 managed (52,6%),
 268.435.456 total
 136 total resources being managed
 average resource age is 467,8 frames
 57 resources at maximum supported age (41,9%)
 6 resources marked permanent (4,4%)
 5 resources have had mismatched locks (3,7%)
 5 resources locked (3,7%)
 82 resources contain interesting data (60,3%)
 0 resources disappeared (0,0%)


 Best regards,
 Mario

Re: outstanding resource locks

[Mike Hearn]

OK. What is the impact of the bugs? I haven't noticed any obvious problems
when it occurs. Sounds like a GPU resource leak of some kind?


On Tue, Sep 2, 2014 at 6:24 PM, Kevin Rushforth kevin.rushfo...@oracle.com
wrote:

  Ideally we need a reproducible test case with a set of instructions to
 demonstrate the bug. I know this can be a challenge for an intermittent bug.

 -- Kevin



 Mike Hearn wrote:

 I see this message quite frequently. What sort of things do you need in
 these bug reports?


 On Tue, Sep 2, 2014 at 5:38 PM, Kevin Rushforth 
 kevin.rushfo...@oracle.com wrote:

 Any time you see this message, it isn't your fault. Rather this is a bug
 in the JavaFX runtime. Please file a JIRA.

 -- Kevin



 Mario Ivankovits wrote:

 Hi!

 Is there anything further I can do to see which resources are locked so
 I can see if this is my fault and to release them properly?
 How to interpret this output?

 Thanks for any info.

 Outstanding resource locks detected:
 ES2 Vram Pool: 76.571.592 used (28,5%), 76.571.592 managed (28,5%),
 268.435.456 total
 118 total resources being managed
 average resource age is 540,5 frames
 57 resources at maximum supported age (48,3%)
 6 resources marked permanent (5,1%)
 2 resources have had mismatched locks (1,7%)
 2 resources locked (1,7%)
 79 resources contain interesting data (66,9%)
 0 resources disappeared (0,0%)

 Outstanding resource locks detected:
 ES2 Vram Pool: 141.193.956 used (52,6%), 141.193.956 managed (52,6%),
 268.435.456 total
 136 total resources being managed
 average resource age is 467,8 frames
 57 resources at maximum supported age (41,9%)
 6 resources marked permanent (4,4%)
 5 resources have had mismatched locks (3,7%)
 5 resources locked (3,7%)
 82 resources contain interesting data (60,3%)
 0 resources disappeared (0,0%)


 Best regards,
 Mario

Any plans to support CSS transitions?

[Mike Hearn]

I enjoy iterating on my UI using JFX CSS and a simple hot reload feature I
added to my app, but I still have to drop back into writing code for doing
animations. In practice this means I use fewer nice animations than I
otherwise would, as perfecting them takes longer.

CSS3 has a way to denote transitions of any styleable property. Given that
JFX already has all the infrastructure, has a similar mechanism been
considered for it?

Re: How to set CFBundleVersion?

[Mike Hearn]

Hi Tony,

Please be aware that your messages to this list are getting spamfoldered by
Gmail and likely other providers too. Not much you can do about it other
than ask the OpenJDK list admins to fix their list so it doesn't break DKIM
body hashes. Yahoo has a strict policy and many mailing lists violate it.
Just FYI in case you're wondering if you don't seem to be getting a
response from @gmail/@hotmail users :)


On Mon, Aug 25, 2014 at 8:09 PM, Danno Ferrin danno.fer...@oracle.com
wrote:

 From CLI use the -v flag

 for ant, verbose is an element on the fx:deploy task

 For the new 8u20 API, the bundler argument is verbose and the value is
 true

 On Aug 25, 2014, at 11:10 AM, Tony Anecito adanec...@yahoo.com wrote:

  How do I run verbose with the bundler?
 
  Thanks!
  -Tony
 
 
  On Monday, August 25, 2014 10:53 AM, Danno Ferrin 
 danno.fer...@oracle.com wrote:
 
 
  Not at the moment.  This is a task I hope to get to in 8u40.
 
  It needs to be in the classpath of the ant-javafx.jar in a specific
 place, which I believe is package/macosx/Info.plist.  IIRC the verbose
 output tells you the name.
 
 
  On Aug 25, 2014, at 9:58 AM, Tony Anecito adanec...@yahoo.com wrote:
 
  Yep I meant CFBundleVersion.
 
 
  Does the bundler allow me to specify the location of a info.plst to
 use? That way I can get the one the bundler has created, modify it to
 include the new info.plist with the CFBundleVersion set to what I need and
 then run the bundler to use that info.plist.
 
  Thanks,
  -Tony
 
 
 
 
  On Monday, August 25, 2014 8:47 AM, Danno Ferrin 
 danno.fer...@oracle.com wrote:
 
 
  Do you mean CFBundleVersion?  (no r).
 
  This is a bug for 8u40:  https://javafx-jira.kenai.com/browse/RT-37833
 
  In the mean time I took the info.plist, used the drop-in-resource
 facility, and provided my own template. Then I hand incremented the
 CFBundle.
 
  If you run with verbose set the Info.PList the bundler provides
 internally will be saved to a temp directory, and you can just modify it
 from there.
 
  I can confirm from personal use the workaround I just described works.
 
  On Aug 25, 2014, at 12:23 AM, Tony Anecito adanec...@yahoo.com wrote:
 
   Hi Danno,
  
   How does one set or increment the CFBundlerVersion value? I tried the
 bundleArgument but that did not work.
   When submitting an updated app to Apple itunes this has to be greater
 than the last version which looks lik by default it is 100.
  
   Thanks!
   -Tony
 
 
 
 
 

Re: How to learn the identity of the graphics card?

[Mike Hearn]

Thanks for the tip. Bug filed:

https://javafx-jira.kenai.com/browse/RT-38224

Re: How to learn the identity of the graphics card?

[Mike Hearn]

The card isn't bad per se, it's just the HD4000 integrated graphics chip
that older MacBook's ship with. It's just that I'm very picky about my
framerates :)


On Wed, Aug 6, 2014 at 6:49 PM, Chien Yang chien.y...@oracle.com wrote:

 There isn't a public Java API support for what you want to do. However if
 you are willing to patch JavaFX in your own build, you can add the bad card
 to the GLGPUInfo blackList[] in the GLFactory class of the specific
 platform if you are using the es2 pipe. You will need to dig down into the
 native C++ code if you need to support Windows d3d pipe. This will be a
 little more work see D3DBadHardware.h for the entries. Hope this helps.

 - Chien


 On 8/5/2014 11:39 PM, Peter Penzov wrote:

 Hi All,
 I'm interested how I can get the model of the GPU card using Java. Can
 you show me some basic example?

 BR,
 Peter


 On Wed, Aug 6, 2014 at 3:02 AM, Jim Graham james.gra...@oracle.com
 wrote:

  If there is a card that can't keep up with what we want it to do then we
 should probably be dealing with that on our end as well, whether by
 disabling 3D on that card or by black listing it and just falling back to
 sw pipeline.  We already do that with a number of embedded GPUs...

  ...jim

 On 8/1/14 2:27 AM, Mike Hearn wrote:

  Scott is correct about the determining of the SW pipeline. To add to
 that,
 if knowing whether you are running on SW is sufficient


  Unfortunately for the Intel HD4000 card that some older laptops have,
 it
 technically supports 3D but struggles to do basic shader effects at
 60fps
 when running at high pixel densities. I think I posted about this
 problem
 before. Simpler animations work better (just) but I'd prefer to only
 fall
 back to that when necessary.


   I think the suggestion about starting out assuming that animation
 will be

 OK and then backing off is a good one, if it is practical for your
 application.


  Given that I'll be bundling a JVM with the app anyway I think it'd be
 easier and give a better UX to just patch JavaFX to expose this data
 using
 an API specific to my app. It obviously has it because when running with
 Prism debug logging the info is printed.

Re: How to learn the identity of the graphics card?

[Mike Hearn]

I want to use it for rendering :) I just want to fall back to e.g. a color
adjust instead of a GaussianBlur.


On Wed, Aug 6, 2014 at 8:17 PM, Chien Yang chien.y...@oracle.com wrote:

  Yes, we know that it is a perfectly fine entry level GPU capable of
 supporting JavaFX graphics requirements. I shouldn't use the word bad
 card. What I'm saying is that you will have to add it to your blacklist if
 you don't want JavaFX to use it for rendering due to poor framerate.

 - Chien


 On 8/6/2014 9:57 AM, Mike Hearn wrote:

 The card isn't bad per se, it's just the HD4000 integrated graphics chip
 that older MacBook's ship with. It's just that I'm very picky about my
 framerates :)


 On Wed, Aug 6, 2014 at 6:49 PM, Chien Yang chien.y...@oracle.com wrote:

 There isn't a public Java API support for what you want to do. However if
 you are willing to patch JavaFX in your own build, you can add the bad card
 to the GLGPUInfo blackList[] in the GLFactory class of the specific
 platform if you are using the es2 pipe. You will need to dig down into the
 native C++ code if you need to support Windows d3d pipe. This will be a
 little more work see D3DBadHardware.h for the entries. Hope this helps.

 - Chien


 On 8/5/2014 11:39 PM, Peter Penzov wrote:

 Hi All,
 I'm interested how I can get the model of the GPU card using Java.
 Can
 you show me some basic example?

 BR,
 Peter


 On Wed, Aug 6, 2014 at 3:02 AM, Jim Graham james.gra...@oracle.com
 wrote:

  If there is a card that can't keep up with what we want it to do then we
 should probably be dealing with that on our end as well, whether by
 disabling 3D on that card or by black listing it and just falling back
 to
 sw pipeline.  We already do that with a number of embedded GPUs...

  ...jim

 On 8/1/14 2:27 AM, Mike Hearn wrote:

  Scott is correct about the determining of the SW pipeline. To add to
 that,
 if knowing whether you are running on SW is sufficient


  Unfortunately for the Intel HD4000 card that some older laptops
 have, it
 technically supports 3D but struggles to do basic shader effects at
 60fps
 when running at high pixel densities. I think I posted about this
 problem
 before. Simpler animations work better (just) but I'd prefer to only
 fall
 back to that when necessary.


   I think the suggestion about starting out assuming that animation
 will be

 OK and then backing off is a good one, if it is practical for your
 application.


  Given that I'll be bundling a JVM with the app anyway I think it'd be
 easier and give a better UX to just patch JavaFX to expose this data
 using
 an API specific to my app. It obviously has it because when running
 with
 Prism debug logging the info is printed.

Re: How to learn the identity of the graphics card?

[Mike Hearn]

 Scott is correct about the determining of the SW pipeline. To add to that,
 if knowing whether you are running on SW is sufficient


Unfortunately for the Intel HD4000 card that some older laptops have, it
technically supports 3D but struggles to do basic shader effects at 60fps
when running at high pixel densities. I think I posted about this problem
before. Simpler animations work better (just) but I'd prefer to only fall
back to that when necessary.


 I think the suggestion about starting out assuming that animation will be
 OK and then backing off is a good one, if it is practical for your
 application.


Given that I'll be bundling a JVM with the app anyway I think it'd be
easier and give a better UX to just patch JavaFX to expose this data using
an API specific to my app. It obviously has it because when running with
Prism debug logging the info is printed.

How to learn the identity of the graphics card?

[Mike Hearn]

I'd like to change my animations depending on whether the users GPU can
keep up. For now, I'm OK with some manual string matching on adapter IDs. I
see no way in JavaFX to find out what hardware I'm on. Is there a
different/other way to get this data, via some other Java API?

Re: How to learn the identity of the graphics card?

[Mike Hearn]

 Would it be feasible for you to do some measurements / calibration on the
 system and make the determination based on measured speed? That seems more
 to the point anyway.


I don't know how to do that without actually drawing to the screen, which I
don't want to do.

Re: Mirrored observable collections

[Mike Hearn]

Thanks Tomas! I'm a big fan of your work and blog.

I learned about ReactFX after I started writing my current project, seems
like a very useful abstraction indeed, although so far I've found the basic
JFX stuff to be nearly sufficient (a few more transformers and mirrored
observables were so far all I needed).

Actually I didn't realise ReactFX could do this. I learned about what it
can do by reading the github page which covers many features but doesn't
mention threading anywhere, so I figured it didn't have any support for it.
I should have dug deeper! Maybe you could add a discussion of threading and
how to manage asynchronous state using ReactFX?

Additionally a discussion of debugging would be helpful. My experience so
far is that reactive/streaming code is fun to write and painful to debug
compared to traditional imperative code.

In my UI I use content bindings, so I'd need to (I think) use
EventStreams.merge() to merge the event stream back into a copy of the set,
and at that point the API would be more verbose than
MirroredObservableSet/List. Still ReactFX is clearly a lot more general and
I might well switch to it at some point.

Incidentally the lack of a uni-directional string binding utility in JavaFX
is really annoying: converting a read only observable value into a string
is a really common thing to want to do!

Mirrored observable collections

[Mike Hearn]

I have what I imagine is a fairly typical JavaFX application (once it's
released I'll post more about it). It has a GUI, some mostly asynchronous
state management, and interactions with various servers that can change the
apps state.

At first I tried the simple and obvious approach in which the backend would
schedule closures onto the UI thread using Platform.runLater() when things
changed, sometimes via ad-hoc event handlers or callbacks. But it ended up
getting more and more complicated and unclear. So I ended up rewriting
things to be more actor-ish in which the backend code ran mostly in its own
thread and vended mirrored observables.

I figured mirrored observables are a generally useful concept that probably
JavaFX should have itself.

The idea is simple enough. Given an ObservableList or ObservableSet (I
didn't need map yet), calling a static utility function with that list and
an Executor returns a new list in which all updates run in the context of
that executor. This means a piece of code that's responding to changes in
state held elsewhere e.g. via a network connection which receives updates
from a server can have its own thread, and update its own
ObservableLists/Sets/Maps without thinking about threading as long as the
only public accessors for these collections vend mirrored versions. Note
that mirrors are read-only, I don't attempt to do two-way sync (with
conflict resolution?!). If you want to update the real list you have to
schedule a closure onto the backend thread to do it and wait for the change
to re-propagate to the frontend thread.

Once this is in place, you can then bind the collections to UI controls
using some extra transformers in the standard manner, and everything hangs
together nicely.

The code I'm using is here (Apache licensed, go wild)

   https://gist.github.com/mikehearn/4781ce7f00228762adfb

There are three files. AffinityExecutor is an extended version of the
Executor interface which has a notion of thread ownership (supports short
circuiting and assertions), along with static methods to create:

   1. AffinityExecutors that are bound to a dedicated new thread with a
   task queue.
   2. An AffinityExecutor that queues up tasks but doesn't execute them
   until explicitly requested, this is useful for unit testing.
   3. An AffinityExecutor that wraps Platform.runLater and
   Platform.isFxApplicationThread
   4. An executor that just runs closures immediately on the same thread.

Then ObservableMirrors creates sets/lists in the same way a content binding
would, but which re-applies changes in the given thread or short-circuits
and does so immediately if the listener on the mirror is running on the
same thread as the caller.

There's also a set of static addListener methods in MarshallingObservers
that just relays into the right thread as well, if you only care about
changes and not full content.

Of course you could have an ObservableMirrors equivalent that uses a
regular Java executor, you'd just lose some safety and short circuiting.

Re: JavaFX at JavaOne 2014

[Mike Hearn]

 There are no reasons that JavaFX could not work well on mobile platforms,
 providing there is a JVM. I was convinced that mobile UI toolkits were very
 specific, but it's really not the case. Android UI Toolkit has really very
 few mobile specificities for example.


It's not so much the toolkit, but the layouts. Yes, you could probably make
a JavaFX that runs OK on iOS/Android though the API would be necessarily
incompatible e.g. no inter-application drag and drop, only one stage, no
exposed file system, very different ideas about menus and toolbars etc.

But, you'd still need to design completely new layouts/FXMLs to handle the
different screen sizes and conventions. And that probably means quite some
changes to your controllers, CSS and animation code as well.

In the end, you'd still need two versions of your app. The only difference
is how much knowledge can be reused? Most of the code would be the same.

Re: New bundler in 8u20 question...

[Mike Hearn]

Does the new bundler still create DMGs as well?

 AppName-version-MAS.pkg where the -MAS variant is for Mac App Store,
 this will show up in next weeks build.


Could I suggest -AppStore instead of -MAS, which is a rather opaque
acronym.

Re: How to force pixels to hit the screen?

[Mike Hearn]

 Would that runLater() code always run after the splash image was finished
 being rendered?


Unfortunately I tried this and it doesn't work.

JavaFX has a dual threaded architecture in which all app logic and scene
graph handling happens on the app thread, and the process of drawing a
frame actually just pushes commands onto a render thread which then does
the work of translating into OpenGL or DirectX or whatever the underlying
rendering engine is. Exactly what that data stream looks like I'm not sure,
but my guess as to what is happening (didn't profile it yet) is that my app
does lots of stuff during startup (including starting other threads,
networking events, etc) and the OS doesn't know that the Prism render
thread is special, so it doesn't get scheduled with higher priority vs the
others.

If there was a way to synchronize with the render thread, that would work,
and if there was a way to make the render thread higher priority than the
rest, that might also work. But I'm not enough of a guru (yet) to know the
best way to do this.

How to force pixels to hit the screen?

[Mike Hearn]

I'd like to create my main stage, show some splash widgets, then begin the
slower process of hauling the data and rest of the main UI into memory.
Unfortunately when I do this most of the startup time has the stage being
empty, instead of showing the splash. Introducing some artificial delays
makes it reliably appear, but of course I don't want to slow down startup.

My guess is that the app initialisation work is starving the render thread,
so the pixels for the splash don't hit the screen quickly enough. I tried
using an AnimationTimer to wait for a few pulses, but it didn't work. Ditto
for plain old runLater.

If anyone has ideas, it'd be appreciated.

Re: How to force pixels to hit the screen?

[Mike Hearn]

 As long as you are doing any of the heavy lifting on the FX application
 thread it will necessarily starve the rendering, since the application
 thread is where animation is run and rendering is triggered. Applications
 are encouraged to do computationally expensive tasks or tasks that are
 subject to blocking (e.g., network reads) on a different thread.


Yes, unfortunately one of the heavy tasks is FXMLLoader.load which hits the
threading issues I emailed about earlier.

But I'm not sure I really understand this. I'm OK with my (non interactive)
splash being hung whilst the app thread goes off and do other things, as
long as it was able to draw at least one frame to the screen. Is there any
way to wait for the rendering thread to settle and process the commands
produced by the app thread?

Re: Scene Builder 2.0 released.

[Mike Hearn]

Very nice, thanks!


On Wed, May 14, 2014 at 7:28 PM, Simon Vienot simon.vie...@oracle.comwrote:

 In case some of you missed it, we have just pushed Scene Builder 2.0 live
 [1] yesterday.
 All details on Jasper's nice blog post [2].
 If you have 8 minutes to spare, I encourage you to have a look at this
 demo [3] where FX8 and SB2 shine.

 -Simon

 [1] http://www.oracle.com/technetwork/java/javase/
 downloads/sb2download-216.html
 [2] http://fxexperience.com/2014/05/announcing-scenebuilder-2-0/
 [3] https://www.youtube.com/watch?v=ij0HwRAlCmofeature=youtu.be

Re: Roadmap for javafxpackager?

[Mike Hearn]

Awesome! I'll check it out.

I'm not sure how your versioning scheme works. Does 8u20 mean it will be
released 20 weeks after the original Java 8.0 or something? When is it
expected to go stable?


On Thu, May 15, 2014 at 12:02 AM, Joe McGlynn joe.mcgl...@oracle.comwrote:

 Hi Mike,

 Take a look at the packager in the 8u20 EA builds, it’s significantly
 improved over the original FX Packager.

 We are looking right now at what features we’ll do for the next feature
 update for JDK 8 after 8u20.  I believe icon support should already be
 there in the original FX Packager, and certainly in the 8u20 version.  File
 associations are coming in a future update, certainly very high on the list
 of features we want to address.

 Joe


 On May 14, 2014, at 2:43 PM, Mike Hearn m...@plan99.net wrote:

  I've been looking around for the best way to distribute my app.
  Javafxpackager is a big leap over what Java provided before (nothing) but
  it's still pretty basic. I'm wondering if there's a plan or roadmap for
  improving it. For instance I made a Mac DMG (it works, yay!) but I had to
  manually replace the default icon file: there's apparently no way to
 adjust
  that. Also, no support for configuring file associations etc.
 
  It looks like to get something sophisticated like the Scene Builder
  packaging still requires a lot of platform specific work.

Re: How to deploy JavaFX application writen in JavaScript unsing Nashorn

[Mike Hearn]

It's probably easiest to have a tiny Java app that just loads the JS files
from resources in the JAR and runs it via Nashorn directly. Then all
existing tools like jfxpackager, JWrapper etc can treat it like a Java app.


On Wed, May 7, 2014 at 3:30 AM, Bilal Soidik bilalsoi...@gmail.com wrote:

 Hi!
 As you know, we can write JavaFX application in JavaScript using Nashorn
 Engine, but I have to run application with command line like:  jjs
 app_all.js -fx .
 So I wont know how can I deploy application that let me click on and lunch
 it or make a self-contained application packaging using JDK 7(Update 6 or
 later) packaging tools

 --
 *Bilal Soidiki Mpapandza*
 *Etudiant en Master Spé. Qualité du Logiciel, FS UIT*
 *Ingénieur logiciel et Développeur Java, C/C++,.NET et PHP*
 *Tél.*:*(+212) 602746546*
 *Blog   *:* http://la-lune-1.blogspot.com
 http://la-lune-1.blogspot.com/  *
 *Twitter   *:* bilaalsoidik*
 *Skype   *:* bilalsoidik*

Re: Why can Scene's only be constructed on the UI thread?

[Mike Hearn]

For a Node to have a peer to dispose, it must have been attached to a live
Scene, right, which must be done on the app thread. Requiring nodes to be
removed from a live Stage/Scene on the app thread doesn't seem like a big
deal.

To snapshot you could just throw an exception if someone tries to snapshot
a node that isn't a part of a live scene. Also no big deal.

Then if a Scene's peer is only constructed when it's attached to a live
Stage, there's nothing to do there.

So it seems like it shouldn't be too hard?


On Tue, Apr 29, 2014 at 8:39 AM, Martin Sladecek martin.slade...@oracle.com
 wrote:

 The patch tries to solve the issue by deferring the construction of Scene
 in PopupWindow, but the issues I ran into just show that it's not enough.
 In order to fix RT-17716, we need Scene construction outside of the thread.

 Looking at the Scene code, it seems that there are not that many places
 where app thread is necessary. The Scene's peer is created only when added
 to a Window (which is good), but there are still calls that need to be
 synchronized or transferred to the app thread. Like when a Node is removed
 from a Scene, it's peer is immediately disposed. And also snapshots require
 peers (i.e. Scene in a Window), but I guess we can live with that.
 I'm also not sure about accessibility, maybe the code would need some
 adjustments as well.

 -Martin


 On 04/28/2014 08:18 PM, Kevin Rushforth wrote:

 Some of this was looked at while trying to solve RT-17716 
 https://javafx-jira.kenai.com/browse/RT-17716 (see Martin's patch).

 I think it would be worth considering relaxing the restriction on
 constructing Scene and Window (maybe Stage, but I don't think there is a
 benefit for that one), but it seems that Martin ran into some issues with
 his specific patch.

 -- Kevin


 Richard Bair wrote:

 Hi,

 Actually I don’t know of any reason why Window and Scene cannot be
 created and initialized on any thread. Each of these has a peer, and the
 *peer* we can’t update except on the right thread (or with care, these are
 OS specific restrictions or issues). But I don’t see any reason why the
 Java side cannot be initialized on any background thread. And in fact, that
 was always my intent for exactly these reasons, having experienced all this
 pain in Swing before firsthand.

 Its just work that needs to be done, contributions welcome :-)

 Richard

 On Apr 26, 2014, at 12:48 PM, Tony Anecito adanec...@yahoo.com wrote:

  Hi Tom this is also true for Swing and the EDT. I had heard years ago
 jre 8 was going to address this via 2 drawing threads and modularity but
 jigsaw was delayed and not sure what happened to the 2 drawing thread idea.
 I really wish we could instantiate windows in memory and when needed draw
 them. The user experience and perception of java would be so much better
 for the client side. If someone on the java client side knows how to do
 this I would love to try it to verify it.

 Best Regards,
 Tony Anecito
 On Saturday, April 26, 2014 11:39 AM, Mike Hearn m...@plan99.net
 wrote:

  At e(fx)clipse we have an FXML to Java translator who removes all the
 reflection overhead from FXML. It does not yet support all FXML
 features
 but we are steadily improving it and with test cases we are able to fix
 problems quite fast. Maybe this is an option for you?

  That would be very interesting to try, yes please! Where can I find
 it? My
 project is Java 8 based so that's no problem.

Why can Scene's only be constructed on the UI thread?

[Mike Hearn]

I'm trying (mostly in vain) to optimise the startup time of my app. It
takes about a second to build the main GUI via FXMLLoader.load() - probably
because the GUI is getting a little bit complex but I think mostly because
it's all running interpreted, as it's one of the first things the app does.
Later loads of the same GUI take more like 100-200msec, presumably because
HotSpot went in and compiled it. But that's kind of useless for me. It's
the first load that counts.

So I figured I'd bring up a stage of the right size early with just a logo
and a loading indicator, and load the root Node of my UI on a background
thread so the user has something to look at for a moment whilst it's
hauling itself into memory.

My first attempt was to show the splash and then load the UI. Didn't work
of course, because the UI thread didn't get a chance to render. So then I
put it inside a Platform.runLater which also didn't work, the splash didn't
appear quickly enough.

So then I tried putting it in a background thread. This got the right
splash behaviour but it didn't work out of the box:  my GUI has tooltips
and context menus in it. These attempt to construct a Scene at load time,
which of course fails because it's not on the GUI thread. Once I commented
those out, I got the behaviour I wanted, but of course at the cost of
features.

Given that these Scene's are not being rendered as they're not visible or
interactable, what's the reason they have to be built on the UI thread?

Also does anyone have any advice for making JFX8 apps that start really
fast? I tried parallelising most of the work my app is doing at startup and
annoyingly it hardly helped at all. Not sure why yet: perhaps the JVM or
the operating system is busy using the other core so all my threads get
scheduled onto the same chip.

Re: Why can Scene's only be constructed on the UI thread?

[Mike Hearn]

 At e(fx)clipse we have an FXML to Java translator who removes all the
 reflection overhead from FXML. It does not yet support all FXML features
 but we are steadily improving it and with test cases we are able to fix
 problems quite fast. Maybe this is an option for you?


That would be very interesting to try, yes please! Where can I find it? My
project is Java 8 based so that's no problem.

Re: Expected frame rates for a full-screen blur

[Mike Hearn]

  What version of jdk and Swing did you use?  Can you check it on the
 latest jdk8?


Ah you're right, Swing does hidpi these days. When I made the decision to
start using JFX it didn't. But last time I tried the IntelliJ Oracle JVM
builds the UI was pretty messed up so it seemed to still have some bugs.
But that was maybe 6 months ago or more.

Re: Expected frame rates for a full-screen blur

[Mike Hearn]

OK, now I'm really puzzled - I watched the JavaFX performance talk from
2011 and learned about PeformanceTracker. It's too bad that's not public
API, but it works. I used it like so:

PerformanceTracker tracker = PerformanceTracker.getSceneTracker(scene);
tracker.setOnRenderedFrameTask(new Runnable() {
long lastTimestamp = System.currentTimeMillis();

@Override
public void run() {
final long now = System.currentTimeMillis();
long delta = now - lastTimestamp;
if (delta  1000)
System.out.println(Frame took  + delta + msec);
lastTimestamp = now;
}
});

The 1000 thing is just to avoid printing a nonsense timestamp when the UI
hasn't been touched for a while.

The deltas I see are consistently between 10-20msec which would be between
50 and 60fps, i.e. the vsync of the screen. But the wacky thing is, this
doesn't change when I increase the size of the window, even though the
animation is noticeably more choppy. It still says there's a 10-20msec gap
between frames even though my eyes tell me otherwise. Even when I shrink
the window size right down and get super smooth animation, the above code
prints the same kind of deltas.

This makes me think that whatever is going on, the regular JavaFX drawing
thread isn't the issue. It seems to be churning through the scene at the
same totally acceptable rate no matter what. So I'm thinking the issue must
be something to do with how fast the GPU drains the command queue or
something.

BTW I tried doing -Dprism.order=j2d to see what would happen, and the GUI
hangs before rendering anything. I'll file a bug on that later.


On Thu, Apr 3, 2014 at 11:54 AM, Mike Hearn m...@plan99.net wrote:

 How does the OS tank?


 All the OS animations hit the same frame rate as the app itself does. For
 instance, opening Mission Control is normally smooth, but when a maximized
 JFX app is animating, it's not.

 It feels like the GPU is being overworked but as I'm not a GPU expert at
 all, I'm not sure where to begin - I am not even sure how to find out the
 frame rate so I know when tweaks are improving things! Is there a way to
 get this data from the system?

Re: Expected frame rates for a full-screen blur

[Mike Hearn]

 How does the OS tank?


All the OS animations hit the same frame rate as the app itself does. For
instance, opening Mission Control is normally smooth, but when a maximized
JFX app is animating, it's not.

It feels like the GPU is being overworked but as I'm not a GPU expert at
all, I'm not sure where to begin - I am not even sure how to find out the
frame rate so I know when tweaks are improving things! Is there a way to
get this data from the system?

Re: Expected frame rates for a full-screen blur

[Mike Hearn]

Right. My issue appears to be far more general - any large window has poor
framerates no matter how simple the contents seem to be. What's more it
doesn't seem to be a pure CPU time issue because *all* graphics operations,
even things like opening mission control, also end up lagged. So I feel
it's more likely to be something to do with the GPU, as that is a shared
resource that perhaps isn't being timesliced very well. I can't offer a
better explanation of why an app would be able to drag down the
responsiveness of the entire OS.

I tried changing the blue type, adding cache hints and so on. No
difference. I also found someone else complaining about this:

mihosoft.eu/?p=486

The issue very specifically seems to be large windows. I tried changing the
display resolution as well, but unsurprisingly the only thing that made it
faster was changing the scaling so all windows were smaller. Modifying the
display settings to give me more space just made things worse (larger
window again).

I'm not sure how to go about diagnosing this. Again - does anyone else see
their entire OS tank when the Ensemble coloured circles demo is run?





On Tue, Apr 1, 2014 at 11:16 PM, John Smith john_sm...@symantec.com wrote:

 Sounds like your issue isn't in fact the blur, but, if it were, some
 things suggestions are:

   1. BoxBlurs are more efficient than GaussianBlurs:
 http://en.wikipedia.org/wiki/Box_blur
   2. Apply some of the suggestions from the openjfx Performance Tips and
 Tricks page:
 https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks

 Anecdotally, applying the Performance Tips and Tricks allowed smooth
 animations on a 2012 MacBook Air with a full-screen blur.

 -Original Message-
 From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf
 Of Jeff Martin
 Sent: Tuesday, April 01, 2014 11:17 AM
 To: Mike Hearn
 Cc: openjfx-dev@openjdk.java.net
 Subject: Re: Expected frame rates for a full-screen blur

 I assume retina optimization was added for JFX 8 (or is on the short
 list). I think there is a Jira for it.

 You can choose a non-retina resolution by going to display preferences and
 clicking the Scaled radio button and selecting something to the right of
 Best Resolution (Retina). It used to be that you could option-click the
 Scaled radio button to get a real list of choices, but now you can only
 get that with a 3rd party resolution tool (I think).

 jeff


 On Apr 1, 2014, at 12:49 PM, Mike Hearn m...@plan99.net wrote:

  How do I do that? And won't that make everything blurry? Retina support
 is one reason why I chose JFX. Swing on Retina Macs is pretty much
 unusable, it's like looking through thick plastic.
 
 
  On Tue, Apr 1, 2014 at 7:26 PM, Jeff Martin j...@reportmill.com wrote:
  If it's a MacBook Pro Retina, you might try it with and without retina
 level resolution. I haven't tested JavaFX 8 with retina, but JFX 7 had
 serious problems that would go away when I changed the display to
 non-retina.
 
  jeff
 
 
  On Apr 1, 2014, at 11:41 AM, Mike Hearn m...@plan99.net wrote:
 
   Actually, playing some more, it seems like the poor frame rates I'm
   seeing are not blur related, but rather affect any animation (i.e.
   all rendering) when my main window is maximized. Shrinking the
   window so it's smaller results in smooth animations of any kind.
   This seems to be true no matter how I try and simplify my scene (e.g.
 turning off a tiled background image).
  
   I grabbed Ensemble and tried the circle blur demo. It actually made
   my entire laptop unusable. The entire OS crawled to a halt and fps
   was maybe
   0.3 for everything, not just the Java app. Going back to the main
   menu made things snappy again.
  
   This is a bit disconcerting. Does anyone else see such appalling
   performance impact from the blurred circles demo on their Mac? Is
   this a driver issue, perhaps? Are there any platforms where this
   demo hits a good fps?
  
  
  
   On Tue, Apr 1, 2014 at 6:10 PM, Mike Hearn m...@plan99.net wrote:
  
   Hi there,
  
   On a MacBook Pro with OS X 10.9.2, does anyone have any estimates
   for anticipated frame rates of a full-screen animated blur? I
   noticed that when my window is not maximized, the blur is smooth
   and high frame-rate. When maximized the blur is somewhat choppy.
   Unfortunately I have no clue how much work is really involved in
   GPU blurring and whether I'm being unreasonable to expect that many
   pixels to be blurred per second (this is on a retina display).
  
   Can anyone let me know if it's worth me trying to optimise this or
   whether hardware limitations will mean that realistically I am
 expecting too much.
  
   thanks!
  
 
 

Expected frame rates for a full-screen blur

[Mike Hearn]

Hi there,

On a MacBook Pro with OS X 10.9.2, does anyone have any estimates for
anticipated frame rates of a full-screen animated blur? I noticed that when
my window is not maximized, the blur is smooth and high frame-rate. When
maximized the blur is somewhat choppy. Unfortunately I have no clue how
much work is really involved in GPU blurring and whether I'm being
unreasonable to expect that many pixels to be blurred per second (this is
on a retina display).

Can anyone let me know if it's worth me trying to optimise this or whether
hardware limitations will mean that realistically I am expecting too much.

thanks!

Re: Expected frame rates for a full-screen blur

[Mike Hearn]

Actually, playing some more, it seems like the poor frame rates I'm seeing
are not blur related, but rather affect any animation (i.e. all rendering)
when my main window is maximized. Shrinking the window so it's smaller
results in smooth animations of any kind. This seems to be true no matter
how I try and simplify my scene (e.g. turning off a tiled background image).

I grabbed Ensemble and tried the circle blur demo. It actually made my
entire laptop unusable. The entire OS crawled to a halt and fps was maybe
0.3 for everything, not just the Java app. Going back to the main menu made
things snappy again.

This is a bit disconcerting. Does anyone else see such appalling
performance impact from the blurred circles demo on their Mac? Is this a
driver issue, perhaps? Are there any platforms where this demo hits a good
fps?



On Tue, Apr 1, 2014 at 6:10 PM, Mike Hearn m...@plan99.net wrote:

 Hi there,

 On a MacBook Pro with OS X 10.9.2, does anyone have any estimates for
 anticipated frame rates of a full-screen animated blur? I noticed that when
 my window is not maximized, the blur is smooth and high frame-rate. When
 maximized the blur is somewhat choppy. Unfortunately I have no clue how
 much work is really involved in GPU blurring and whether I'm being
 unreasonable to expect that many pixels to be blurred per second (this is
 on a retina display).

 Can anyone let me know if it's worth me trying to optimise this or whether
 hardware limitations will mean that realistically I am expecting too much.

 thanks!

Re: Expected frame rates for a full-screen blur

[Mike Hearn]

How do I do that? And won't that make everything blurry? Retina support is
one reason why I chose JFX. Swing on Retina Macs is pretty much unusable,
it's like looking through thick plastic.


On Tue, Apr 1, 2014 at 7:26 PM, Jeff Martin j...@reportmill.com wrote:

 If it's a MacBook Pro Retina, you might try it with and without retina
 level resolution. I haven't tested JavaFX 8 with retina, but JFX 7 had
 serious problems that would go away when I changed the display to
 non-retina.

 jeff


 On Apr 1, 2014, at 11:41 AM, Mike Hearn m...@plan99.net wrote:

  Actually, playing some more, it seems like the poor frame rates I'm
 seeing
  are not blur related, but rather affect any animation (i.e. all
 rendering)
  when my main window is maximized. Shrinking the window so it's smaller
  results in smooth animations of any kind. This seems to be true no matter
  how I try and simplify my scene (e.g. turning off a tiled background
 image).
 
  I grabbed Ensemble and tried the circle blur demo. It actually made my
  entire laptop unusable. The entire OS crawled to a halt and fps was maybe
  0.3 for everything, not just the Java app. Going back to the main menu
 made
  things snappy again.
 
  This is a bit disconcerting. Does anyone else see such appalling
  performance impact from the blurred circles demo on their Mac? Is this a
  driver issue, perhaps? Are there any platforms where this demo hits a
 good
  fps?
 
 
 
  On Tue, Apr 1, 2014 at 6:10 PM, Mike Hearn m...@plan99.net wrote:
 
  Hi there,
 
  On a MacBook Pro with OS X 10.9.2, does anyone have any estimates for
  anticipated frame rates of a full-screen animated blur? I noticed that
 when
  my window is not maximized, the blur is smooth and high frame-rate. When
  maximized the blur is somewhat choppy. Unfortunately I have no clue how
  much work is really involved in GPU blurring and whether I'm being
  unreasonable to expect that many pixels to be blurred per second (this
 is
  on a retina display).
 
  Can anyone let me know if it's worth me trying to optimise this or
 whether
  hardware limitations will mean that realistically I am expecting too
 much.
 
  thanks!