Re: Anyone using JMX with JavaFX?

[Robert Krüger]

t;>>>
>>>>>>   cheers,
>>>>>>   dalibor topic
>>>>>>
>>>>>>   On 09.06.2016 00:31, Kevin Rushforth wrote:
>>>>>>   As some of you may be aware, JavaFX has shipped
>>>>>>   a JMX plugin as a
>>>>>>   separate jar file along with the JDK (not part
>>>>>>   of the JRE) in
>>>>>>   /lib/javafx-mx.jar. Development on this
>>>>>>   plugin stopped prior to JDK
>>>>>>   8 being shipped, although we continued to ship
>>>>>>   javafx-mx.jar in JDK 8.
>>>>>>
>>>>>>   Are there any developers that still use this? We
>>>>>>   haven't seen any bug
>>>>>>   reports or had questions on it for quite a
>>>>>>   while. I note that this jar
>>>>>>   file has been gone from JDK 9 ea since build 111
>>>>>>   and we are trying to
>>>>>>   determine how best to address this in JDK 9.
>>>>>>
>>>>>>   Our options are:
>>>>>>
>>>>>>   1) Remove it entirely and drop this tooling
>>>>>> support
>>>>>>
>>>>>>   2) Continue to ship it as a legacy jar file,
>>>>>>   meaning that any use would
>>>>>>   require command line qualified exports to be
>>>>>>   added since it uses
>>>>>>   internal packages
>>>>>>
>>>>>>   3) Turn it into a proper JDK-only module,
>>>>>>   javafx.jmx; it would not be
>>>>>>   one of the default modules, so it would need to
>>>>>>   be added with -addmods.
>>>>>>
>>>>>>   Obviously #1 would be the least amount of work,
>>>>>>   and given that it isn't
>>>>>>   being actively maintained, might be a viable
>>>>>>   solution. If we do need to
>>>>>>   keep it, then #2 might be less effort than #3,
>>>>>>   while still preserving
>>>>>>   the ability for developers to use it. This is
>>>>>>   only used for tooling, so
>>>>>>   requiring qualified exports, as is done for
>>>>>>   Robot and
>>>>>>   PerformanceTracker, is not a problem.
>>>>>>
>>>>>>   Separately, if we don't remove it for JDK 9, we
>>>>>>   probably will deprecate
>>>>>>   it with the intention to remove it in a future
>>>>>>   release.
>>>>>>
>>>>>>   -- Kevin
>>>>>>
>>>>>>
>>>>>>   --
>>>>>>   <http://www.oracle.com> Dalibor Topic | Principal
>>>>>>   Product Manager
>>>>>>   Phone: +494089091214 
>>>>>>   > | Mobile:
>>>>>>   +491737185961 
>>>>>>   >
>>>>>>
>>>>>>   ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 |
>>>>>>   22761 Hamburg
>>>>>>
>>>>>>   ORACLE Deutschland B.V. & Co. KG
>>>>>>   Hauptverwaltung: Riesstr. 25, D-80992 München
>>>>>>   Registergericht: Amtsgericht München, HRA 95603
>>>>>>
>>>>>>   Komplementärin: ORACLE Deutschland Verwaltung B.V.
>>>>>>   Hertogswetering 163/167, 3543 AS Utrecht,
>>>>>> Niederlande
>>>>>>   Handelsregister der Handelskammer
>>>>>>   Midden-Niederlande, Nr. 30143697
>>>>>>   Geschäftsführer: Alexander van der Ven, Jan
>>>>>>   Schultheiss, Val Maher
>>>>>>
>>>>>>   <http://www.oracle.com/commitment> Oracle is
>>>>>>   committed to developing
>>>>>>   practices and products that help protect the
>>>>>> environment
>>>>>>
>>>>>>
>>>>>>   --
>>>>>>   <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>>>>>   Phone: +494089091214  >>>>>   > | Mobile: +491737185961
>>>>>> 
>>>>>>   >
>>>>>>
>>>>>>   ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>>>>>>
>>>>>>   ORACLE Deutschland B.V. & Co. KG
>>>>>>   Hauptverwaltung: Riesstr. 25, D-80992 München
>>>>>>   Registergericht: Amtsgericht München, HRA 95603
>>>>>>
>>>>>>   Komplementärin: ORACLE Deutschland Verwaltung B.V.
>>>>>>   Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>>>>>   Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>>>>>   Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>>>>
>>>>>>   <http://www.oracle.com/commitment> Oracle is committed to
>>>>>> developing
>>>>>>   practices and products that help protect the environment
>>>>>>
>>>>>
>>>>> --
>>>>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>>>> Phone: +494089091214  | Mobile: +491737185961
>>>>> 
>>>>>
>>>>> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>>>>>
>>>>> ORACLE Deutschland B.V. & Co. KG
>>>>> Hauptverwaltung: Riesstr. 25, D-80992 München
>>>>> Registergericht: Amtsgericht München, HRA 95603
>>>>>
>>>>> Komplementärin: ORACLE Deutschland Verwaltung B.V.
>>>>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>>>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>>>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>>>
>>>>> <http://www.oracle.com/commitment> Oracle is committed to developing
>>>>> practices and products that help protect the environment
>>>>>
>>>>
>>> --
>>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>> Phone: +494089091214  | Mobile: +491737185961
>>> 
>>>
>>> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>>>
>>> ORACLE Deutschland B.V. & Co. KG
>>> Hauptverwaltung: Riesstr. 25, D-80992 München
>>> Registergericht: Amtsgericht München, HRA 95603
>>>
>>> Komplementärin: ORACLE Deutschland Verwaltung B.V.
>>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>>
>>> <http://www.oracle.com/commitment> Oracle is committed to developing
>>> practices and products that help protect the environment
>>>
>>
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +491737185961
> 
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

http://lesspain.software
http://kyno.software

Re: Feature matrix

[Robert Krüger]

Superuseful for sure!

On Sun, Jan 17, 2016 at 9:32 PM, Felix Bembrick 
wrote:

> I think developers would find it useful if there was a maintained
> spreadsheet that was kept as current as possible that details each major
> JavaFX feature and the status of its implementation on each platform.
>
> The values could be something like "FULL" (the feature is fully
> implemented and working), "PARTIAL" (the feature is available but is not
> complete or suitable for production apps yet), "NONE" (the feature has not
> been implemented at all yet but will be eventually) and "NEVER" (for
> whatever reason, the feature will never be implemented on this platform).
>
> This would be so helpful for developers targeting multiple platforms to
> know in advance which features are going to work on each platform as
> opposed to banging their head against a wall trying to make a
> non-functional feature work on a particular platform.
>
> Ideally this would be hosted and maintained by Oracle though I suspect
> Gluon would have more information, especially for mobile platforms, and so
> it would be a nice addition to the Gluon website.
>
> Does anyone else think they would find this useful? Could someone from
> Oracle and Gluon please respond?
>
> Felix




-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Future of JavaFX

[Robert Krüger]

Thanks Chien and Kevin. I will recheck my issues with JDK 9 early access
and report back, probably here because I cannot comment in JBS.

On Wed, Dec 2, 2015 at 8:44 PM, Chien Yang  wrote:

> On 12/2/15, 4:46 AM, Robert Krüger wrote:
>
>> How much of a priority are quality issues,
>> especially on the Mac (which clearly is a second-class citizen as far as
>> JavaFX is concerned)? Are things like flashing when opening Stages, bad
>> rendering performance, broken media APIs etc. an issue?
>>
> We have been busy fixing bugs to ensure a high quality release for 9 on
> all supported platforms. Many of our developers have a Mac and it is tested
> weekly. If you found a bug that is still reproducible on the JDK 9 early
> access please file it [1]. We will definitely investigate it.
>
> [1] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report
>
> - Chien
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Future of JavaFX

[Robert Krüger]

Kevin,

thanks for sharing those plans. How much of a priority are quality issues,
especially on the Mac (which clearly is a second-class citizen as far as
JavaFX is concerned)? Are things like flashing when opening Stages, bad
rendering performance, broken media APIs etc. an issue? As far as my
company is concerned, the biggest problem (which resulted in us reluctantly
dropping the idea of a migration of our product to JFX for the time being
after lengthy evaluation) is not so much lack of features but primarily
quality in terms of robustness and user experience and the number of
problems we have run into in almost every area that we did tests in was
what led us to that decision (especially with Mac being our most important
platform).

Is there awareness that there are serious problems of the described kind
that block the adoption of JFX in companies who desperately want to switch?
It's always difficult to judge that by the priorities in Jira but it
appeared to me that in many cases the perception on the Oracle side was
very different, if things like the white flashing problem when opening
windows or the tree view scrolling incorrectly or looping in a media api
not working seemed to be viewed rather like a minor glitch.

People have different requirements and thus different views on the topic of
this thread but I found the analysis and observations in Shay's posting not
very far from that of our own engineering team (no affiliation with him or
his company btw.) for the reasons described above.

Best regards,

Robert


On Wed, Dec 2, 2015 at 1:29 AM, Kevin Rushforth 
wrote:

> 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
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Future of JavaFX

[Robert Krüger]

Please, you're really oversimplifying things, I'm not sure if
intentionally. It's not just coding. In my company I pay people
serious money who do testing and file reproducible test cases with a
qualified analysis of what they observed and what may be the problem and
that's what I have done in the past for JavaFX using my Jira account as
also have a number of other qualified people who were affronted by the
policy changes, which probably resulted in many of them stopping this
because they could no longer follow their Jira tickets including taking
part in discussions there or answering questions by the engineers. If you
don't count these things as meaningful/valuable contributions that make a
difference, I don't really know on what basis to argue anymore. Then I have
to assume, you just don't want to really deal with criticism. Of course
some unqualified ranting in a Jira issue hurts (i.e. consumes resources)
more than it helps but putting the many qualified people (many of them on
this list) all in that category is neither correct, nor a smart move in
anyone's interest.

On Wed, Dec 2, 2015 at 10:45 AM, dalibor topic 
wrote:

> On 01.12.2015 22:58, Markus KARG wrote:
>
>> I actually talk about those people that *did not* invest the time to
>> contribute
>>
>
> Making high quality contributions to open source projects takes a
> considerable amount of humbleness, time and effort. People who aren't able
> or willing to invest the necessary time and effort into making high quality
> contributions are not likely to produce acceptable results - in any open
> source community.
>
> To quote Jono Bacon:
>
> "Low-quality contributors don't bring much other than noise: they are a
> net drain on resources because other good contributors have to take time
> away to support them." [1]
>
> cheers,
> dalibor topic
>
> [1] http://opensource.com/life/15/3/how-to-fire-community-members
>
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +491737185961
> 
>
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
>
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
>
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: OpenGLNode or NativeSurfaceNode

[Robert Krüger]

On Tue, Sep 8, 2015 at 1:30 PM, Edu García  wrote:

> I've seen that, but if I understood that correctly, I need to ship a
> modified version of JavaFX in order for it to work properly on Windows, and
> it continues to be a hack that might or might not work... That is far from
> ideal :)
>
>
it is not too unlikely that that will be your best bet for the time being.
At the moment (Java8) my understanding is that you don't need to use a
modified JRE as the hack with the native window handle currently works IIRC
but that is likely to change in Java9 due to enforcement of invisibility of
non-public api. Then you may have to modify the JRE if no command line
switch is provided to switch this off (which I think they are planning for
a grace period). It is far from ideal as you say but Oracle has not shown
any interest in pursuing this topic, so I don't see that changing soon.

Re: OpenGLNode or NativeSurfaceNode

[Robert Krüger]

On Tue, Sep 8, 2015 at 7:45 AM, Edu García  wrote:

> So, years ago somebody asked on this list if it was possible to have some
> sort of OpenGL or NativeSurface node, to be able to integrate OpenGL or
> DirectX rendering on top of JavaFX (in my case, to embed something like
> LibGDX).
>
> Has any work been done on this at all? If it hasn't, are there any plans to
> support this in the near future? If both answers are negative, is there any
> way of using heavyweight Swing controls on top of JavaFX?
>
> Thanks.
>

I have raised this topic again a few months ago on this list and the answer
was, no, there are no concrete plans, which is a step back compared to the
interest in the topic that was shown e.g. by a JavaOne presentation with a
(still working) hack to render stuff into a JFX using OpenGL by someone
from the JFX team. In addition to that, the person who was in charge of
that, has left Oracle since, so all evidence unfortunately tells us not to
hold our breath waiting for that to happen.

Re: JavaFX graphic performance slow on Mac? Clock app

[Robert Krüger]

On Tue, Jul 7, 2015 at 1:32 PM, Tobias Bley  wrote:

>
>
> Hi,
>
> currently our experiences with JavaFX on Mac are very disappointing. While
> JavaFX on Windows runs very good with low cpu usage, JavaFX on Mac via
> Java 8 doesn’t perform well. I created a little clock app which uses
> between 25% and 80% cpu usage. But what’s the reason for? I though JavaFX
> rendering pipeline works on the graphic device? So why there is such a
> traffic on the CPU?
>
>
Hi,

I had the exact same experience with a super-simple app that just animates
a circle and was not able to get it to run smoothly on the Mac at least not
for window sizes that were not very small and cpu load was also much higher
than expected for an app that only does things which I thought were
accelerated.

See https://bugs.openjdk.java.net/browse/JDK-8088396

Doesn't look very encouraging.

Cheers,

Robert

Re: MediaPlayer - Out of sync video & audio when playing from slow medium

[Robert Krüger]

Well, technically a slow connection should not cause A/V desync. If it
does, I would suspect there is a bug in MediaPlayer. Syncronization should
happen based on media timestamps not based on the time the individual
packets come in. So, if you have a more or less reproducible case, file a
bug report.

My 2c.

Cheers,

Robert

On Fri, May 22, 2015 at 12:25 PM, Rafal Leibzig  wrote:

> Hi, my friends use MediaPlayer in their javafx application to play videos
> (mp4, 50fps) from DVD.
> They have noticed out of sync video/audio in such case.
> Problem doesn't exist when file is loaded from HDD.
> I know that it is because of slow medium like DVD (or poor quality DVD disc
> / bad recording)
>
> My question is what to do in such cases?
>
> My PoC was proxing static files by HttpServer (bundled in JRE) by path: "
> http://localhost/video.mp4";.
> It worked for me, media player plays video correctly with buffering, but
> this solution has disadventeges:
> - more CPU
> - problems with seeking video
> - complexity
>
>
> Any other suggestions?
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: JavaFX JIRA issues moving to JBS on June 5

[Robert Krüger]

Has any progress been made regarding the issues raised by a number of
people (mainly bug report contributors and followers), i.e. are policy
changes regarding JBS accounts or new types of JBS accounts for that
purpose something that is likely? Is anyone in the JFX team lobbying for
this?

On Fri, May 22, 2015 at 1:00 AM, Kevin Rushforth  wrote:

> As previously announced [1] we are in the process of migrating JavaFX bugs
> to the JDK Bug System (JBS) [2] in the JDK project.
>
> The target date for this migration is Friday, June 5. The existing JavaFX
> bug tracker will become permanently read-only on that date, and will be
> decommissioned some time after the transition is complete. After
> javafx-jira.kenai.com is retired, we will explore the feasibility of
> setting up an automatic redirect to bugs.openjdk.java.net so that
> existing URLs will work. In any case, typing in an old RT-n number into
> JBS will open the bug even after it is mapped into the JDK project.
>
> -- Kevin
>
> [1]
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017083.html
> [2] https://bugs.openjdk.java.net/
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Enhancements to 3D for JFX9?

[Robert Krüger]

On Fri, Apr 24, 2015 at 5:27 PM, Donald Smith 
wrote:

> Yes, but then read the rest of the thread.  You really must not rely on
> the theoretical possibility of an XX flag that magically kicks all your
> problems down the road a year or two.  The best time to get all this nailed
> correctly is now.


I understand why you are writing this and in principle I agree. But please
understand that this is not about fixing sloppy programming in a college
project but affects whether we can use a technology for the next few years
where the problems that stop us now may have gone away or otherwise not to
be able to continue our product using Java (at least until we know where
Java/JFX is going) and move to something native instead throwing away huge
investments. The world is just not that simple.



> That flag is not likely to be as extensive and durable as everyone is
> imagining.
>
> OK, so having to patch the JDK to access private API in Java 9 is still a
possible outcome?

Re: Enhancements to 3D for JFX9?

[Robert Krüger]

I agree and we are hesitant. However, if that buys you three or more years
of time to either see if Oracle is making good decisions regarding things
we now build using private APIs as a last resort or if all (for us)
showstopping JFX bugs are fixed by then, this can be a valid option in the
real world, where you have to deliver a product as opposed to now rushing
into a decision to move to a different technology, because Java/JFX cannot
deliver now but  YMMV. It's just balancing risks on a case-by-case basis.

People with complex, successful products like IntelliJ Idea are doing the
exact same thing:

https://github.com/JetBrains/intellij-community/search?utf8=%E2%9C%93&q=%22com.sun%22


On Fri, Apr 24, 2015 at 5:15 PM,  wrote:

> Of course, that flag could easily disappear in JDK10.
>
> Personally, I would be hesitant to rely on a feature that goes against the
> direction that Oracle is taking Java.
>
>
> Neil
>
>
>
>
> From:Robert Krüger 
> To:"openjfx-dev@openjdk.java.net" ,
> Date:04/24/2015 09:36 AM
> Subject:Re: Enhancements to 3D for JFX9?
> Sent by:"openjfx-dev" 
> --
>
>
>
> On Fri, Apr 24, 2015 at 2:19 PM, Tom Schindl 
> wrote:
>
> > Did you read the reply from Phil in the other thread?
> >
> > > There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
> > transition.
>
>
> > So you will not have to maintain a JDK9 build but only start with this
> > thread to still access private APIs and this is something you can
> > clearly control if you install the JDK with your app!
> >
>
> Excellent news! How could I miss that, sorry.
>
>
>
>
> NOTICE *from Ab Initio: This email (including any attachments) may
> contain information that is subject to confidentiality obligations or is
> legally privileged, and sender does not waive confidentiality or privilege.
> If received in error, please notify the sender, delete this email, and make
> no further use, disclosure, or distribution. *




-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Enhancements to 3D for JFX9?

[Robert Krüger]

On Fri, Apr 24, 2015 at 2:19 PM, Tom Schindl 
wrote:

> Did you read the reply from Phil in the other thread?
>
> > There will be a -XX flag in JDK 9 that jigsaw provides to aid in the
> transition.


> So you will not have to maintain a JDK9 build but only start with this
> thread to still access private APIs and this is something you can
> clearly control if you install the JDK with your app!
>

Excellent news! How could I miss that, sorry.

Re: Enhancements to 3D for JFX9?

[Robert Krüger]

On Fri, Apr 24, 2015 at 1:16 PM, Mike Hearn  wrote:

> 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.
>
>
>
patched != bundled. For us this would be quite a step back, having to
maintain our JDK patches/builds. Bundling itself is fine in our business
cases.

Re: Enhancements to 3D for JFX9?

[Robert Krüger]

On Thu, Apr 23, 2015 at 12:50 PM, Mike Hearn  wrote:

>
> I think there are people who are embedding arbitrary OpenGL contexts into
> the JFX scene graph, so you could plug in a third party 3D engine that way.
> Though I guess it'd not work on Windows.
>

since the fix version of RT-36215 was changed from 9 to tbd_major (?) and
given the fact that this currently only works using private API, depending
on if there will be a way to prevent the JRE from enforcing access
restrictions (see separate thread a few days ago), this may mean, people
who do this must work with a patched JDK in the future.

Re: JavaFX JIRA issues moving to JBS

[Robert Krüger]

On Thu, Apr 16, 2015 at 11:02 AM, Mario Torre <
neugens.limasoftw...@gmail.com> wrote:

>
> On the other end, the rules for Author are clear, you need to sign the
> OCA (this is the main pain point, but I believe most of the
> contributors to OpenJFX already have this done anyway, isn't that a
> requirement to use the current JIRA as well?).
>
> No, it isn't. You can just register.
Please note that the main criticism is not that it becomes a problem for
code contributors but for people submitting qualified bug reports including
reproducible test cases, concrete measurements etc. or contribute these
kind of things to issues opened by other people by submitting qualified
comments thus creating value.


> Right now, to even see an OpenJFX bug I need to log in, so I need an
> account. WIth OpenJDK the bugs are accessible so you don't even need
> an account to track an issue, here's an example, where I just picked
> the first random bug I've seen:
>
> https://bugs.openjdk.java.net/browse/JDK-8075204
>
> I can see that without logging in, something I can't do with the
> current bug database, so I don't think the situation is worse really,
> it gives more visibility.
>
>
Yes that is one point that is indeed an improvement and nobody denies that
but it is by far outweighed by the negative consequences of the announced
change and Ryan summarized very precisely why.


> Anyway, I encourage you, if you want a better level of access, to
> start working with us to find a solution, the right forums is the
> "discuss" alias that Dalibor mentioned for a start, and definitely the
> Adoption Group can help out in smoothing the transition.
>

Fair enough but it would still be nice to have someone at Oracle
championing/supporting that in a way on behalf of the JFX community.

Re: JavaFX JIRA issues moving to JBS

[Robert Krüger]

On Thursday, April 16, 2015, Ryan Jaeb  wrote:

> My frustration isn't aimed at anyone on the list, so I hope it didn't seem
> like that.
>
> I don't usually post to the list, but I follow it enough to know that, once
> we see an announcement like the one Kevin delivered, the decision has been
> made and there's no going back.  If I've misinterpreted, I apologize.
> Please correct me.
>
> The thing that's particularly frustrating with this incident is that it's
> going to have a predictable, negative impact on people like me who feel
> like submitting bug reports is the most effect contribution we can make to
> the JavaFX community.  Being told that we should engage the JBS folks after
> the decision has been made isn't acceptable.  Whoever made the decision to
> merge with JBS should already have engaged the JBS folks and advocated for
> changes on behalf of the JavaFX community before the decision was
> finalized.  The message Kevin delivered should have included the results of
> that advocacy.
>
> Regardless, what's done is done.  If we need to have someone engage the JBS
> people to ask for policy changes, I think we'd do well to nominate whoever
> made the original decision.  If they have enough influence to get a project
> merged into the JBS, they're effort will be far more effective than that of
> a random person from the community.
>
> We've been told that Oracle wants to see more participation from the JavaFX
> community.  This is an excellent opportunity for someone with a decision
> making role at Oracle to take action and demonstrate to the community that
> they're willing to help facilitate some of that participation.
>
>
Amen to every single aspect you touch. I believe that summarizes pretty
well how many of us die-hard java desktop/client-side application/product
developers feel.

@Dalibor: An after-the-fact "Not our responsibility, ask over there" is not
exactly how you get your community to feel involved. But Ryan has also
already covered that very well above.

Re: JavaFX JIRA issues moving to JBS

[Robert Krüger]

On Wed, Apr 15, 2015 at 4:54 PM, Richard Bair 
wrote:

> Hi everybody,
>
> Moving to JBS is both good and bad. The good:
>


> The bad:
>
>- Contributing is hard (nay, impossible?) if you are not at least an
>OpenJDK Author
>
>
>
That's really the only (and serious) aspect anyone is complaining about
IIRC. Having everything in one Jira instance does of course make sense.


> This is exactly the issue. We know from the last 20 years that in fact we
> get a huge amount of completely bogus bugs that get filed via
> bugs.java.com (previously bugs.sun.com). Wild stuff from end users like
> “I can’t reboot my computer” and so forth. The concern with JBS (as I
> understand it) was that we’d end up with 10’s or 100,000’s of thousands of
> user accounts, many of which would be one-shot submitters associated with
> bogus issues.
>
>
Understandable. IMHO a certain "seriousness threshold" to reduce the noise
makes sense. What if you at least had a policy where someone in your team
can propose people they know from the mailing list for a while for
accounts? I don't think what's needed is to have a completely open system
with one-click self-registration but don't draw the line where you draw it
now, which means you're missing qualified input from people who are ready
to invest qualified time (e.g. to build test cases and good descriptions of
issues) but do not submit patches.


> One solution would be if Atlasssian had some kind of “guest” mode where
> submitter accounts could be created but they would not show up in lists for
> things like assignees etc so they don’t clutter other views. Another
> solution could be to have a system whereby anybody who submits a good issue
> through bugs.java.com would get an email allowing them to sign up on JBS
> if they had an issue.
>

Yes, something like that would address at least my concerns.


>
> Or, maybe the concern is actually not a problem — since Applets etc would
> point towards bugs.java.com, the only people (hopefully) coming to JBS
> are serious developers, the doors could be opened.
>
> Dalibor would probably know the right alias to discuss the JBS policy, and
> I do believe, personally, that the policy is too restrictive and
> discourages cooperation and needs to be changed. But I also think moving to
> JBS is a good thing for a bunch of other reasons (and cost cutting can’t be
> ignored) and actually I’m looking forward to the ability to browse issues
> without having to get an account (not like I don’t have an account, but I
> mean for all the folks out there who just want to see the issues :-)).
>
>
Your response gives me some hope that you take the feedback seriously. This
is a big thing. Please don't disappoint us by letting this discussion fade
into nirvana without anything being done about that.

Re: JavaFX JIRA issues moving to JBS

[Robert Krüger]

On Wed, Apr 15, 2015 at 8:53 AM, Ryan Jaeb  wrote:

> Do you guys have an estimate for the percentage of current JIRA
> contributors that will no longer be able to participate, in a meaningful
> way, in bug reporting due to this change?  I can't speak for anyone else,
> but I can tell you what a switch to JBS means to me.
>
> I consider myself an OpenJFX user, not an OpenJFX developer.  I contribute
> bug reports, but not patches.  I haven't contributed a ton of bug reports
> (22), but every time I run into a bug I take extra time to isolate the
> issue, create a reproducible example, and file a bug.  I'm careful to be
> polite, honest if I make any mistakes, and I make an effort to follow up
> whenever there's activity on a bug I've reported.
>
> The current bug tracker is a good value proposition for me.  My effort has
> a direct impact on having bugs that I discover fixed, it's easy for me to
> comment on bugs when I feel like I have useful input, I get to vote on all
> the bugs that affect me, and, most importantly, the discussion on many bug
> reports often leads to an acceptable workaround until the bug can be fixed.
>
> Conversely, contributing via JBS is not a good value proposition for me.  I
> won't have an author role, I won't get to comment on bugs, and I won't get
> to vote on bugs.  The process for me to participate is more cumbersome and
> bureaucratic and is going to be far less meaningful than the participation
> that I've become accustomed to with the existing bug tracking system.
>
> Why should I participate in a system where my contributions don't even
> warrant a vote on existing bugs?  Once the switch to JBS happens I'll stop
> reporting minor bugs.  The hassle of using JBS means I'm only going to make
> an effort when I run into a major, showstopping bug.  I don't intend to
> sound like I'm throwing a tantrum.  I'm simply being honest.
>
> For a normal user like me, JBS doesn't make contributing easier, it makes
> it harder.  It doesn't communicate appreciation to small contributors, it
> alienates us.  It's not inviting to new contributors, it's intimidating.
> These things may be ok for a large project like the OpenJDK and it may even
> help stack the bug tracker with veteran developers.  However, I don't think
> JavaFX is in a position to discourage anyone from participating.
>
> Please reconsider the decision to merge with JBS as it's going to have a
> significant, negative impact on normal users like me.


I had not realized that I would not be able to comment on my own or other
issues after this change. That is a major step back for me as well and my
role so far is very similar to Ryan's (I have not contributed code but I
have invested considerable amounts of time preparing bug reports with
reproducible test cases and aiding Oracle devs by adding comments when
requested).

So I am totally with Ryan and Tobias on this. Very bad news.

Re: JavaFX JIRA issues moving to JBS

[Robert Krüger]

On Wed, Apr 15, 2015 at 12:20 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:
>
>
> A JBS account will be needed to directly report new bugs or comment on
> existing bugs. Most application developers will file new JavaFX bugs at
> bugs.java.com [3] just like other JDK bugs. The requirement to get a JBS
> account [4] is to have a role of Author or higher in an OpenJDK Project
> (e.g., jdk9 or openjfx)
>

When I submit a bug there, will I be informed of the resulting Jira Issue
ID in JBS? That's crucial for tracking the things I submit. So far I have
perceived bugs.java.com as a black hole compared to the JFX jira.

Re: Private APIs not usable in Java 9?

[Robert Krüger]

On Wed, Apr 8, 2015 at 11:03 PM, Stefan Fuchs  wrote:

>
> But in all artificial restrictions to implement your own workarounds using
> private apis its another minus on our assessment of the risks involved,
> when investing in the javafx technology. Others are the diminishing plugin
> support by browser vendors and a lack of commitment from oracle for growing
> platforms like android or ios.
> On the other side of the equation is unrestricted access of the
> application to the local filesystem and cpu resources and the rich java
> apis.
>
> Currently the equation still holds in favor of javafx, but is constantly
> evaluated.
>
>
*Exactly* the same situation here. I have been arguing against colleagues
proposing an approach where we keep the non-UI code Java and make the UI
using the native technologies similar to what robovm does for iOS APIs
which works remarkably well but of course has its drawbacks compared to
largely sharing the UI code across platforms but other obvious advantages.
With each of these decisions making it harder to somehow get through the
very long phase of JFX maturing, my case for porting to JFX falls apart
more and more.

Re: Private APIs not usable in Java 9?

[Robert Krüger]

On Wed, Apr 8, 2015 at 9:59 PM, Tomas Mikula  wrote:

> >Should I rely now on all of those fixes
> > to be backported to 8?
>
> Why do you need them to be backported to 8? Just having them fixed in
> 9 should be fine, no? (keeping the private workarounds for 8)
>
> It was a response to the point that I could live with Java 8 for a few
more years if I needed private workarounds. Of course, in theory, if all of
them get fixed in 9 I am fine, but if there is a period of time where half
of them are fixed in 9 and the other half can only be worked around on 8,
what do I do with my product?

Re: Private APIs not usable in Java 9?

[Robert Krüger]

- Getting access to the native window to let our video player render into a
JFX screen, to have a video player with features and format support that
can compete with other players on the market (RT-36215), basically
following the example of Steve and Felipe's JavaOne presentation
"Integrating JavaFX with Native Technologies"
- Getting access to the currently displayed table rows by hacking into the
skin, because not being able to do so, would significantly degrade the UX
of our application (RT-39917). This will probably happen for other controls
(list, tree) in the future, when we dive in deeper because, as I understand
it, they share the same limitation.

Those two definitely so far but we have only started evaluating the porting
process and haven't had the time to check if things like RT-37372,
RT-37501, RT-40409 or RT-40379 can be worked around by using private APIs,
still hoping some of that will be fixed before we need to do something
about it ourselves.

On Wed, Apr 8, 2015 at 10:05 PM, Danno Ferrin 
wrote:

>
> > On Apr 8, 2015, at 1:52 PM, Robert Krüger  wrote:
> >  our only workaround is to use private API
>
> 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.




-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Private APIs not usable in Java 9?

[Robert Krüger]

exactly. I don't give a  about Unsafe but I have to deal with the
realities of Java(FX) in its current state and as long as bugs or
limitations that simply make it impossible to ship a product that can
compete with others in our market sit there for months or years and our
only workaround is to use private API and that is taken away then we only
have the choice to move to another technology, which we do not really want
to do. Luckily we are in a better position than Stefan still being able to
modify the JRE in those emergencies but I absolutely see his point.

Your point about Java 8 being available for a long time is moot in a JFX
context as we all know that JFX is very much in motion and needs to be,
because it is far from mature. _All_ of my 6 open issues in Jira plus some
others I am watching because we have run tinto them as well haven been
scheduled for Java 9. _All_ of them are either serious problems or even
showstoppers for products of ours. Should I rely now on all of those fixes
to be backported to 8?


On Wed, Apr 8, 2015 at 9:21 PM, Stefan Fuchs  wrote:

> Hi,
>
> you are right, there are still years to the end of public updates to JDK
> 8   We can use them to migrate to other technologies.
>
> - Stefan
>
>
>
>  Making any theoretical flag available to the deployment side would
>> entirely miss the point.
>>
>> Let me be blunt -- sun.misc.Unsafe must die in a fire.  It is -- wait for
>> it -- Unsafe.  It must go.  Ignore any kind of theoretical rope and start
>> the path to righteousness _*/now/*_. It is still years until the end of
>> public updates to JDK 8, so we have /*years */to work this out properly.
>> But sticking our heads in the collective sands and hoping for trivial work
>> arounds to Unsafe is not going to work.  If you're using Unsafe, this is
>> the year to explain where the API is broken and get it straight
>>
>> Please help us kill Unsafe, kill Unsafe dead, kill Unsafe right, and do
>> so as quickly as possible to the ultimate benefit of everyone.
>>
>>  - Don
>>
>> On 08/04/2015 2:56 PM, Stefan Fuchs wrote:
>>
>>> Hi,
>>>
>>> then I can only hope, that this flag is available to webstart
>>> applications.
>>> Webstart applications have no control over the installed jre. In the
>>> past we encountered various bugs in the jre, which required using internal
>>> apis for workarounds.
>>> For example in some releases of Java 7 the swing gui thread did not
>>> start unless hacking internal apis (see https://javafx-jira.kenai.com/
>>> browse/RT-31205 for details). If such an error occurs again in the
>>> future and we are no longer able to hack around the problem, our only
>>> choice to keep our business alive, is to discourage users from upgrading to
>>> newer versions of the jre, exposing them to security risks.
>>>
>>> - Stefan
>>>
>>>
>>>
>>>> >  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'

Re: Private APIs not usable in Java 9?

[Robert Krüger]

OK, while I wrote this, all the other replies came in. So I see that your
recommendation for the cases I mentioned is then to patch OpenJDK and
submit Jira issues. Fair enough.

Regarding Jira issues, we are already doing that. Regarding code
contribution, this is a different thing, because in many cases a hack to
expose something that should be there is quick but designing a consistent
API that exposes the missing things is often something that requires a
different qualification.


>

Re: Private APIs not usable in Java 9?

[Robert Krüger]

OK, if that statement holds true it is not too unlikely it will be the
death of our plans to migrate to JFX (which I am trying to convince my
partners of). I am aware that using private APIs is a last resort and we
don't do that if we don't have to. Realistically the pace at which JFX
(which we think is a great technology btw.) matures, it is currently the
only way to handle the risk of running into something that does not work
(yet), which has happened to me many times just beginning to dive into
migration. Simply stating "it's not a good idea to do this" and hoping it's
going to work is ignoring the facts and I will probably not bet my business
on JFX without everything we lose, if enforcement of this is mandatory in
Java 9. Just looking at a few things in Jira, it is obvious that you are
already scheduling rather serious problems to Java 9 and I am not expecting
this to change very soon, because Oracle suddenly doubles the dev resources
for JFX. Taking away this (admittedly very ugly) way for developers to help
themselves at their own risk (in many cases until something is
fixed/implemented in the JDK by Oracle, which, of course, takes more time
than a hack) is IMHO not a good idea in the current phase of JFX. You will
probably lose yet more originally very interested software vendors who will
disappointedly move to native technologies because they simply cannot
deliver the product they want/have to, although they'd rather use Java
(FX). But, of course, it's your decision and legitimate to do it either
way. I'm just trying to show you a side here (that I think a number of
other ISVs here on the list know), that might need a little lobbying.

On the other hand, I would guess that deactivating the enforcement of this
in OpenJDK will probably not be too difficult anyway, so if you decide not
to offer to make this configurable one could find a way by building a
modified OpenJDK and shipping that but it would be nicer if Oracle would
acknowledge that this helps some people at this stage and offer it. After
all some of those people are JFX lobbyists out there and there are not many
at the moment compared to the competing technologies.

It all may be a different situation a few years from now when JFX has
matured and seen a few thousand serious commercial applications built on
top of it.

On Wed, Apr 8, 2015 at 6:25 PM, Joe McGlynn  wrote:

> This is unrelated to FX, no Java applications will be able to use private
> APIs in JDK 9.  There _may_ be a temporary compatibility mode, but clearly
> use of them is not something you should plan on regardless of UI technology.
>

Private APIs not usable in Java 9?

[Robert Krüger]

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 as we will
probably have to use 9 at some point because many things now scheduled for
9 will not get fixed in 8 and we will most likely still need workarounds
using private API, at least that's what my current experience with JFX
tells me.

Please tell me that this was a misunderstanding (maybe meant for the
general case where one does not ship the JRE) or a non-engineering source
that simply made mistake.

Best regards and thanks in advance,

Robert

Re: Canvas performance on Mac OS

[Robert Krüger]

derlying graphics systems but I do
>>>>>>> think there's a bug here.
>>>>>>>
>>>>>>> Will file a Jira if I can contribute a bit more than "feels slow"
>>>>>>> ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  On Sat, March 28, 2015 10:06, Robert Krüger wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> This is consistent with what I am observing. Is this something
>>>>>>>> that Oracle
>>>>>>>> is aware of? Looking at Jira, I don't see that anyone is working
>>>>>>>> on this:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%
>>>>>>>> 20%2
>>>>>>>> 2In%
>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20A
>>>>>>>> ND%2
>>>>>>>> 0la
>>>>>>>> bels%20in%20(performance)
>>>>>>>>
>>>>>>>> Given that one of the One of the main reasons to use JFX for me
>>>>>>>> is to be able to develop with one code base for at least OSX and
>>>>>>>> Windows and
>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>
>>>>>>>> "JavaFX is a set of graphics and media packages that enables
>>>>>>>> developers to design, create, test, debug, and deploy rich client
>>>>>>>> applications that operate consistently across diverse platforms"
>>>>>>>>
>>>>>>>> and the fact that this is clearly not the case currently (8u40)
>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>> performance/quality problems on the Mac, I am a bit unsure what
>>>>>>>> to make of all that. Is Mac OSX a second-class citizen as far as
>>>>>>>> dev resources are concerned?
>>>>>>>>
>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>> performance that can be tracked?
>>>>>>>>
>>>>>>>> I will file an issue with a simple test case and hope for the
>>>>>>>> best.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>  Possibly related:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX between
>>>>>>>>>   drawing a wireframe polygon on a Canvas using a series of
>>>>>>>>> gc.strokeLine(double x1, double y1, double x2, double y2)
>>>>>>>>> commands versus using a single gc.strokePolygon(double[]
>>>>>>>>> xPoints, double[] yPoints, int count) command.
>>>>>>>>>
>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>
>>>>>>>>> This is reproducible in a little GitHub JavaFX benchmarking
>>>>>>>>> project I've
>>>>>>>>> created: https://github.com/chriswhocodes/DemoFX
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Build with ant
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Run with:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # use strokeLine
>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> # use strokePolygon
>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>> result: 6 (six) fps
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM
>>>>>>>>> /
>>>>>>>>> Radeon
>>>>>>>>> 6970M 1024MB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Looking at the code paths in
>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints,
>>>>>>>>>   true, NGCanvas.STROKE_PATH) which involves significantly more
>>>>>>>>> work with adding to and flushing a GrowableDataBuffer.
>>>>>>>>>
>>>>>>>>> I've not had time to dig any deeper than this but it's surely a
>>>>>>>>> bug when building a poly manually is 10x faster than using the
>>>>>>>>> convenience method.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  In my opinion the whole graphics performance on MacOSX
>>>>>>>>>> isn’t good at all with JavaFX….
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  Am 27.03.2015 um 22:10 schrieb Robert Krüger
>>>>>>>>>>> :
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The bad full screen performance is without the arcs. It is
>>>>>>>>>>> just one call to fillRect, two to strokeOval and one to
>>>>>>>>>>> fillOval, that's all. I will build a simple test case and
>>>>>>>>>>> file an issue.
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>  Hi Robert,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Please file a Jira issue with a simple test case.  Arcs
>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>> predetermined shader, but it shouldn't be that slow.
>>>>>>>>>>>> Something else may
>>>>>>>>>>>> be going on.
>>>>>>>>>>>>
>>>>>>>>>>>> Another test might be to replace the arcs with rectangles
>>>>>>>>>>>> or ellipses and see if the performance changes...
>>>>>>>>>>>>
>>>>>>>>>>>> ...jim
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert Krüger wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>  Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>> AnimationTimer
>>>>>>>>>>>>> and Canvas where the canvas just performs a few draw
>>>>>>>>>>>>> operations, i.e. fills the screen with a color and then
>>>>>>>>>>>>>   draws and fills 2-3 circles and I have already
>>>>>>>>>>>>> observed that each drawing operation I add, results in
>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs in
>>>>>>>>>>>>> addition to the circles, the CPU load goes up to 30-40%
>>>>>>>>>>>>> on a Mac Book Pro
>>>>>>>>>>>>> for a Canvas size of 600x600(!).
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now I tested the animation in full screen mode (only
>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>> serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>> performance known to be very bad on Mac or
>>>>>>>>>>>>> am I doing something wrong? Are there workarounds for
>>>>>>>>>>>>> this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Robert Krüger
>>>>>>>>>>> Managing Partner
>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Robert Krüger
>>>>>>>> Managing Partner
>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> www.lesspain-software.com
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Canvas performance on Mac OS

[Robert Krüger]

Hi,

On Sat, Apr 4, 2015 at 10:31 PM, Chris Newland 
wrote:

> Hi Jim,
>
>
>
-snip


> I think my question is:
>
> Does the OpenJFX group think JavaFX is a suitable technology for full
> frame rate canvas-style graphics or is the degree of indirection between
> application code and the graphics hardware just too great?
>
>
I think there is also a general problem not related to 2d drawing at least
on 10.10.2. For RT-40377 I created a simple node-based alternative which is
animating _one_ circle and in full-screen mode I get 25-35 fps on my retina
MBP. Maybe it's unrelated but maybe there is an additional throttle
somewhere also affecting your case.


> I would have expected the hardware I've tested on to eat 2500 triangles at
> 60fps for breakfast even with no GPU acceleration.
>
>
Yes, for my case with one circle I would have expected almost no CPU but I
still get 15% which I find quite a bit for rendering one circle 30
times/sec.


> I'm going to knock up a version of this code that uses Graphics2D for
> comparison.
>
>
If you do that, please also include numbers for running that code with
Apple Java 6 as well, because there are quite a few people still saying
that Apple's Java 6 outperforms Oracle's Java by a lot in 2D Graphics.


> Cheers,
>
> Chris
>
>
I don't know what else to do but to lobby here and invest some work in Jira
issues with reproducible test cases. There is a huge performance problem on
the Mac (I have to admit, I have no Windows machine to compare myself) with
the potential to drive companies like ours, which is seriously
considering/testing the technology for our product development, away from
the technology. I would also hope that other people who have encountered
this like the Ultramixer guys don't give up on this and keep posting
qualified information, making the case for this and supporting the Oracle
team by reproducible benchmarks/test cases.

Cheers,

Robert

Re: Media API question regarding metadata retrieval

[Robert Krüger]

On Thu, Apr 2, 2015 at 6:16 PM, David DeHaven 
wrote:

>
> > > If not is there a specific reason not
> > > to offer this functionality independently of a player?
> >
> > There were plans, there were also issues as we don't have a Java based
> mp4 parser so we're relying on the underlying platforms (e.g. QTKit,
> AVFoundation, etc..) to provide that data, which basically means we're
> creating a player at the native level anyways. If you're using the horribly
> outdated FXM format you get the benefit of a Java
> >
> > Deferring to native code absolutely makes sense but I didn't think that
> you needed to create a player to obtain duration, width and height in
> AVFoundation either.
>
> No, but for the lack of a separate interface for metadata retrieval. In
> hindsight there were a number of things that should have been done
> differently :/
>
>
Alright, understood. No offense intended btw.. Thanks for taking the time
to explain!

Re: Media API question regarding metadata retrieval

[Robert Krüger]

On Wed, Apr 1, 2015 at 10:50 PM, Scott Palmer  wrote:

> I seems like a decent compromise to defer to the native platform code that
> will ultimately be used to process the file anyway.  It seems a little
> heavy, but the alternative is perhaps bloating the JavaFX API.
>
>
Yes absolutely but ... (see my reply to David).


> It likely makes more sense to use the MediaInfo project with some JNA
> bindings (you can probably find either JNI or JNA bindings on the web) if
> you need access to the metadata:
> https://mediaarea.net/nn/MediaInfo
>
>
Yes, also agreed for real general-purpose metadata retrieval like in a
broadcast or media converter product, it does not make sense to kick off
such a huge project in Java, when there is already native code around for
that and we are doing that already in one of our products using JNI. I am
talking about the super-simple cases where I am fine with the (very
limited) format support of JavaFX and I just want to know duration, width
and height basically for those files and I do not want to ship native libs
with my cross-platform app which otherwise works well enough with pure
Java. I just don't see any technical reason to instantiate a player for
that in any native framework I know and it should not be necessary in
JavaFX IMHO. Of course I can wrap all that in my own library and probably
will and then the fact that a player is instantiated and then thrown away
is just an implementation detail, I just did not and still do not see why
this is necessary or sensible, which is why I asked.


> I keep thinking a pure java port of MediaInfo would be cool... but
> probably not worth the time :-)
>
>
Yes, I agree and it's doable but A LOT of work (if you want to have the
level of completeness and maturity of MediaInfo) and therefore not likely
to happen anytime soon.

Re: Media API question regarding metadata retrieval

[Robert Krüger]

On Wed, Apr 1, 2015 at 9:48 PM, David DeHaven 
wrote:

>
> > I was a bit surprised that the metadata retrieval functionality
> > of javafx.scene.media.Media is only usable in conjunction with a player,
> so
> > if I want to retrieve the dimensions of a video file I have to
> instantiate
> > a player and wait for it to reach ready state? That's how I read the
> > javadoc. Is this a misunderstanding?
>
> Nope, currently you have to create a player. Once a player is created it
> kicks off a parser to grab metadata or waits for the underlying native
> player to parse.
>
>
> > If not is there a specific reason not
> > to offer this functionality independently of a player?
>
> There were plans, there were also issues as we don't have a Java based mp4
> parser so we're relying on the underlying platforms (e.g. QTKit,
> AVFoundation, etc..) to provide that data, which basically means we're
> creating a player at the native level anyways. If you're using the horribly
> outdated FXM format you get the benefit of a Java


Deferring to native code absolutely makes sense but I didn't think that you
needed to create a player to obtain duration, width and height in
AVFoundation either.

Media API question regarding metadata retrieval

[Robert Krüger]

Hi,

I was a bit surprised that the metadata retrieval functionality
of javafx.scene.media.Media is only usable in conjunction with a player, so
if I want to retrieve the dimensions of a video file I have to instantiate
a player and wait for it to reach ready state? That's how I read the
javadoc. Is this a misunderstanding? If not is there a specific reason not
to offer this functionality independently of a player?

Best regards,

Robert

Re: Packaging a JFX app in a gradle build system

[Robert Krüger]

thanks.

On Sat, Mar 28, 2015 at 4:30 PM, Scott Palmer  wrote:

> I believe the bitbucket repo is the main page. At least the bintray page
> points to it.
>
> Scott
>
> On Mar 28, 2015, at 11:10 AM, Robert Krüger  wrote:
>
> Which repository is the master? Bitbucket or github? I just saw a posting
> by someone mentioning that it is also on github.
>
> On Fri, Mar 27, 2015 at 7:27 AM, Robert Krüger 
> wrote:
>
>> On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer 
>> wrote:
>>
>>> I am successfully using the javafx gradle plugin to produce a packaged
>>> app on Windows and Linux. (Thanks Danno!)
>>> I haven't tried much with Mac yet, but I believe it will make an
>>> application bundle.
>>>
>>>
>> That sounds great. I will give it a try on OSX then.
>>
>>
>>> Oracle should be making this part of your day job, Danno.  Who do I need
>>> to bribe? :-)
>>>
>>>
>> Absolutely! Easy packaging (i.e. well integrated into a build process),
>> especially if it's cross-platform, is a big thing to make JavaFX more
>> attractive to developers.
>>
>
>
>
> --
> Robert Krüger
> Managing Partner
> Lesspain GmbH & Co. KG
>
> www.lesspain-software.com
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Packaging a JFX app in a gradle build system

[Robert Krüger]

Which repository is the master? Bitbucket or github? I just saw a posting
by someone mentioning that it is also on github.

On Fri, Mar 27, 2015 at 7:27 AM, Robert Krüger  wrote:

> On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer  wrote:
>
>> I am successfully using the javafx gradle plugin to produce a packaged
>> app on Windows and Linux. (Thanks Danno!)
>> I haven't tried much with Mac yet, but I believe it will make an
>> application bundle.
>>
>>
> That sounds great. I will give it a try on OSX then.
>
>
>> Oracle should be making this part of your day job, Danno.  Who do I need
>> to bribe? :-)
>>
>>
> Absolutely! Easy packaging (i.e. well integrated into a build process),
> especially if it's cross-platform, is a big thing to make JavaFX more
> attractive to developers.
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Canvas performance on Mac OS

[Robert Krüger]

I have filed this now:

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


On Sat, Mar 28, 2015 at 11:06 AM, Robert Krüger  wrote:

> This is consistent with what I am observing. Is this something that Oracle
> is aware of? Looking at Jira, I don't see that anyone is working on this:
>
>
> https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%20labels%20in%20(performance)
>
> Given that one of the One of the main reasons to use JFX for me is to be
> able to develop with one code base for at least OSX and Windows and the
> official statement what JavaFX is for, i.e.
>
> "JavaFX is a set of graphics and media packages that enables developers to
> design, create, test, debug, and deploy rich client applications that
> operate consistently across diverse platforms"
>
> and the fact that this is clearly not the case currently (8u40) as soon as
> I do something else than simple forms, I run into performance/quality
> problems on the Mac, I am a bit unsure what to make of all that. Is Mac OSX
> a second-class citizen as far as dev resources are concerned?
>
> Tobi and Chris, have you filed Jira Issues on Mac graphics performance
> that can be tracked?
>
> I will file an issue with a simple test case and hope for the best.
>
>
>
>
> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland  > wrote:
>
>> Possibly related:
>>
>> I can reproduce a massive (90%) performance drop on OSX between drawing a
>> wireframe polygon on a Canvas using a series of gc.strokeLine(double x1,
>> double y1, double x2, double y2) commands versus using a single
>> gc.strokePolygon(double[] xPoints, double[] yPoints, int count) command.
>>
>> Creating the polygons manually with strokeLine() is significantly faster
>> using the ES2Pipeline on OSX.
>>
>> This is reproducible in a little GitHub JavaFX benchmarking project I've
>> created: https://github.com/chriswhocodes/DemoFX
>>
>> Build with ant
>>
>> Run with:
>>
>> # use strokeLine
>> ./run.sh -c 5000 -m line
>> result: 60 (sixty) fps
>>
>> # use strokePolygon
>> ./run.sh -c 5000 -m poly
>> result: 6 (six) fps
>>
>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM / Radeon
>> 6970M 1024MB
>>
>> Looking at the code paths in javafx.scene.canvas.GraphicsContext:
>>
>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, NGCanvas.STROKE_LINE)
>>
>> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, true,
>> NGCanvas.STROKE_PATH) which involves significantly more work with adding
>> to and flushing a GrowableDataBuffer.
>>
>> I've not had time to dig any deeper than this but it's surely a bug when
>> building a poly manually is 10x faster than using the convenience method.
>>
>> Cheers,
>>
>> Chris
>>
>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>> > In my opinion the whole graphics performance on MacOSX isn’t good at
>> > all with JavaFX….
>> >
>> >
>> >> Am 27.03.2015 um 22:10 schrieb Robert Krüger :
>> >>
>> >>
>> >> The bad full screen performance is without the arcs. It is just one
>> >> call to fillRect, two to strokeOval and one to fillOval, that's all. I
>> >> will build a simple test case and file an issue.
>> >>
>> >> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham 
>> >> wrote:
>> >>
>> >>
>> >>> Hi Robert,
>> >>>
>> >>>
>> >>> Please file a Jira issue with a simple test case.  Arcs are handled
>> >>> as a generalized shape rather than via a predetermined shader, but it
>> >>> shouldn't be that slow.  Something else may be going on.
>> >>>
>> >>> Another test might be to replace the arcs with rectangles or ellipses
>> >>> and see if the performance changes...
>> >>>
>> >>> ...jim
>> >>>
>> >>>
>> >>>
>> >>> On 3/27/15 1:52 PM, Robert Krüger wrote:
>> >>>
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>>
>> >>>> I have a super-simple animation implemented using AnimationTimer
>> >>>> and Canvas
>> >>>> where the canvas just performs a few draw operations, i.e. fills the
>> >>>>  screen with a color and then draws and fills 2-3 circles and I have
>> &

Re: Canvas performance on Mac OS

[Robert Krüger]

On Sat, Mar 28, 2015 at 11:22 AM, Chris Newland 
wrote:

> Hi Robert,
>
> I've not filed a Jira yet as I was hoping to find time to investigate
> thoroughly but when I saw your question I thought I'd better add my
> findings.
>
> I believe the issue is in the ES2Pipeline as if I run with
> -Dprism.order=sw then strokePolygon outperforms the series of strokeLine
> commands as expected:
>
> java -cp target/DemoFX.jar -Dprism.order=sw
> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
> Result: 44fps
>
> java -cp target/DemoFX.jar -Dprism.order=sw
> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
> Result: 60fps
>
> Will see if I can find the root cause as I've got plenty more examples
> where ES2Pipeline performs horribly on my Mac which should have no problem
> throwing around a few thousand polys.
>
> I realise there's a *lot* of indirection involved in making JavaFX support
> such a wide range of underlying graphics systems but I do think there's a
> bug here.
>
> Will file a Jira if I can contribute a bit more than "feels slow" ;)
>
> Cheers,
>
> Chris
>
>
Great, thanks!

Re: Canvas performance on Mac OS

[Robert Krüger]

This is consistent with what I am observing. Is this something that Oracle
is aware of? Looking at Jira, I don't see that anyone is working on this:

https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%20labels%20in%20(performance)

Given that one of the One of the main reasons to use JFX for me is to be
able to develop with one code base for at least OSX and Windows and the
official statement what JavaFX is for, i.e.

"JavaFX is a set of graphics and media packages that enables developers to
design, create, test, debug, and deploy rich client applications that
operate consistently across diverse platforms"

and the fact that this is clearly not the case currently (8u40) as soon as
I do something else than simple forms, I run into performance/quality
problems on the Mac, I am a bit unsure what to make of all that. Is Mac OSX
a second-class citizen as far as dev resources are concerned?

Tobi and Chris, have you filed Jira Issues on Mac graphics performance that
can be tracked?

I will file an issue with a simple test case and hope for the best.




On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland 
wrote:

> Possibly related:
>
> I can reproduce a massive (90%) performance drop on OSX between drawing a
> wireframe polygon on a Canvas using a series of gc.strokeLine(double x1,
> double y1, double x2, double y2) commands versus using a single
> gc.strokePolygon(double[] xPoints, double[] yPoints, int count) command.
>
> Creating the polygons manually with strokeLine() is significantly faster
> using the ES2Pipeline on OSX.
>
> This is reproducible in a little GitHub JavaFX benchmarking project I've
> created: https://github.com/chriswhocodes/DemoFX
>
> Build with ant
>
> Run with:
>
> # use strokeLine
> ./run.sh -c 5000 -m line
> result: 60 (sixty) fps
>
> # use strokePolygon
> ./run.sh -c 5000 -m poly
> result: 6 (six) fps
>
> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 / 20GB RAM / Radeon
> 6970M 1024MB
>
> Looking at the code paths in javafx.scene.canvas.GraphicsContext:
>
> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2, NGCanvas.STROKE_LINE)
>
> gc.strokePolygon() maps to writePoly(xPoints, yPoints, nPoints, true,
> NGCanvas.STROKE_PATH) which involves significantly more work with adding
> to and flushing a GrowableDataBuffer.
>
> I've not had time to dig any deeper than this but it's surely a bug when
> building a poly manually is 10x faster than using the convenience method.
>
> Cheers,
>
> Chris
>
> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
> > In my opinion the whole graphics performance on MacOSX isn’t good at
> > all with JavaFX….
> >
> >
> >> Am 27.03.2015 um 22:10 schrieb Robert Krüger :
> >>
> >>
> >> The bad full screen performance is without the arcs. It is just one
> >> call to fillRect, two to strokeOval and one to fillOval, that's all. I
> >> will build a simple test case and file an issue.
> >>
> >> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham 
> >> wrote:
> >>
> >>
> >>> Hi Robert,
> >>>
> >>>
> >>> Please file a Jira issue with a simple test case.  Arcs are handled
> >>> as a generalized shape rather than via a predetermined shader, but it
> >>> shouldn't be that slow.  Something else may be going on.
> >>>
> >>> Another test might be to replace the arcs with rectangles or ellipses
> >>> and see if the performance changes...
> >>>
> >>> ...jim
> >>>
> >>>
> >>>
> >>> On 3/27/15 1:52 PM, Robert Krüger wrote:
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>>
> >>>> I have a super-simple animation implemented using AnimationTimer
> >>>> and Canvas
> >>>> where the canvas just performs a few draw operations, i.e. fills the
> >>>>  screen with a color and then draws and fills 2-3 circles and I have
> >>>> already observed that each drawing operation I add, results in
> >>>> significant CPU load (e.g. when I draw < 10 arcs in addition to the
> >>>> circles, the CPU load goes up to 30-40% on a Mac Book Pro for a
> >>>> Canvas size of 600x600(!).
> >>>>
> >>>>
> >>>> Now I tested the animation in full screen mode (only with a few
> >>>> circles) and playback is unusable for a serious application (very
> >>>> choppy). Is 2D canvas performance known to be very bad on Mac or am
> >>>> I doing something
> >>>> wrong? Are there workarounds for this?
> >>>>
> >>>> Thanks,
> >>>>
> >>>>
> >>>> Robert
> >>>>
> >>>>
> >>>>
> >>
> >>
> >> --
> >> Robert Krüger
> >> Managing Partner
> >> Lesspain GmbH & Co. KG
> >>
> >>
> >> www.lesspain-software.com
> >
> >
>
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Canvas performance on Mac OS

[Robert Krüger]

The bad full screen performance is without the arcs. It is just one call to
fillRect, two to strokeOval and one to fillOval, that's all. I will build a
simple test case and file an issue.

On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham  wrote:

> Hi Robert,
>
> Please file a Jira issue with a simple test case.  Arcs are handled as a
> generalized shape rather than via a predetermined shader, but it shouldn't
> be that slow.  Something else may be going on.
>
> Another test might be to replace the arcs with rectangles or ellipses and
> see if the performance changes...
>
>     ...jim
>
>
> On 3/27/15 1:52 PM, Robert Krüger wrote:
>
>> Hi,
>>
>> I have a super-simple animation implemented using AnimationTimer and
>> Canvas
>> where the canvas just performs a few draw operations, i.e. fills the
>> screen
>> with a color and then draws and fills 2-3 circles and I have already
>> observed that each drawing operation I add, results in significant CPU
>> load
>> (e.g. when I draw < 10 arcs in addition to the circles, the CPU load goes
>> up to 30-40% on a Mac Book Pro for a Canvas size of 600x600(!).
>>
>> Now I tested the animation in full screen mode (only with a few circles)
>> and playback is unusable for a serious application (very choppy). Is 2D
>> canvas performance known to be very bad on Mac or am I doing something
>> wrong? Are there workarounds for this?
>>
>> Thanks,
>>
>> Robert
>>
>>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Canvas performance on Mac OS

[Robert Krüger]

Hi,

I have a super-simple animation implemented using AnimationTimer and Canvas
where the canvas just performs a few draw operations, i.e. fills the screen
with a color and then draws and fills 2-3 circles and I have already
observed that each drawing operation I add, results in significant CPU load
(e.g. when I draw < 10 arcs in addition to the circles, the CPU load goes
up to 30-40% on a Mac Book Pro for a Canvas size of 600x600(!).

Now I tested the animation in full screen mode (only with a few circles)
and playback is unusable for a serious application (very choppy). Is 2D
canvas performance known to be very bad on Mac or am I doing something
wrong? Are there workarounds for this?

Thanks,

Robert

Re: Packaging a JFX app in a gradle build system

[Robert Krüger]

On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer  wrote:

> I am successfully using the javafx gradle plugin to produce a packaged app
> on Windows and Linux. (Thanks Danno!)
> I haven't tried much with Mac yet, but I believe it will make an
> application bundle.
>
>
That sounds great. I will give it a try on OSX then.


> Oracle should be making this part of your day job, Danno.  Who do I need
> to bribe? :-)
>
>
Absolutely! Easy packaging (i.e. well integrated into a build process),
especially if it's cross-platform, is a big thing to make JavaFX more
attractive to developers.

Re: Packaging a JFX app in a gradle build system

[Robert Krüger]

Great! Thanks for the update!

On Thu, Mar 26, 2015 at 7:43 PM, Danno Ferrin 
wrote:

> It’s not abandoned, I’ve just had a lot of work on my day job at the
> moment.
>
> For 8u20 and later you can access most of the new features from the
> builder arguments.  Secondary



> launchers and file associations will require some additions I hope to get
> to in the next month or so.
>

I am not sure I understand this correctly. Does that mean the plugin as it
is now works for 8u40? At the moment I would be more than happy just to be
able to package a runnable application without file associations. What do
you mean by secondary launchers in this context? A second main class in a
build file?

Best regards,

Robert

Packaging a JFX app in a gradle build system

[Robert Krüger]

Hi,

sorry for posting this here but I have tried Stackoverflow and the Oracle
JFX user forum first with no responses.

I am looking for the most sensible way to integrate packaging of a JavaFX
application into my Gradle build.

The plugin at https://bitbucket.org/shemnon/javafx-gradle does not look
like it's maintained and I was wondering if there was a better way than
manually hacking together a command line invocation of javapackager where I
have to manually resolve all the dependency stuff myself.

For OSX packaging I have successfully played around with the gradle plugin
at https://code.google.com/p/gradle-macappbundle/, which offers the level
of convenience that I am looking for but I thought this was something that
was within the scope of the Javapackager shipped with the JDK, which I
would like to use, mainly because it is a supported/maintained piece of
software and supports more than just OSX.

Any advice from people doing similar things or maybe the
Javapackager-Developers?

Best regards,

Robert

Re: The trouble with Skins

[Robert Krüger]

On Mon, Mar 23, 2015 at 7:07 PM, Richard Bair 
wrote:

> tl;dr; I lean toward keeping the Control API as view-agnostic as possible,
> but where view details become essential to the operation of the control,
> then define the Control to always include those specific view details.
>
>
> 
>
> Very interesting discussion, I’m enjoying reading through it. The
> following is a bit of background as to where my head was when we were
> designing this.
>
> In Swing we had a similar concept to the Skins, they were the various UI
> delegates. In theory they allowed you to change the look of a Swing
> component (and they did) — but there were all kinds of “view specific”
> details that leaked into it, and also in the Swing components. With JavaFX,
> I wanted to go down more of a purist route, where the Skin would literally
> do all the UI (view)  and the control would be the controller. OK, the
> Control was a Node because it made more sense conceptually to put a Button
> into a scene graph than to create a Button, associate it with a view, put
> the View into the scene graph, and somewhere stash the controller so you
> could get it back later. And for something like a Button, it works well.
>
> Almost as soon as we’d gone down this road we got into the various
> problems you guys have been discussion around scroll bars and view
> positions. If you’re using the standard UI, then you kind of want to have
> access to these properties so you can get the UX right. However if we add
> these properties to ListView, then it would go down the road of saying
> “ListView displays a list of items and has a scroll bar or at least a
> scroll position and you have convenience API for making certain items
> visible, etc”.
>
> Another very common complaint was about how to go about knowing the size
> of a cell for a specific list view item. You’d really want an API on
> ListView that said “getCell(item)” and then you got the cell, at least
> assuming it was visible, otherwise since it is virtualized it doesn’t make
> a whole lot of sense. But anyway, if you don’t know whether the skin even
> does virtualization, then how can you define these semantics in a way that
> is broadly consistent and usable?
>
> Basically it comes down to having the API on the controller (Control) and
> restricting what kinds of skins can be created per control or having users
> cast the skin to a concrete type and work with the Skin directly for such
> things. If we were a dynamic language we could be dirty and munge the two
> together into a single thing (dynamic properties), but with its own set of
> trade-offs (you have to know what kind of skin you’re dealing with, and if
> you get it wrong, your app breaks).
>
> As time went on we ended up adding more view-specific functionality to the
> controls (even adding view state via the CSS background API etc!!). I don’t
> know what the right answer is for this design question, but where we were
> heading was a place where you would have different UI controls for
> different “classes” of controls. So a ListView with scrollbars is our
> ListView, and a PagingListView or something would probably be different.
> They could have a common base class if we designed it such, otherwise they
> would just have those similarities that are consistent between the two
> classes of control.
>
> That is why I find this actually quite appropriate:
>
> > So Skins prevent us from getting visual details of the Control (such
> > as scroll position, position of item on screen, ...), because it is
> > Skin-specific, but at the same time they fail to customize the look &
> > feel, because visual presentation leaks into the Control anyway.
>
>
> This is the design balance! If you get it wrong, you get exactly what
> you’re saying here.
>
> In the end, I lean toward keeping the Control API as view-agnostic as
> possible, but where view details become essential to the operation of the
> control, then define the Control to always include those specific view
> details.
>
>
Not understanding the discussion in-depth, I just hope that solving issues
like https://javafx-jira.kenai.com/browse/RT-39917 is possible within the
current design. If such limitations are something one has to live with, it
is not possible to create a UX that can compete with other toolkits
including Swing. At the moment this is a brick wall we seem to be hitting
porting our product from Swing to JFX.

Re: Media player maturity (on Mac)

[Robert Krüger]

On Thu, Mar 12, 2015 at 8:48 PM, David DeHaven 
wrote:

>
> > > One more question regarding this. Is it OK to have many instances of
> AudioClip or MediaPlayer if only a few of them actually play stuff or do
> they block audio resources even when they are stopped?
> >
> > You can have as many as memory will allow :) They don’t tie up hardware
> resources until actually playing. I actually recommend pre-loading
> AudioClips to avoid startup latency, especially if they’re fetched remotely.
> >
> > Thanks for the info!
>
> Oh, and if you have a lot of AudioClips, it’s best to spawn a new thread
> to load them up asynchronously, otherwise you could block the main
> application thread which will render the UI unresponsive while it’s
> loading. We’ve seen this happen on a couple occasions...
>
>
Good to know, thanks.


> I wanted to provide a library API to handle pre-loading, but didn’t have
> the time or resources :(
>

I can imagine resources quite stretched for a huge project like this. Maybe
JFX10 then ;-).

MediaPlayer status changes

[Robert Krüger]

Hi,

I don't see anything in the docs stating how status should change in
MediaPlayer, e.g. will reaching end of media trigger a transition from
PLAYING to STOPPED? Will a subsequent call to play() start at the beginning
of the media file or do I need to seek? I was expecting some kind of status
change on end of media but am not seeing any when playing back an audio
sample until the end and when I checked the api doc, I didn't find anything
(e.g. like a state diagram) to check if it's a bug or documented behavior.

Regards,

Robert

Re: Media player maturity (on Mac)

[Robert Krüger]

On Thu, Mar 12, 2015 at 6:02 PM, David DeHaven 
wrote:

>
> > One more question regarding this. Is it OK to have many instances of
> AudioClip or MediaPlayer if only a few of them actually play stuff or do
> they block audio resources even when they are stopped?
>
> You can have as many as memory will allow :) They don’t tie up hardware
> resources until actually playing. I actually recommend pre-loading
> AudioClips to avoid startup latency, especially if they’re fetched remotely.
>

Thanks for the info!

Re: Media player maturity (on Mac)

[Robert Krüger]

On Wed, Mar 11, 2015 at 5:28 PM, David DeHaven 
wrote:

>
> > No, thanks for the hint. I just did and the behavior is a bit better in
> the sense that the sample start is not cut off on subsequent play
> invocations (behaves more or less line instantiating a new mediaplayer for
> each invocation, which is good) but when I loop using setCycleCount the
> sample start is also not clean (seams to be varying, though).
> >
> > For my uses case I will probably need both MediaPlayer and Audioclip,
> because I have typical cases for AudioClip (e.g. short notification sounds)
> and long looping background samples.
> >
> > Wow, I just discovered, that the behavior with the sample start sounding
> different on the first invocation also happens when I play the sample using
> the player integrated in Finder, so I owe you a big apology. I am sorry! I
> can also no longer reproduce the looping failure after my last reboot :-S.
>
> No worries, these things just aren’t supposed to behave that way ;)
>
>
> > Btw. the latency of AudioClip on the Mac (2012 MBP) is not quite low
> enough to implement something like a drum kit using the keyboard. I don't
> know if that is the benchmark you are after or if that is also a limitation
> of the hosting system. I need to test that with other applications. The
> latency I get with AudioClip is good enough for my current use case, though.
>
> Yeah, the current AudioClip implementation actually uses the same engine
> as MediaPlayer, just in a slightly different way. The biggest difference
> (aside from the one-shot interface) is it caches all the audio data in
> memory. If you use uncompressed audio (aiff) it will be a bit faster.
>
> -DrD-
>
>
One more question regarding this. Is it OK to have many instances of
AudioClip or MediaPlayer if only a few of them actually play stuff or do
they block audio resources even when they are stopped?

Re: Media player maturity (on Mac)

[Robert Krüger]

On Wed, Mar 11, 2015 at 5:28 PM, David DeHaven 
wrote:

>
> > No, thanks for the hint. I just did and the behavior is a bit better in
> the sense that the sample start is not cut off on subsequent play
> invocations (behaves more or less line instantiating a new mediaplayer for
> each invocation, which is good) but when I loop using setCycleCount the
> sample start is also not clean (seams to be varying, though).
> >
> > For my uses case I will probably need both MediaPlayer and Audioclip,
> because I have typical cases for AudioClip (e.g. short notification sounds)
> and long looping background samples.
> >
> > Wow, I just discovered, that the behavior with the sample start sounding
> different on the first invocation also happens when I play the sample using
> the player integrated in Finder, so I owe you a big apology. I am sorry! I
> can also no longer reproduce the looping failure after my last reboot :-S.
>
> No worries, these things just aren’t supposed to behave that way ;)
>
>
> > Btw. the latency of AudioClip on the Mac (2012 MBP) is not quite low
> enough to implement something like a drum kit using the keyboard. I don't
> know if that is the benchmark you are after or if that is also a limitation
> of the hosting system. I need to test that with other applications. The
> latency I get with AudioClip is good enough for my current use case, though.
>
> Yeah, the current AudioClip implementation actually uses the same engine
> as MediaPlayer, just in a slightly different way. The biggest difference
> (aside from the one-shot interface) is it caches all the audio data in
> memory. If you use uncompressed audio (aiff) it will be a bit faster.
>
> I already tested uncompressed (wav).

Re: Media player maturity (on Mac)

[Robert Krüger]

No, thanks for the hint. I just did and the behavior is a bit better in the
sense that the sample start is not cut off on subsequent play invocations
(behaves more or less line instantiating a new mediaplayer for each
invocation, which is good) but when I loop using setCycleCount the sample
start is also not clean (seams to be varying, though).

For my uses case I will probably need both MediaPlayer and Audioclip,
because I have typical cases for AudioClip (e.g. short notification sounds)
and long looping background samples.

Wow, I just discovered, that the behavior with the sample start sounding
different on the first invocation also happens when I play the sample using
the player integrated in Finder, so I owe you a big apology. I am sorry! I
can also no longer reproduce the looping failure after my last reboot :-S.

Btw. the latency of AudioClip on the Mac (2012 MBP) is not quite low enough
to implement something like a drum kit using the keyboard. I don't know if
that is the benchmark you are after or if that is also a limitation of the
hosting system. I need to test that with other applications. The latency I
get with AudioClip is good enough for my current use case, though.

@Joe: I am using 10.10.1, just realized I never answered that

Best regards,

Robert


On Wed, Mar 11, 2015 at 2:51 AM, David DeHaven 
wrote:

>
> > anyone doing serious work with the media player on the Mac? I am
> > experimenting and so far I am not getting the impression, this is really
> > something very solid.
> >
> > The first Audio-Sample I tried playing plays fine the first time but
> when I
> > play it for a second time by either issuing stop() followed by play() or
> > seek(new Duration(0) and then play, the playback cuts off a few samples
> at
> > the start (does not happen when I instantiate a new Player for each time
> I
> > want to play it, which does not feel right). You need a suitable audio
> file
> > like a drum beat that starts immediately in the file to notice the
> > difference.
> >
> > If one was to implement simple sample-player-like functionality (not a
> full
> > fledged music sequencer but something that allows timed playback to
> arrange
> > sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to
> > use or do I have to use native APIs? Last time I checked JavaSound, it
> was
> > still an abandoned toy usable only for educational purposes but not for
> > anything else. Don't know if that has changed or if this is even the
> Audio
> > strategy for JFX.
> >
> > Would be great if someone could share experience/opinions in this area.
>
> Have you tried AudioClip instead of MediaPlayer?
>
> -DrD-
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Media player maturity (on Mac)

[Robert Krüger]

Doesn't seem to make a difference if I use u25 or u40.

I can't get any sound file to loop using setCycleCount(INDEFINITE) on u25
or u40 either.

I will probably submit bug reports for this later.


On Mon, Mar 9, 2015 at 6:01 PM, Joe McGlynn  wrote:

> The FX/Media stack is supported, and the media stack on Mac was *just*
> updated in 8u40 to use the newer AVFoundation stack (10.8+ only) instead of
> QtKit.  It’s certainly possible there are bugs, please file a bug report
> with a reproducer case so we can fix them.
>
> <http://www.oracle.com/commitment>
>
> <http://www.oracle.com/commitment>
>
> On Mar 9, 2015, at 9:31 AM, Robert Krüger  wrote:
>
> Hi,
>
> anyone doing serious work with the media player on the Mac? I am
> experimenting and so far I am not getting the impression, this is really
> something very solid.
>
> The first Audio-Sample I tried playing plays fine the first time but when I
> play it for a second time by either issuing stop() followed by play() or
> seek(new Duration(0) and then play, the playback cuts off a few samples at
> the start (does not happen when I instantiate a new Player for each time I
> want to play it, which does not feel right). You need a suitable audio file
> like a drum beat that starts immediately in the file to notice the
> difference.
>
> If one was to implement simple sample-player-like functionality (not a full
> fledged music sequencer but something that allows timed playback to arrange
> sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to
> use or do I have to use native APIs? Last time I checked JavaSound, it was
> still an abandoned toy usable only for educational purposes but not for
> anything else. Don't know if that has changed or if this is even the Audio
> strategy for JFX.
>
> Would be great if someone could share experience/opinions in this area.
>
> Thanks in advance,
>
> Robert
>
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Media player maturity (on Mac)

[Robert Krüger]

Hi,

anyone doing serious work with the media player on the Mac? I am
experimenting and so far I am not getting the impression, this is really
something very solid.

The first Audio-Sample I tried playing plays fine the first time but when I
play it for a second time by either issuing stop() followed by play() or
seek(new Duration(0) and then play, the playback cuts off a few samples at
the start (does not happen when I instantiate a new Player for each time I
want to play it, which does not feel right). You need a suitable audio file
like a drum beat that starts immediately in the file to notice the
difference.

If one was to implement simple sample-player-like functionality (not a full
fledged music sequencer but something that allows timed playback to arrange
sounds on a timeline a bit) in JavaFX, should Mediaplayer be the tool to
use or do I have to use native APIs? Last time I checked JavaSound, it was
still an abandoned toy usable only for educational purposes but not for
anything else. Don't know if that has changed or if this is even the Audio
strategy for JFX.

Would be great if someone could share experience/opinions in this area.

Thanks in advance,

Robert

Re: Media player performance on Mac

[Robert Krüger]

I am running 10.10.1 and the video is a standard h.264 export from FCPX, so
nothing special. I have tried other plain h.264 videos (an iTunes trailer)
with the same result. Have you tried it on Mac?

Another thing that is strange is that files with mov-Extensions do not seem
to be allowed. I had to rename a file to mp4 for it to be accepted. That
feels a bit weird, if the underlying framework is really AVFoundation.

This is the code I used for testing:


import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.FlowPane;
import javafx.scene.media.Media;
import javafx.scene.media.MediaPlayer;
import javafx.scene.media.MediaView;
import javafx.stage.Stage;

import java.util.List;

/**
 * Simple Media Player Example
 */
public class MediaPlayerExample extends Application {

@Override
public void start(Stage stage) throws Exception {
FlowPane pane = new FlowPane();

final List args = getParameters().getRaw();

if(args.isEmpty()){
throw new IllegalStateException("no file specified");
}

final String file = args.get(0);

final Media media = new Media(file);

final MediaPlayer player = new MediaPlayer(media);

MediaView mediaView = new MediaView(player);

mediaView.setOnMouseClicked((e)->{
if(player.getStatus() == MediaPlayer.Status.PAUSED){
player.play();
} else if(player.getStatus() == MediaPlayer.Status.PLAYING){
player.pause();
}
});

mediaView.setFitWidth(800);
mediaView.setFitHeight(600);
pane.getChildren().add(mediaView);

final Scene scene = new Scene(pane);
stage.setScene(scene);
stage.setTitle(getClass().getSimpleName());
stage.sizeToScene();

stage.show();
player.play();
}

public static void main(String[] args) {
launch(args);
}
}



On Wed, Mar 4, 2015 at 8:28 PM, David DeHaven 
wrote:

>
> > I just put a MediaView with a MediaPlayer into a FlowPane and displayed
> it.
> > Playing a Full-HD H.264 file consumes between 40 and 60% of CPU. Playing
> > the same file in Quicktime consumes about 3-4% CPU. What is the reason
> for
> > the dramatic difference? Is the player subsystem not using hardware
> > acceleration for decoding h.264? Is it something else intrinsic to
> > MediaPlayer oder MediaView? I thought 8u40's media support was build on
> top
> > of the AVFoundation framework and thus could compete with native players.
> > Can I set a flag to force hardware acceleration? Is something being done
> > about this? I am a bit worried that an application built on top of this
> > would just eat up our users' battery like crazy.
>
> Can you link a sample of a movie that’s causing that much of a performance
> difference? There will always be a slight difference, but it should not be
> that much.
>
> Could also be helpful to know more details about the environment you’re
> running in. Keep in mind the new AVFoundation code is only supported on
> 10.8 and later due to the lack of certain required APIs in 10.7 and 10.6.
>
> -DrD-
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Media player performance on Mac

[Robert Krüger]

Hi,

I just put a MediaView with a MediaPlayer into a FlowPane and displayed it.
Playing a Full-HD H.264 file consumes between 40 and 60% of CPU. Playing
the same file in Quicktime consumes about 3-4% CPU. What is the reason for
the dramatic difference? Is the player subsystem not using hardware
acceleration for decoding h.264? Is it something else intrinsic to
MediaPlayer oder MediaView? I thought 8u40's media support was build on top
of the AVFoundation framework and thus could compete with native players.
Can I set a flag to force hardware acceleration? Is something being done
about this? I am a bit worried that an application built on top of this
would just eat up our users' battery like crazy.

Best regards,

Robert

Re: TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

I have filed https://javafx-jira.kenai.com/browse/RT-39917 for this in Jira.

On Wed, Jan 28, 2015 at 5:57 PM, Robert Krüger  wrote:

>
>
> On Wed, Jan 28, 2015 at 5:55 PM, Robert Krüger 
> wrote:
>
>> OK, I investigated some more.
>>
>> What is weird is that the same table cell instance (I checked the Object
>> hashcode) is set to different model values while it is still visible, i.e.
>> I get sequences like this in the log, just when I display the table:
>>
>> Updating cell 673139775 from null with Image reference for Row 0
>> Adding Row 0 to image load queue
>> Updating cell 673139775 from Image reference for Row 0 with Image
>> reference for Row 1
>> Adding Row 1 to image load queue
>> Dequeueing image for Row 0
>> Updating cell 673139775 from Image reference for Row 1 with Image
>> reference for Row 2
>> Adding Row 2 to image load queue
>> Dequeueing image for Row 1
>> Updating cell 673139775 from Image reference for Row 2 with Image
>> reference for Row 3
>> Adding Row 3 to image load queue
>> Dequeueing image for Row 2
>> Updating cell 673139775 from Image reference for Row 3 with Image
>> reference for Row 4
>> Adding Row 4 to image load queue
>> Dequeueing image for Row 3
>> Updating cell 673139775 from Image reference for Row 4 with Image
>> reference for Row 5
>> Adding Row 5 to image load queue
>> Dequeueing image for Row 4
>> Updating cell 673139775 from Image reference for Row 5 with Image
>> reference for Row 6
>> Adding Row 6 to image load queue
>> Dequeueing image for Row 5
>>
>> This means that I cannot rely on the same table cell to be used for
>> displaying the content while its row is visible (+ a bit of buffered rows
>> around the visible area) and that means the whole approach will not work.
>>
>> It would really be great if someone from Oracle could comment here. None
>> of this behaviour is documented in the API so it seems that using this is
>> really relying on implementation details and I have found any other options
>> to achieve that. The behaviour of the application as it is
>>
>
> this should be "I have _not_ found ..."
>
>
>> now is that randomly some images are never loaded, because they are
>> quickly removed from the load queue because the cell's content is
>> overwritten while it is still being displayed.
>>
>>
>>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

On Wed, Jan 28, 2015 at 5:55 PM, Robert Krüger  wrote:

> OK, I investigated some more.
>
> What is weird is that the same table cell instance (I checked the Object
> hashcode) is set to different model values while it is still visible, i.e.
> I get sequences like this in the log, just when I display the table:
>
> Updating cell 673139775 from null with Image reference for Row 0
> Adding Row 0 to image load queue
> Updating cell 673139775 from Image reference for Row 0 with Image
> reference for Row 1
> Adding Row 1 to image load queue
> Dequeueing image for Row 0
> Updating cell 673139775 from Image reference for Row 1 with Image
> reference for Row 2
> Adding Row 2 to image load queue
> Dequeueing image for Row 1
> Updating cell 673139775 from Image reference for Row 2 with Image
> reference for Row 3
> Adding Row 3 to image load queue
> Dequeueing image for Row 2
> Updating cell 673139775 from Image reference for Row 3 with Image
> reference for Row 4
> Adding Row 4 to image load queue
> Dequeueing image for Row 3
> Updating cell 673139775 from Image reference for Row 4 with Image
> reference for Row 5
> Adding Row 5 to image load queue
> Dequeueing image for Row 4
> Updating cell 673139775 from Image reference for Row 5 with Image
> reference for Row 6
> Adding Row 6 to image load queue
> Dequeueing image for Row 5
>
> This means that I cannot rely on the same table cell to be used for
> displaying the content while its row is visible (+ a bit of buffered rows
> around the visible area) and that means the whole approach will not work.
>
> It would really be great if someone from Oracle could comment here. None
> of this behaviour is documented in the API so it seems that using this is
> really relying on implementation details and I have found any other options
> to achieve that. The behaviour of the application as it is
>

this should be "I have _not_ found ..."


> now is that randomly some images are never loaded, because they are
> quickly removed from the load queue because the cell's content is
> overwritten while it is still being displayed.
>
>
>

Re: TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

OK, I investigated some more.

What is weird is that the same table cell instance (I checked the Object
hashcode) is set to different model values while it is still visible, i.e.
I get sequences like this in the log, just when I display the table:

Updating cell 673139775 from null with Image reference for Row 0
Adding Row 0 to image load queue
Updating cell 673139775 from Image reference for Row 0 with Image reference
for Row 1
Adding Row 1 to image load queue
Dequeueing image for Row 0
Updating cell 673139775 from Image reference for Row 1 with Image reference
for Row 2
Adding Row 2 to image load queue
Dequeueing image for Row 1
Updating cell 673139775 from Image reference for Row 2 with Image reference
for Row 3
Adding Row 3 to image load queue
Dequeueing image for Row 2
Updating cell 673139775 from Image reference for Row 3 with Image reference
for Row 4
Adding Row 4 to image load queue
Dequeueing image for Row 3
Updating cell 673139775 from Image reference for Row 4 with Image reference
for Row 5
Adding Row 5 to image load queue
Dequeueing image for Row 4
Updating cell 673139775 from Image reference for Row 5 with Image reference
for Row 6
Adding Row 6 to image load queue
Dequeueing image for Row 5

This means that I cannot rely on the same table cell to be used for
displaying the content while its row is visible (+ a bit of buffered rows
around the visible area) and that means the whole approach will not work.

It would really be great if someone from Oracle could comment here. None of
this behaviour is documented in the API so it seems that using this is
really relying on implementation details and I have found any other options
to achieve that. The behaviour of the application as it is now is that
randomly some images are never loaded, because they are quickly removed
from the load queue because the cell's content is overwritten while it is
still being displayed.

On Wed, Jan 28, 2015 at 5:17 PM, Robert Krüger  wrote:

> Yes, and I think there was a mistake in my code. I have it almost working
> and have to analyse now, why it does not work for all cells, which may
> again be my mistake. I will investigate and post an update and if I don't
> find it, I will build a simple test program to illustrate this.
>
> On Wed, Jan 28, 2015 at 5:06 PM, Werner Lehmann <
> lehm...@media-interactive.de> wrote:
>
>> That's strange because then TableView would have to create cells always
>> new instead of reusing them - if they would be reused you would see the
>> updateItem calls you are saying do never occur... As far as I know the
>> number of cells is about as many as you need for one visible page in the
>> tableview plus 2-4 more to facilitate scrolling.
>>
>>
>> On 28.01.2015 15:47, Robert Krüger wrote:
>>
>>> To clarify: I am using the stack approach you describe and I remove it
>>> from the stack when updateItem for a table cell is called that already
>>> has a different item set. Then I remove the already set item from the
>>> stack but that never seems to happen in my example.
>>>
>>
>>
>
>
> --
> Robert Krüger
> Managing Partner
> Lesspain GmbH & Co. KG
>
> www.lesspain-software.com
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

Yes, and I think there was a mistake in my code. I have it almost working
and have to analyse now, why it does not work for all cells, which may
again be my mistake. I will investigate and post an update and if I don't
find it, I will build a simple test program to illustrate this.

On Wed, Jan 28, 2015 at 5:06 PM, Werner Lehmann <
lehm...@media-interactive.de> wrote:

> That's strange because then TableView would have to create cells always
> new instead of reusing them - if they would be reused you would see the
> updateItem calls you are saying do never occur... As far as I know the
> number of cells is about as many as you need for one visible page in the
> tableview plus 2-4 more to facilitate scrolling.
>
>
> On 28.01.2015 15:47, Robert Krüger wrote:
>
>> To clarify: I am using the stack approach you describe and I remove it
>> from the stack when updateItem for a table cell is called that already
>> has a different item set. Then I remove the already set item from the
>> stack but that never seems to happen in my example.
>>
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

OK, hang on. I may have found a mistake and what I described may not
actually have been happening.

On Wed, Jan 28, 2015 at 3:13 PM, Robert Krüger  wrote:

>
> Hi,
>
> On Wed, Jan 28, 2015 at 1:59 PM, Werner Lehmann <
> lehm...@media-interactive.de> wrote:
>
>> Robert,
>>
>> I think Tomas is right, load your thumbnails on demand when updateItem is
>> called for an item with missing thumbnail. You say that the cell of a
>> visible item gets reused for another item. If that is the case I guess that
>> the item is "moved" to another cell. Wouldn't it be possible to have an
>> image property on your items and the lazy loading is done on the item,
>> triggered when the item is passed to updateItem of any cell? That
>
>
> That is exactly what I have implemented but the problem is as described
> above
> - Too many non-visible images are loaded (I could probably live with that
> for a while)
> - I have yet to find a criterion to decide an image is no longer needed
> and thus its loading job needs to be removed from the job stack (see below)
>
>
>> should trigger the demand-loading and it would be robust against the
>> tableview exchanging cells for individual items.
>>
> As to the question when to start or stop lazy loading for items, I would
>> add the load-demands to a stack. Each time the image for a new item is
>> requested it is put to the top of the stack and you have one or more
>> threads processing items on the stack (LIFO). An an image is requested
>> which is already on the stack move it to the top of the stack. If an item
>> is removed from a cell remove it from the stack. That should do it.
>>
>>
> That's what I am doing already.
>
> Regards,
>
> Robert
>
> Werner
>>
>> On 28.01.2015 09:30, Robert Krüger wrote:
>>
>>> Doesn't help. The patterns of this property being changed are just as
>>> unusable for my purposes as with the other approaches (e.g. I can clearly
>>> see that item is set to a different value for a cell that is still
>>> visible,
>>>
>> ...
>>
>>
>
>
> --
> Robert Krüger
> Managing Partner
> Lesspain GmbH & Co. KG
>
> www.lesspain-software.com
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Fwd: TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

forgot again to reply to all. If anyone ever considers changing the default
settings of the list server, +1 from me.

-- Forwarded message --
From: Robert Krüger 
Date: Wed, Jan 28, 2015 at 3:47 PM
Subject: Re: TableView API, no lazy retrieval of visible cell content
possible?
To: Werner Lehmann 




On Wed, Jan 28, 2015 at 3:13 PM, Robert Krüger  wrote:

>
> Hi,
>
> On Wed, Jan 28, 2015 at 1:59 PM, Werner Lehmann <
> lehm...@media-interactive.de> wrote:
>
>> Robert,
>>
>> I think Tomas is right, load your thumbnails on demand when updateItem is
>> called for an item with missing thumbnail. You say that the cell of a
>> visible item gets reused for another item. If that is the case I guess that
>> the item is "moved" to another cell. Wouldn't it be possible to have an
>> image property on your items and the lazy loading is done on the item,
>> triggered when the item is passed to updateItem of any cell? That
>
>
> That is exactly what I have implemented but the problem is as described
> above
> - Too many non-visible images are loaded (I could probably live with that
> for a while)
> - I have yet to find a criterion to decide an image is no longer needed
> and thus its loading job needs to be removed from the job stack (see below)
>
>
>> should trigger the demand-loading and it would be robust against the
>> tableview exchanging cells for individual items.
>>
> As to the question when to start or stop lazy loading for items, I would
>> add the load-demands to a stack. Each time the image for a new item is
>> requested it is put to the top of the stack and you have one or more
>> threads processing items on the stack (LIFO). An an image is requested
>> which is already on the stack move it to the top of the stack. If an item
>> is removed from a cell remove it from the stack. That should do it.
>>
>>
> That's what I am doing already.
>

To clarify: I am using the stack approach you describe and I remove it from
the stack when updateItem for a table cell is called that already has a
different item set. Then I remove the already set item from the stack but
that never seems to happen in my example.


>
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

Hi,

On Wed, Jan 28, 2015 at 1:59 PM, Werner Lehmann <
lehm...@media-interactive.de> wrote:

> Robert,
>
> I think Tomas is right, load your thumbnails on demand when updateItem is
> called for an item with missing thumbnail. You say that the cell of a
> visible item gets reused for another item. If that is the case I guess that
> the item is "moved" to another cell. Wouldn't it be possible to have an
> image property on your items and the lazy loading is done on the item,
> triggered when the item is passed to updateItem of any cell? That


That is exactly what I have implemented but the problem is as described
above
- Too many non-visible images are loaded (I could probably live with that
for a while)
- I have yet to find a criterion to decide an image is no longer needed and
thus its loading job needs to be removed from the job stack (see below)


> should trigger the demand-loading and it would be robust against the
> tableview exchanging cells for individual items.
>
As to the question when to start or stop lazy loading for items, I would
> add the load-demands to a stack. Each time the image for a new item is
> requested it is put to the top of the stack and you have one or more
> threads processing items on the stack (LIFO). An an image is requested
> which is already on the stack move it to the top of the stack. If an item
> is removed from a cell remove it from the stack. That should do it.
>
>
That's what I am doing already.

Regards,

Robert

Werner
>
> On 28.01.2015 09:30, Robert Krüger wrote:
>
>> Doesn't help. The patterns of this property being changed are just as
>> unusable for my purposes as with the other approaches (e.g. I can clearly
>> see that item is set to a different value for a cell that is still
>> visible,
>>
> ...
>
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

Doesn't help. The patterns of this property being changed are just as
unusable for my purposes as with the other approaches (e.g. I can clearly
see that item is set to a different value for a cell that is still visible,
so this would falsely cancel the loading of that cell's image). And since
none of these things are documented in the api, i.e. how the relationship
between visibility and those properties really are, this is not a god
approach in the first place because my application might behave completely
differently after a Java update, completely screwing up usability.

I am running out of ideas. It just cannot be the case that it is not
possible to write a decent file browser using JFX.

On Tue, Jan 27, 2015 at 10:32 PM, Tomas Mikula 
wrote:

> If the cells don't ever get removed from the scene, then I guess your
> best bet is to start and cancel loading when the item changes, i.e.
> listening to itemProperty(). This is similar to your original
> updateItem() approach, but also don't forget to cancel loading of the
> old item: cancel loading of the old item, if not null, and start
> loading the new item, if not null. I don't think you can yourself do
> much about the inefficiency that more cells than needed are created
> and hold non-null items.
>
> Let's see if others have something to suggest.
>
> Tomas
>
> On Tue, Jan 27, 2015 at 3:49 PM, Robert Krüger 
> wrote:
> > Hi Tomas,
> >
> > When I do that, the property is never set to null. If I use it for
> > triggering the loading (when it is set to a non-null value) it is set
> for a
> > lot more rows than those actually visible. In my test with a model
> > containing 200 items of which the first 4 were visible, it was set to
> > non-null for the first 23 items.
> >
> > Am Dienstag, 27. Januar 2015 schrieb Tomas Mikula :
> >
> >> Hi Robert,
> >>
> >> instead of listening to visibleProperty(), listen to sceneProperty()
> >> and cancel loading when scene becomes null.
> >>
> >> Tomas
> >>
> >> On Tue, Jan 27, 2015 at 1:16 PM, Robert Krüger 
> >> wrote:
> >> > Hi,
> >> >
> >> > either I don't see the forest for the trees or something is missing in
> >> > the
> >> > TableView API as I cannot seem to implement something that seems a
> >> > common
> >> > requirement and was rather easy (not pretty though) in Swing.
> >> >
> >> > Imagine an application like OSX finder in its list view, i.e.
> something
> >> > that displays a possibly very long list of files and displays
> thumbnails
> >> > for them generated on the fly. For many files (e.g. video files)
> >> > extracting
> >> > these thumbnails is an expensive operation and has to be performed in
> >> > the
> >> > background. My application does a very similar thing and uses a
> >> > TableView.
> >> > What I want is to begin extracting video thumbnails as soon as their
> >> > corresponding table row has become visible. I have done that in Swing
> in
> >> > the past without any problem (for more info, you can read
> >> > https://community.oracle.com/message/12810930).
> >> >
> >> > With JavaFX I have tried the following:
> >> >
> >> > 1) Trigger loading the thumbnail in the table cell when it is updated
> >> > and
> >> > the corresponding thumbnail isn't already there
> >> >
> >> > Result: Triggering works more or less as desired but how do I stop the
> >> > loading process if the cell becomes invisible? If the user quickly
> >> > scrolls
> >> > through a large number of rows and puts tons of thumbnail loading jobs
> >> > on
> >> > the queue I have not found a way to dequeue them, so this is
> unusable. I
> >> > added output to the calls to the update method of the TableCell to see
> >> > which instances are used and how their data is reset but the pattern I
> >> > see
> >> > is not suitable for deciding which cell is currently visible.
> >> >
> >> > 2) Register a change listener to the TableCell’s visible property to
> >> > make
> >> > that control the image loading.
> >> >
> >> > Result: I don’t seem to get any change events when I do that, so it
> does
> >> > not work at all for my purpose.
> >> >
> >> > I see no public API in table view to explicitly compute the items
> >> > visible
> >> > in the current viewport either. What am I missing. It can't be an
> >> > oversight
> >> > in the API design, as the thing, I am trying to achieve appears rather
> >> > basic.
> >> >
> >> > Thanks in advance for any hints,
> >> >
> >> > Robert
> >
> >
> >
> > --
> > Robert Krüger
> > Managing Partner
> > Lesspain GmbH & Co. KG
> >
> > www.lesspain-software.com
> >
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

Hi Tomas,

When I do that, the property is never set to null. If I use it for
triggering the loading (when it is set to a non-null value) it is set for a
lot more rows than those actually visible. In my test with a model
containing 200 items of which the first 4 were visible, it was set to
non-null for the first 23 items.

Am Dienstag, 27. Januar 2015 schrieb Tomas Mikula :

> Hi Robert,
>
> instead of listening to visibleProperty(), listen to sceneProperty()
> and cancel loading when scene becomes null.
>
> Tomas
>
> On Tue, Jan 27, 2015 at 1:16 PM, Robert Krüger  > wrote:
> > Hi,
> >
> > either I don't see the forest for the trees or something is missing in
> the
> > TableView API as I cannot seem to implement something that seems a common
> > requirement and was rather easy (not pretty though) in Swing.
> >
> > Imagine an application like OSX finder in its list view, i.e. something
> > that displays a possibly very long list of files and displays thumbnails
> > for them generated on the fly. For many files (e.g. video files)
> extracting
> > these thumbnails is an expensive operation and has to be performed in the
> > background. My application does a very similar thing and uses a
> TableView.
> > What I want is to begin extracting video thumbnails as soon as their
> > corresponding table row has become visible. I have done that in Swing in
> > the past without any problem (for more info, you can read
> > https://community.oracle.com/message/12810930).
> >
> > With JavaFX I have tried the following:
> >
> > 1) Trigger loading the thumbnail in the table cell when it is updated and
> > the corresponding thumbnail isn't already there
> >
> > Result: Triggering works more or less as desired but how do I stop the
> > loading process if the cell becomes invisible? If the user quickly
> scrolls
> > through a large number of rows and puts tons of thumbnail loading jobs on
> > the queue I have not found a way to dequeue them, so this is unusable. I
> > added output to the calls to the update method of the TableCell to see
> > which instances are used and how their data is reset but the pattern I
> see
> > is not suitable for deciding which cell is currently visible.
> >
> > 2) Register a change listener to the TableCell’s visible property to make
> > that control the image loading.
> >
> > Result: I don’t seem to get any change events when I do that, so it does
> > not work at all for my purpose.
> >
> > I see no public API in table view to explicitly compute the items visible
> > in the current viewport either. What am I missing. It can't be an
> oversight
> > in the API design, as the thing, I am trying to achieve appears rather
> > basic.
> >
> > Thanks in advance for any hints,
> >
> > Robert
>


-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

TableView API, no lazy retrieval of visible cell content possible?

[Robert Krüger]

Hi,

either I don't see the forest for the trees or something is missing in the
TableView API as I cannot seem to implement something that seems a common
requirement and was rather easy (not pretty though) in Swing.

Imagine an application like OSX finder in its list view, i.e. something
that displays a possibly very long list of files and displays thumbnails
for them generated on the fly. For many files (e.g. video files) extracting
these thumbnails is an expensive operation and has to be performed in the
background. My application does a very similar thing and uses a TableView.
What I want is to begin extracting video thumbnails as soon as their
corresponding table row has become visible. I have done that in Swing in
the past without any problem (for more info, you can read
https://community.oracle.com/message/12810930).

With JavaFX I have tried the following:

1) Trigger loading the thumbnail in the table cell when it is updated and
the corresponding thumbnail isn't already there

Result: Triggering works more or less as desired but how do I stop the
loading process if the cell becomes invisible? If the user quickly scrolls
through a large number of rows and puts tons of thumbnail loading jobs on
the queue I have not found a way to dequeue them, so this is unusable. I
added output to the calls to the update method of the TableCell to see
which instances are used and how their data is reset but the pattern I see
is not suitable for deciding which cell is currently visible.

2) Register a change listener to the TableCell’s visible property to make
that control the image loading.

Result: I don’t seem to get any change events when I do that, so it does
not work at all for my purpose.

I see no public API in table view to explicitly compute the items visible
in the current viewport either. What am I missing. It can't be an oversight
in the API design, as the thing, I am trying to achieve appears rather
basic.

Thanks in advance for any hints,

Robert

Re: Scroll events fired in TableView although there is nothing to scroll

[Robert Krüger]

yes, that's what appear's to be happening.

On Sat, Jan 24, 2015 at 9:33 PM, Scott Palmer  wrote:

> You are probably only seeing the event when the TableView's internal
> ScrollPane doesn't consume it.
>
> Scott
>
> > On Jan 24, 2015, at 11:50 AM, Robert Krüger  wrote:
> >
> > Hi,
> >
> > yes, I just now realized that setOnScroll is Node API and not TableView
> so
> > I obviously sent my Mail too early.
> >
> > Sorry about the noise.
> >
> > Another observation, though: The onscroll-eventhandler is not called when
> > the tableview actually does scroll. It does fire again, when I reach one
> > end of the data and keep using scroll gestures. Interesting but
> irrelevant
> > for my case.
> >
> > Thanks for your response,
> >
> > Robert
> >
> >
> >
> > On Sat, Jan 24, 2015 at 4:17 PM, Tom Schindl <
> tom.schi...@bestsolution.at>
> > wrote:
> >
> >> [sorry sent the other mail too early]
> >>
> >> Hi,
> >>
> >> I don't really see why you need to know about this all view classes are
> >> virtual so a TableCell, ListCell is only requested when shown - and then
> >> reused.
> >>
> >> IIRC this virtuallity is row based only but the otn request also only
> >> talks about rows.
> >>
> >> One more note on the onScroll which has nothing todo with the scrollbars
> >> - it simply tells you that:
> >> a) someone used the scrollwheel on the mouse
> >> b) used the scroll gesture eg on the touch pad
> >>
> >> So I think you did not really get what onScroll is doing.
> >>
> >> Tom
> >>
> >>> On 24.01.15 14:15, Robert Krüger wrote:
> >>> Hi,
> >>>
> >>> I am a bit surprised by the behaviour of the onScroll event handling of
> >>> TableView. I just printed the events I received there to standard out
> and
> >>> although the table does not display any scrollbars because it is large
> >>> enough to fit all content into it, I receive events as if it were
> >> scrolling
> >>> (even with the physics/inertia I would expect from a scrollbar, i.e. it
> >>> takes a while after the scroll gesture for the events to stop firing).
> >>>
> >>> As an API user I would never have expected this. This makes me wonder
> how
> >>> useful the event handler is in the first place as I cannot use it to
> see
> >> if
> >>> there is actually any scrolling going on in the table. How do I do
> that?
> >>>
> >>> This is somewhat related to a post on OTN (
> >>> https://community.oracle.com/message/12810930#12810930) if anyone
> wants
> >> to
> >>> know what the broader context of this is.
> >>>
> >>> Best regards,
> >>>
> >>> Robert
> >>
> >>
> >> --
> >> Thomas Schindl, CTO
> >> BestSolution.at EDV Systemhaus GmbH
> >> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> >> http://www.bestsolution.at/
> >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >
> >
> >
> > --
> > Robert Krüger
> > Managing Partner
> > Lesspain GmbH & Co. KG
> >
> > www.lesspain-software.com
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Scroll events fired in TableView although there is nothing to scroll

[Robert Krüger]

Hi,

yes, I just now realized that setOnScroll is Node API and not TableView so
I obviously sent my Mail too early.

Sorry about the noise.

Another observation, though: The onscroll-eventhandler is not called when
the tableview actually does scroll. It does fire again, when I reach one
end of the data and keep using scroll gestures. Interesting but irrelevant
for my case.

Thanks for your response,

Robert



On Sat, Jan 24, 2015 at 4:17 PM, Tom Schindl 
wrote:

> [sorry sent the other mail too early]
>
> Hi,
>
> I don't really see why you need to know about this all view classes are
> virtual so a TableCell, ListCell is only requested when shown - and then
> reused.
>
> IIRC this virtuallity is row based only but the otn request also only
> talks about rows.
>
> One more note on the onScroll which has nothing todo with the scrollbars
> - it simply tells you that:
> a) someone used the scrollwheel on the mouse
> b) used the scroll gesture eg on the touch pad
>
> So I think you did not really get what onScroll is doing.
>
> Tom
>
> On 24.01.15 14:15, Robert Krüger wrote:
> > Hi,
> >
> > I am a bit surprised by the behaviour of the onScroll event handling of
> > TableView. I just printed the events I received there to standard out and
> > although the table does not display any scrollbars because it is large
> > enough to fit all content into it, I receive events as if it were
> scrolling
> > (even with the physics/inertia I would expect from a scrollbar, i.e. it
> > takes a while after the scroll gesture for the events to stop firing).
> >
> > As an API user I would never have expected this. This makes me wonder how
> > useful the event handler is in the first place as I cannot use it to see
> if
> > there is actually any scrolling going on in the table. How do I do that?
> >
> > This is somewhat related to a post on OTN (
> > https://community.oracle.com/message/12810930#12810930) if anyone wants
> to
> > know what the broader context of this is.
> >
> > Best regards,
> >
> > Robert
> >
>
>
> --
> Thomas Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
> http://www.bestsolution.at/
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Scroll events fired in TableView although there is nothing to scroll

[Robert Krüger]

Hi,

I am a bit surprised by the behaviour of the onScroll event handling of
TableView. I just printed the events I received there to standard out and
although the table does not display any scrollbars because it is large
enough to fit all content into it, I receive events as if it were scrolling
(even with the physics/inertia I would expect from a scrollbar, i.e. it
takes a while after the scroll gesture for the events to stop firing).

As an API user I would never have expected this. This makes me wonder how
useful the event handler is in the first place as I cannot use it to see if
there is actually any scrolling going on in the table. How do I do that?

This is somewhat related to a post on OTN (
https://community.oracle.com/message/12810930#12810930) if anyone wants to
know what the broader context of this is.

Best regards,

Robert

Re: Tagging UI control

[Robert Krüger]

Thanks everyone for your suggestions. I will probably start playing
around with the TextFlow approach as I have to make another similar
control for variable substitution in a text that needs typing to be
possible in multiple places and I may be able to implement both using
one approach.

On Mon, Sep 8, 2014 at 11:32 PM, Jonathan Giles
 wrote:
> ControlsFX has a CustomTextField component that allows for nodes to be
> placed on the left / right of a normal TextField, without overlapping the
> text. I would probably use that internally along with some custom code to
> render the individual tags in an HBox on the left.
>
> -- Jonathan
>
>
> On 8/09/2014 8:02 p.m., Robert Krüger 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
>
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Tagging UI control

[Robert Krüger]

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

Fwd: JavaFx roadmap?

[Robert Krüger]

Classic, forgot to post to list.

-- Forwarded message --
From: Robert Krüger 
Date: Thu, Aug 14, 2014 at 10:29 AM
Subject: Re: JavaFx roadmap?
To: Adam Granger 


On Mon, Aug 11, 2014 at 11:08 PM, Adam Granger  wrote:
> The official java fx roadmap on oracle.com seems to have been taken down,
> without replacement.
>
> http://www.oracle.com/technetwork/java/javafx/overview/roadmap-1446331.html
>
> I've had a search in JIRA and there is clearly a lot of work going on.
>
> - What's the long term plan, target release dates, long term support dates?
> We're interested in this at work, but need to know oracle is committed
> to it.
> - What about features like multi-touch on Linux?
> - How will WebView ever keep up with the constantly evolving HTML5 platform?
> - Is Swing development really over?

As I am probably in a similar situation like you (wild guess) and I
have posted questions here with probably similar motivation (making
informed decisions regarding our product technology strategy), here
are my two cents:

Swing is likely to be available for at least another few years. It's
not deprecated in 8, so earliest to deprecate it is 9 and 10 is not
officially scheduled but Wikipedia guesses around 2018. Additionally
there are probably many Oracle support contract customers out there
that run Swing-based applications and I do not think it's likely
Oracle wants to piss them off by rushing out of Swing. The amount of
Swing development at Oracle (making new things like Retina support
work) is something nobody can predict. Depending on your product,
something like this may become a problem for you before Swing hits end
of life. In addition to that there are probably a number of larger
Swing-based Oracle applications (Netbeans being the largest one
probably) that would have to be migrated to JFX (or dumped) before
getting rid of Swing. Having said that, I don't think Oracle folks
will likely say anything that encourages people to wait with their
adoption of JFX for obvious reasons. The amount of work that is
obviously put into JFX is significant (judging by following this list
and Jira) and it does look very unlikely that it is going away.
Regarding adoption of JFX for me there is a bit of a chicken-egg
problem. My first research into migrating our stuff to JFX gave me the
impression that it is a great platform to work with, easily learned by
Swing developers with a lot of advantages over Swing regarding
maintainability of code among other things but there are still quite a
few bugs that simply show, it has not been used that much (as in
thousands or tens of thousands of production-quality applications
having been developed with it, not hello-world-style or free academic
applications where people do not complain as much about problems) and
that may be a reason to wait with adoption for some people (after all
pretty complex high-profile applications like Idea still work very
well with Swing although development, especially as look-and-feel
customization is concerned, is very clumsy compared to JFX). Response
to JFX Jira bug reports is outstanding, though.

All in all not an easy call.

Cheers,

Robert

Re: ANGLE - Translating OpenGL ES 2 code to DirectX?

[Robert Krüger]

Yes, it's exactly the same here (basically the same use case, i.e.
high performance video playback). I guess it's different for the guys
wanting to reuse their tons of GL code.

On Wed, Jul 23, 2014 at 1:23 PM, Scott Palmer  wrote:
> If I'm resorting to native code I care a lot less about it being 
> cross-platform (not 100% less, but less). Give me a GLContext on Linux and 
> Mac and whatever DirectX has on Windows. I just want a way to get content 
> generated on the native side to the screen without losing performance.
>
> Scott
>
>> On Jul 21, 2014, at 4:13 PM, Joseph Andresen  
>> wrote:
>>
>> That's a good point Robert,
>>
>> If the GLContext work that steve and felipe did become an actual thing, this 
>> would help that cause become cross platform.
>> Angle also is strictly es2, and I haven't looked at prism es2 in a while but 
>> I think we use GL2 calls for desktop in some cases. We would have to address 
>> those cases (if even possible) before any work started.
>>
>> -Joe
>>
>>> On 7/21/2014 10:40 AM, Robert Krüger wrote:
>>> On Mon, Jul 21, 2014 at 7:09 PM, Joseph Andresen
>>>  wrote:
>>>> I also forgot,
>>>>
>>>> The argument could be made that if we did indeed use angle, we could ditch
>>>> our directx 9 pipeline altogether and just use "one" hardware pipeline. We
>>>> would really have to evaluate this though, and I am not sure the work would
>>>> be worth the benefit (if there even is any).
>>> Well, at least the presence of the directx pipeline was used as an
>>> argument against exposing a GL context via a low-level native api,
>>> which quite a number of people with particular graphics/performance
>>> requirements need IIRC, so this would be a potential benefit.
>>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: ANGLE - Translating OpenGL ES 2 code to DirectX?

[Robert Krüger]

Thanks for all the in-depth insights. As most of the time it appears
easier at first glance than it actually is.

On Mon, Jul 21, 2014 at 10:22 PM, Richard Bair  wrote:
> I was interested in Angle for exactly this same reason — it would allow us to 
> expose OpenGL at the public API level. However there are licensing issues 
> we’d have to look at, performance tests to be run, security audits performed, 
> and whether or not it is actually able to perform well.
>
> Although the browsers use it for WebGL, WebGL is not the main thing browsers 
> do. What I mean by that, is that if WebGL isn’t working, an HTML author can 
> detect that and redirect or provide some kind of error to the user. If GL 
> doesn’t work for us, we’d be dead in the water (probably just crash) without 
> having some kind of fallback. We could maybe just fallback to software 
> rendering (and realize that in such cases the performance will not be good 
> and people will be mad). It didn’t look like a slam dunk to me. Rather, it 
> seemed to me that we should allow the OpenGL stack to run on Windows with an 
> option, let developers opt into it, but note that it isn’t a supported 
> configuration so we don’t have support costs associated with it if it doesn’t 
> work. And we’d have to forbid it on WebStart / Applets (within reason) so as 
> not to allow bugs in the native drivers to be exploitable through us (if the 
> board causes the VM to crash, there is potentially some security issues 
> there). And then expose an API that works with GL, supported on Mac / Linux, 
> but “known to work” on Windows in cases where Windows GL support works. That 
> seemed to me a shorter path to victory.

This sounds like there are concrete plans for this, which wood be
great news. The approach where an integration API would only work on
Windows with GL support would at least in our area not be uncommon.
There are a number of digital media pro applications that require GL
to be installed on Windows to work.

Keep up the good work.

Re: ANGLE - Translating OpenGL ES 2 code to DirectX?

[Robert Krüger]

On Mon, Jul 21, 2014 at 7:09 PM, Joseph Andresen
 wrote:
> I also forgot,
>
> The argument could be made that if we did indeed use angle, we could ditch
> our directx 9 pipeline altogether and just use "one" hardware pipeline. We
> would really have to evaluate this though, and I am not sure the work would
> be worth the benefit (if there even is any).

Well, at least the presence of the directx pipeline was used as an
argument against exposing a GL context via a low-level native api,
which quite a number of people with particular graphics/performance
requirements need IIRC, so this would be a potential benefit.

Re: OT: Netbeans ported to JFX?

[Robert Krüger]

On Thu, Jul 10, 2014 at 4:53 PM, David Hill  wrote:
> On 7/10/14, 10:40 AM, Jeff Martin wrote:
>>
>> That's not what Bill Gates or Steve Jobs said.
>
> To be fair - both of those guys are trying to build an ecosystem - not just
> an OS, but an OS and tools and products layered on top of it. They want to
> create an environment that you want to come to and spend $$$.
>
> Oracle's bottom line is about Big Data and the appware in the middle of it.
> That middle ware uses several technologies for graphical display and JavaFX
> is just one of them. Unless you are a middle ware customer, you probably
> have not seen any of them, because unlike MS Word, or Apple ITunes, they are
> not usually seen by the general public.
>
> It certainly would be nice to have more JavaFX applications (real apps or
> even good demos) as it would help showcase the capabilities. Jasper has
> whipped together some interesting demo apps over the years for JavaOne
>
> Any suggestions on good demo apps for small boards (Pi, i.MX6) ? (Existing
> or otherwise).

No offence but it is exactly those apps that I am not talking about
because while they may help to demonstrate how to do things to a
beginner, they do not contribute to the platform becoming mature and I
have yet to see one that really impresses me when compared to examples
of uses of other state-of-the-art software. Having the next 2-1/2D
Raspberry mini game certainly won't convince many people, who make the
decision which technology their company will embrace for their next
product, that JFX is a stat-of-the-art platform just as Jasper's 3D
examples won't. Honestly, I _want_ to move to JavaFX and I am trying
to convince my business partners to consider that and I asked them to
look at what's available on the web and most of what you find is those
demos. The reaction was really something like "technology looks OK but
they cannot be serious about making the case with those demos when
developers are used to the respective resources by Apple (iOS, OSX) or
Google (Android)" and quality problems worrying them, which currently
is my main concern as well (stuff like RT-37533, RT-37501, RT-37372,
which I ran into not while porting a complex application to JavaFX but
in just three days of building mini sample applications that use UI
features that we currently use in our Swing app).

My point is that acceptance of JavaFX by more companies making quality
products they make a living on, is vital for JFX, if it is not
supposed to remain a niche or academic technology which it currently
most likely is (while it absolutely has the potential for more).
Netbeans being a huge product and Swing being a legacy technology not
being an option for another 10 years I just thought, I'd ask if that
one in-house product would become a flagship real-world "demo".

Re: OT: Netbeans ported to JFX?

[Robert Krüger]

On Wed, Jul 9, 2014 at 4:14 PM, Jeff Martin  wrote:
> My thought is that JavaFX is perfect for an IDE targeted to education, like 
> Greenfoot and BlueJ:
>
> SnapCode: SnapCode is the first and only pure JavaFX IDE
> YouTube Overview: SnapCode JavaFX Overview
>
> SnapCode has visual code editing ("Snap-coding"), a sprite kit, 
> graphics/sound editing, a runtime browser/player with animated transitions 
> and more. It also has most of the features you expect in a modern IDE. 
> Hopefully this is a great way to attract a new generation of developers and 
> bring JavaFX to all Java developers.
>
> What it doesn't have is very much in the way of resources. If anyone wants to 
> help, let me know. If Oracle would like to kick in an engineer or a few 
> dollars, I wouldn't turn that away either.
>
> We need something like a "JavaFX Playground" before Apple Swift-boat's us. :-)

I have to say I passionately disagree here. Of course, everyone has
different requirements/expectations. I am currently looking at JavaFX
as a candidate technology for commercial products in a market where
people are used to native applications. So far, I think JavaFX, from a
developer point of view, is great and the dedication of the dev team
and the transparency of the dev process are outstanding but it still
suffers from maturity problems that usually go away after a lot of
serious applications have been thrown at it, not by another Ensemble
or educational tool. Even big finance or medical or system management
applications may not be a good enough test for some areas because
their users are typically more forgiving in certain areas than e.g. a
photographer or designer using their favourite photo organisation tool
on a Mac but of course, every application helps and Netbeans is so
huge that porting it would probably result in a number of new Jira
issues making the platform better and, as I wrote, I thought with the
Swing API no longer being developed, it would either have to die or be
ported anyway.

BTW, is there any directory of (commercial) JFX applications anyone is aware of?

OT: Netbeans ported to JFX?

[Robert Krüger]

Hi,

it is a little off-topic but the people reading this list are most
likely the ones who could answer this.

Is a port of Netbeans to JFX planned or even ongoing? It would
certainly be a huge project but I am asking myself, if there is a way
around that with Swing being de-facto legacy if Netbeans isn't dropped
as a whole. It would certainly demonstrate Oracle's commitment to JFX
as the future for Desktop UIs and would surely help the maturity of
JFX which IMHO needs tons of real-world apps to be thrown at it.

I would not be surprised not to get an answer for all sorts of
understandable reasons but I thought I'd give it a shot anyway.

Best regards,

Robert

Re: API enhancement request to make stage respect scene's min size

[Robert Krüger]

Hi Martin,

yes that seems to address exactly that problem.

Thanks!

On Thu, Jun 26, 2014 at 1:27 PM, Martin Sladecek
 wrote:
> Hi Robert,
> I think this is the JIRA issue you are looking for:
> https://javafx-jira.kenai.com/browse/RT-19183
>
> This might be a good candidate for 8u40 actually...
>
> -Martin
>
>
> On 06/26/2014 01:10 PM, Robert Krüger wrote:
>>
>> Hi,
>>
>> right now, I am doing this to prevent stage windows to be resizable in
>> a way that cuts off their contained scene's content:
>>
>>  final Scene scene = new Scene(pane);
>>  stage.setScene(scene);
>>  stage.setTitle(getClass().getSimpleName());
>>  stage.sizeToScene();
>>
>>  // ensure that the window can not be resized to smaller than
>> the minsize of its scene
>>  Runnable updateMinSize = () -> {
>>
>> stage.setMinWidth(scene.getRoot().minWidth(scene.getHeight()));
>>
>> stage.setMinHeight(scene.getRoot().minHeight(scene.getWidth())
>> + DECORATIONS_HEIGHT);
>>  };
>>
>>  stage.setOnShown((e) -> updateMinSize.run());
>>  stage.widthProperty().addListener((obs, oldVal, newVal) ->
>> updateMinSize.run());
>>  stage.heightProperty().addListener((obs, oldVal, newVal) ->
>> updateMinSize.run());
>>  stage.show();
>>
>> This feels somewhat odd (and the constant for window decoration's
>> height is ugly but maybe I am missing the clean way to retrieve it)
>> for something that should be a common requirement (in all of our
>> applications it is usually considered a bug when a window/dialog does
>> not enforce this).
>>
>> Shouldn't there be a method like
>> stage.setRespectContentMinSize(boolean respect) or something similar?
>> Am I missing something obvious that is already there?
>>
>> Thanks for any insights.
>>
>> Robert
>
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

API enhancement request to make stage respect scene's min size

[Robert Krüger]

Hi,

right now, I am doing this to prevent stage windows to be resizable in
a way that cuts off their contained scene's content:

final Scene scene = new Scene(pane);
stage.setScene(scene);
stage.setTitle(getClass().getSimpleName());
stage.sizeToScene();

// ensure that the window can not be resized to smaller than
the minsize of its scene
Runnable updateMinSize = () -> {
stage.setMinWidth(scene.getRoot().minWidth(scene.getHeight()));
stage.setMinHeight(scene.getRoot().minHeight(scene.getWidth())
+ DECORATIONS_HEIGHT);
};

stage.setOnShown((e) -> updateMinSize.run());
stage.widthProperty().addListener((obs, oldVal, newVal) ->
updateMinSize.run());
stage.heightProperty().addListener((obs, oldVal, newVal) ->
updateMinSize.run());
stage.show();

This feels somewhat odd (and the constant for window decoration's
height is ugly but maybe I am missing the clean way to retrieve it)
for something that should be a common requirement (in all of our
applications it is usually considered a bug when a window/dialog does
not enforce this).

Shouldn't there be a method like
stage.setRespectContentMinSize(boolean respect) or something similar?
Am I missing something obvious that is already there?

Thanks for any insights.

Robert

Re: Exposing native surface or opengl handle

[Robert Krüger]

On Thu, Jun 26, 2014 at 9:40 AM, John Hendrikx  wrote:
>
> On 13/06/2014 08:57, Robert Krüger wrote:
>>
>> Hi,
>>
>> it has been discussed a number of time in the passed but let me
>> quickly summarize:
>>
>> A number of people have requested a feature that provides the ability
>> to have native code draw into a surface provided by a JavaFX
>> application as fast as technically possible, i.e. with no indirection
>> or copying because use cases for this were mostly cases where
>> performance was critical, e.g. HD/UHD video players, real-time
>> visualization etc. where losing even e few percent would make a
>> software written in JavaFX unable to compete with native products
>> (e.g. in the video area nobody will use a video player that is not
>> able to play the content smoothly that VLC player or Quicktime can on
>> the same machine).
>
> Although copying is used, I've combined JavaFX and VLC in this fashion for
> over a year already, and video is smooth and stable -- stable enough to
> watch full length HD movies, at 20% increased speed (the speed I normally
> watch them).
>
> Of course, if the target machine is barely able to play these, then the
> extra copying overhead (which is smaller than people think) may be too much.

Yes and this becomes more and more a problem of not so weak machines
when you go to higher resolutions than FHD that you can display well
on a Retina display and thus a competitive disadvantage when targeting
that market. I agree that for a lot of video applications the copying
approach is probably good enough, though.

Robert

Re: Exposing native surface or opengl handle

[Robert Krüger]

Thanks a lot for the valuable and very encouraging info! I will track
that issue and use that for further communication.

Robert

On Mon, Jun 23, 2014 at 5:15 PM, Stephen F Northover
 wrote:
> I'm sorry this thread scrolled away into the bitbucket in the sky.
>
> Last JavaOne, we wrote a prototype that showed native integration on OS X.
> We parented a native sheet dialog in an FX stage and providing an OpenGL
> node.  The code was a prototype that worked only on OS X.  The Open GL node
> allowed drawing JOGL and LWJGL to draw on a texture that was created by FX.
> This mean that the OpenGL node could take part in FX animations and effects.
>
> I will attach the prototype code to
> https://javafx-jira.kenai.com/browse/RT-36215.  I need to find it and make
> sure that it still compiles and works.  This week is M5 RDP2 and today is
> likely to be a write off for a number of reasons.
>
> https://wiki.openjdk.java.net/display/OpenJFX/8u20
>
> Please ping me in the JIRA if the code doesn't show up sometime this week.
> The prototype is the basis of one possible implementation and needs some
> work.  There are other possible implementations and this is not the final
> word on the issue.
>
> Steve
>
>
> On 2014-06-23, 10:03 AM, Robert Krüger wrote:
>>
>> Sorry, my last reply did not go to the list. That was unintended.
>>
>> Oracle-Team, please someone comment on this, at least on what should
>> be done regarding a Jira Issue (or several ones?) to track any
>> progress on this and collect ideas & requirements.
>>
>> Best regards,
>>
>> Robert
>>
>> On Fri, Jun 13, 2014 at 10:41 PM, Robert Krüger 
>> wrote:
>>>
>>> Thanks for the hint. I think this is similar to what a colleague of
>>> mine did a while ago as a proof of concept using other com.sun.api
>>> that then went away. As long as we're bundling the JRE with our
>>> product and we're desperate enough to get it working, we might do
>>> something like this but it's of course just a last resort. Lets hope
>>> someone from Oracle says something.
>>>
>>>
>>>
>>> On Fri, Jun 13, 2014 at 8:05 PM, Scott Palmer  wrote:
>>>>
>>>> That’s basically it. It isn’t perfect, but its so simple I don’t see why
>>>> it can’t be done quickly.  We are already talking about using native code 
>>>> to
>>>> render.
>>>>
>>>> That said, com.sun.glass.ui.Window contains the field we want:
>>>>
>>>>  // Native object handle (HWND, or NSWindow*, etc.)
>>>>  long ptr;
>>>>
>>>> You could be evil and hack it now with reflection, but it relies on
>>>> internal implementation details.
>>>>
>>>> In my application I already create a native window for video preview…
>>>> though not as a child of the FX window.  The problem is that there isn’t a
>>>> straight-forward, reliable, supported way to get the window handle to use
>>>> for the parent (JavaFX) window.  There are ways to hack it, but they aren’t
>>>> pretty.
>>>>
>>>>
>>>> Scott
>>>>
>>>> On Jun 13, 2014, at 7:55 AM, Robert Krüger  wrote:
>>>>
>>>>> Just for my understanding: Your approach would be to get the native
>>>>> window handle for the hosting JFX stage, then leave an open space in
>>>>> the layout for e.g. the player canvas that will be implemented
>>>>> natively and then create a native child window that just reacts to
>>>>> move and resize events of its native parent?
>>>>>
>>>>> On Fri, Jun 13, 2014 at 1:48 PM, Scott Palmer 
>>>>> wrote:
>>>>>>
>>>>>> This is critical, but I don't think we need to focus on a specific
>>>>>> technology like Direct3D or OpenGL. As a first step all we need is a
>>>>>> mechanism to get a native reference to the Window. Just like we can with
>>>>>> JAWT.  I'm guessing that JavaFX doesn't use heavyweight child windows so 
>>>>>> we
>>>>>> could add a new child window that we manage with our own code and it 
>>>>>> would
>>>>>> appear on top of the JavaFX content.
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>>> On Jun 13, 2014, at 3:08 AM, Felix Bembrick
>>>>>>>  wrote:
>>>>>>>
>>>>>>> I absolutely agree tha

Re: Exposing native surface or opengl handle

[Robert Krüger]

Sorry, my last reply did not go to the list. That was unintended.

Oracle-Team, please someone comment on this, at least on what should
be done regarding a Jira Issue (or several ones?) to track any
progress on this and collect ideas & requirements.

Best regards,

Robert

On Fri, Jun 13, 2014 at 10:41 PM, Robert Krüger  wrote:
> Thanks for the hint. I think this is similar to what a colleague of
> mine did a while ago as a proof of concept using other com.sun.api
> that then went away. As long as we're bundling the JRE with our
> product and we're desperate enough to get it working, we might do
> something like this but it's of course just a last resort. Lets hope
> someone from Oracle says something.
>
>
>
> On Fri, Jun 13, 2014 at 8:05 PM, Scott Palmer  wrote:
>> That’s basically it. It isn’t perfect, but its so simple I don’t see why it 
>> can’t be done quickly.  We are already talking about using native code to 
>> render.
>>
>> That said, com.sun.glass.ui.Window contains the field we want:
>>
>> // Native object handle (HWND, or NSWindow*, etc.)
>> long ptr;
>>
>> You could be evil and hack it now with reflection, but it relies on internal 
>> implementation details.
>>
>> In my application I already create a native window for video preview… though 
>> not as a child of the FX window.  The problem is that there isn’t a 
>> straight-forward, reliable, supported way to get the window handle to use 
>> for the parent (JavaFX) window.  There are ways to hack it, but they aren’t 
>> pretty.
>>
>>
>> Scott
>>
>> On Jun 13, 2014, at 7:55 AM, Robert Krüger  wrote:
>>
>>> Just for my understanding: Your approach would be to get the native
>>> window handle for the hosting JFX stage, then leave an open space in
>>> the layout for e.g. the player canvas that will be implemented
>>> natively and then create a native child window that just reacts to
>>> move and resize events of its native parent?
>>>
>>> On Fri, Jun 13, 2014 at 1:48 PM, Scott Palmer  wrote:
>>>> This is critical, but I don't think we need to focus on a specific 
>>>> technology like Direct3D or OpenGL. As a first step all we need is a 
>>>> mechanism to get a native reference to the Window. Just like we can with 
>>>> JAWT.  I'm guessing that JavaFX doesn't use heavyweight child windows so 
>>>> we could add a new child window that we manage with our own code and it 
>>>> would appear on top of the JavaFX content.
>>>>
>>>> Scott
>>>>
>>>>> On Jun 13, 2014, at 3:08 AM, Felix Bembrick  
>>>>> wrote:
>>>>>
>>>>> I absolutely agree that such a feature is critical for the success and
>>>>> longevity of JavaFX.  I am *really* hoping for some heavily beefed-up 3D
>>>>> support in a JFX 8.* release or JFX 9.
>>>>>
>>>>> I need my graphics toolkit (currently JavaFX) to be able to handle
>>>>> everything from simple UIs with basic controls to complex 3D
>>>>> visualisations, just like the underlying graphics API is capable of (i.e.
>>>>> OpenGL or Direct3D).  I strongly suspect though that focusing on OpenGL
>>>>> exclusively is the only viable way to go from a cost perspective which
>>>>> would mean JavaFX supporting OpenGL on Windows.
>>>>>
>>>>>
>>>>>> On 13 June 2014 16:57, Robert Krüger  wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> it has been discussed a number of time in the passed but let me
>>>>>> quickly summarize:
>>>>>>
>>>>>> A number of people have requested a feature that provides the ability
>>>>>> to have native code draw into a surface provided by a JavaFX
>>>>>> application as fast as technically possible, i.e. with no indirection
>>>>>> or copying because use cases for this were mostly cases where
>>>>>> performance was critical, e.g. HD/UHD video players, real-time
>>>>>> visualization etc. where losing even e few percent would make a
>>>>>> software written in JavaFX unable to compete with native products
>>>>>> (e.g. in the video area nobody will use a video player that is not
>>>>>> able to play the content smoothly that VLC player or Quicktime can on
>>>>>> the same machine). Some people already have libraries of native code
>>&

Exposing native surface or opengl handle

[Robert Krüger]

Hi,

it has been discussed a number of time in the passed but let me
quickly summarize:

A number of people have requested a feature that provides the ability
to have native code draw into a surface provided by a JavaFX
application as fast as technically possible, i.e. with no indirection
or copying because use cases for this were mostly cases where
performance was critical, e.g. HD/UHD video players, real-time
visualization etc. where losing even e few percent would make a
software written in JavaFX unable to compete with native products
(e.g. in the video area nobody will use a video player that is not
able to play the content smoothly that VLC player or Quicktime can on
the same machine). Some people already have libraries of native code
that they have built over the years and would like to reuse. I would
even go so far to say that our product will probably never be able to
move to JFX (apart from mixing it a bit with Swing, which we currently
see rather aa a migration strategy and not as the end result) without
this problem solved.

In the past the reactions/signals from the Oracle team in this respect
were mixed but some of it indicated that this topic was discussed in
the past and might be revisited after the release of JFX 8. Now that
the latter has happened I would like to ask what the plans for this
are.

Is there a Jira Issue where we can track the progress of it?

If not, does it make sense if I open one, so people (probably the same
ones that have participated in these discussions in the past like
Scott and the Ultramixer guys etc.) can collect their
requirements/thoughts?

Even if Oracle should decide not to do something about it, it would
still be nice to get pointers in the code base to where this would be
possible, even if it is non-portable. I know that for our product it
would be totally OK to have different ways of doing this for each
platform and to live with the limitation to not be able to manipulate
the result in the FX scene graph apart from that the position of the
surface moving with the hosting FX node and as far as I have
understood others, it is the same for them.

Maybe a Jira issue could also be a good place to bundle information
about approaches interested parties are willing to pursue.

Thoughts anyone?

Robert

Re: Adding application-wide stylesheet

[Robert Krüger]

How would one reference the stylesheet location of the default style
sheet packaged with the JRE in the import statement?

On Thu, Jun 12, 2014 at 11:34 PM, David Grieve  wrote:
> In 8u20, you can use @import in your .css file. That, along with
> Application#setUserAgentStylesheet(String), should do the trick. If I'm
> missing something, then please feel free to create a new feature request in
> JIRA.
>
>
> On 6/12/14, 4:57 PM, Robert Krüger wrote:
>>
>> Hi,
>>
>> RT-18543 has been closed as not an issue with the following explanation:
>>
>> API exists in Application for this:
>>
>> http://download.java.net/jdk8/jfxdocs/javafx/application/Application.html#setUserAgentStylesheet-java.lang.String-
>>
>> But that does not the same thing as it replaces the default (modena)
>> stylesheet, which is not what people asking this including the
>> original poster usually want (see also
>>
>> http://stackoverflow.com/questions/16318517/how-do-i-dynamically-add-and-remove-css-for-the-whole-javafx-application).
>>
>> What is the reason not to expose what
>> StyleManager.getInstance().addUserAgentStylesheet("...") does
>> somewhere in public API like in Application?
>>
>> Thanks,
>>
>> Robert
>
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Adding application-wide stylesheet

[Robert Krüger]

Hi,

RT-18543 has been closed as not an issue with the following explanation:

API exists in Application for this:
http://download.java.net/jdk8/jfxdocs/javafx/application/Application.html#setUserAgentStylesheet-java.lang.String-

But that does not the same thing as it replaces the default (modena)
stylesheet, which is not what people asking this including the
original poster usually want (see also
http://stackoverflow.com/questions/16318517/how-do-i-dynamically-add-and-remove-css-for-the-whole-javafx-application).

What is the reason not to expose what
StyleManager.getInstance().addUserAgentStylesheet("...") does
somewhere in public API like in Application?

Thanks,

Robert

Re: Ugly flashing when opening a css-styled stage

[Robert Krüger]

Hi Anthony

On Mon, Jun 2, 2014 at 3:01 PM, Anthony Petrov
 wrote:
> Hi Robert,
>
>
>> Which of the
>> two mailing lists is the more appropriate one to post these things
>> (JFX problems which look like they might be platform-specific) to?
>
>
> FYI: the JDK Mac OS X Port Project has been completed long time ago, so
> currently the macosx-port-dev@ mailing list isn't appropriate for almost
> anything.

Oh, that's a surprise. I thought it was more or less the successor of
apple-java-dev, i.e. where one discusses issues/problems/questions
specific to the Mac port of the JDK/JRE and Java development on the
Mac in general.

>
> Please report JavaFX bugs at: https://javafx-jira.kenai.com/

Submitted as RT-37372
>
> AWT/Swing/JDK bugs can be reported at: http://bugreport.java.com/bugreport/
> (or http://bugs.sun.com/ )
>
> If you wish to participate in the development of the technologies (e.g. you
> want to contribute a patch for JavaFX or JDK platform), then you're welcome
> to post your suggestions on the appropriate development mailing lists
> (openjfx-dev@, awt-dev@, swing-dev@, etc.)
>

I've been subscribed to the two lists for a while now and my
impression is, it is also a place where people running into problems
with the platform's limitations exchange their experience which has
been very valuable especially when dealing with a rather new platform
but I guess I need to move to the OTN community for this.

Thanks and best regards,

Robert

Re: Ugly flashing when opening a css-styled stage

[Robert Krüger]

No, it does not. So it is not the CSS.


On Mon, Jun 2, 2014 at 10:04 AM, Tom Schindl
 wrote:
> To rule out CSS is the reason you could directly set the background:
>
> pane.setBackground(new Background(new BackgroundFill(Color.rgb(54, 54,
> 54), CornerRadii.EMPTY, Insets.EMPTY)));
>
> Does that improve the situation?
>
> Tom
>
>
> On 02.06.14 09:51, Robert Krüger wrote:
>> Thanks but it does not seem to improve the situation.
>>
>> btw, I am using 1.8.0_05-b13 on Mac OS 10.9.3 on a retina MBP.
>>
>> On Sun, Jun 1, 2014 at 9:59 PM, Jeff Martin  wrote:
>>> I haven't seen this, but here's a hack you can try:
>>>
>>> // Show stage transparent once to get proper drawing
>>> _stage.setOpacity(0); _stage.show(); _stage.hide(); 
>>> _stage.setOpacity(1);
>>>
>>> I've done this before to trigger Stage to set it's width/height property 
>>> (which I needed to position the stage property).
>>>
>>> jeff
>>>
>>>
>>> On Jun 1, 2014, at 3:18 AM, Robert Krüger  wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm in the process of evaluating Java FX 8 for our currently
>>>> Swing-based product (also Java 8) on OSX.
>>>>
>>>> My first attempt to style a stage's background resulted in an ugly
>>>> flashing effect which I would classify as a show-stopper for
>>>> delivering a commercial product. This looks like it is caused by the
>>>> stage being drawn at least once before the style has been applied, and
>>>> I am wondering what the mistake is since my code is more or less a
>>>> straight-forward hello world:
>>>>
>>>> package jfxtest;
>>>>
>>>> import javafx.application.Application;
>>>> import javafx.scene.Scene;
>>>> import javafx.scene.control.Button;
>>>> import javafx.scene.layout.StackPane;
>>>> import javafx.stage.Stage;
>>>>
>>>> public class JXTest extends Application {
>>>>
>>>>@Override
>>>>public void start(Stage primaryStage) throws Exception {
>>>>final StackPane pane = new StackPane();
>>>>final Button closeButton = new Button("Close");
>>>>closeButton.setOnAction(event -> primaryStage.close());
>>>>pane.getChildren().add(closeButton);
>>>>final Scene scene = new Scene(pane, 800, 600);
>>>>scene.getStylesheets().add("dark.css");
>>>>scene.getStylesheets();
>>>>primaryStage.setScene(scene);
>>>>primaryStage.setTitle(getClass().getSimpleName());
>>>>primaryStage.show();
>>>>}
>>>>
>>>>public static void main(String[] args) {
>>>>launch(args);
>>>>}
>>>> }
>>>>
>>>> with dark.css being:
>>>>
>>>> .root {
>>>>  -fx-background: rgb(54, 54, 54);
>>>> }
>>>>
>>>> Is this a Mac-specific problem? Is there a workaround? Which of the
>>>> two mailing lists is the more appropriate one to post these things
>>>> (JFX problems which look like they might be platform-specific) to?
>>>>
>>>> Thanks,
>>>>
>>>> Robert
>>>
>

Re: Ugly flashing when opening a css-styled stage

[Robert Krüger]

Thanks but it does not seem to improve the situation.

btw, I am using 1.8.0_05-b13 on Mac OS 10.9.3 on a retina MBP.

On Sun, Jun 1, 2014 at 9:59 PM, Jeff Martin  wrote:
> I haven't seen this, but here's a hack you can try:
>
> // Show stage transparent once to get proper drawing
> _stage.setOpacity(0); _stage.show(); _stage.hide(); 
> _stage.setOpacity(1);
>
> I've done this before to trigger Stage to set it's width/height property 
> (which I needed to position the stage property).
>
> jeff
>
>
> On Jun 1, 2014, at 3:18 AM, Robert Krüger  wrote:
>
>> Hi,
>>
>> I'm in the process of evaluating Java FX 8 for our currently
>> Swing-based product (also Java 8) on OSX.
>>
>> My first attempt to style a stage's background resulted in an ugly
>> flashing effect which I would classify as a show-stopper for
>> delivering a commercial product. This looks like it is caused by the
>> stage being drawn at least once before the style has been applied, and
>> I am wondering what the mistake is since my code is more or less a
>> straight-forward hello world:
>>
>> package jfxtest;
>>
>> import javafx.application.Application;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Button;
>> import javafx.scene.layout.StackPane;
>> import javafx.stage.Stage;
>>
>> public class JXTest extends Application {
>>
>>@Override
>>public void start(Stage primaryStage) throws Exception {
>>final StackPane pane = new StackPane();
>>final Button closeButton = new Button("Close");
>>closeButton.setOnAction(event -> primaryStage.close());
>>pane.getChildren().add(closeButton);
>>final Scene scene = new Scene(pane, 800, 600);
>>scene.getStylesheets().add("dark.css");
>>scene.getStylesheets();
>>primaryStage.setScene(scene);
>>primaryStage.setTitle(getClass().getSimpleName());
>>primaryStage.show();
>>}
>>
>>public static void main(String[] args) {
>>launch(args);
>>}
>> }
>>
>> with dark.css being:
>>
>> .root {
>>  -fx-background: rgb(54, 54, 54);
>> }
>>
>> Is this a Mac-specific problem? Is there a workaround? Which of the
>> two mailing lists is the more appropriate one to post these things
>> (JFX problems which look like they might be platform-specific) to?
>>
>> Thanks,
>>
>> Robert
>

Ugly flashing when opening a css-styled stage

[Robert Krüger]

Hi,

I'm in the process of evaluating Java FX 8 for our currently
Swing-based product (also Java 8) on OSX.

My first attempt to style a stage's background resulted in an ugly
flashing effect which I would classify as a show-stopper for
delivering a commercial product. This looks like it is caused by the
stage being drawn at least once before the style has been applied, and
I am wondering what the mistake is since my code is more or less a
straight-forward hello world:

package jfxtest;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

public class JXTest extends Application {

@Override
public void start(Stage primaryStage) throws Exception {
final StackPane pane = new StackPane();
final Button closeButton = new Button("Close");
closeButton.setOnAction(event -> primaryStage.close());
pane.getChildren().add(closeButton);
final Scene scene = new Scene(pane, 800, 600);
scene.getStylesheets().add("dark.css");
scene.getStylesheets();
primaryStage.setScene(scene);
primaryStage.setTitle(getClass().getSimpleName());
primaryStage.show();
}

public static void main(String[] args) {
launch(args);
}
}

with dark.css being:

.root {
  -fx-background: rgb(54, 54, 54);
}

Is this a Mac-specific problem? Is there a workaround? Which of the
two mailing lists is the more appropriate one to post these things
(JFX problems which look like they might be platform-specific) to?

Thanks,

Robert

Re: Integrating JFX Dialog/Stage in Swing application

[Robert Krüger]

That was quicker than I had hoped. Invoking close() on the stage
constructed in this way results in this here:

[ERROR|16:24:23] d.l.m.MediaTool Uncaught exception in thread JavaFX
Application Thread: [JavaFX Application Thread]
java.lang.IllegalStateException: This operation is permitted on the
event thread only; currentThread = JavaFX Application Thread
at com.sun.glass.ui.Application.checkEventThread(Application.java:427)
~[jfxrt.jar:na]
at com.sun.glass.ui.View.isClosed(View.java:409) ~[jfxrt.jar:na]
at 
com.sun.glass.ui.mac.MacTouchInputSupport.notifyNextTouchEvent(MacTouchInputSupport.java:122)
~[jfxrt.jar:na]
at 
com.sun.glass.ui.mac.MacGestureSupport.notifyNextTouchEvent(MacGestureSupport.java:77)
~[jfxrt.jar:na]

I checked in the debugger and com.sun.glass.ui.Application#eventThread
is null. This makes me believe the environment is not properly
initialized despite the invocation on new JFXPanel() that I have in
the EDT before the stage is built.

On Sat, May 31, 2014 at 4:15 PM, Robert Krüger  wrote:
> Hi Jeff,
>
> thanks, yeah, that's a workaround I have also found. I am just asking
> myself (and the JFX developers on this list) why this kind of
> Integration is not supported directly.
>
> Good to know that you have used this quite a bit. So I'll try using it
> until someone brings up a nicer solution or I run into any problems
> :-).
>
> Cheers,
>
> Robert
>
> On Sat, May 31, 2014 at 3:57 PM, Jeff Martin  wrote:
>> I'm sure this isn't the proper answer, but I have used this call to 
>> initialize the FX toolkit on demand from various Swing contexts and it has 
>> always worked for me:
>>
>> new javafx.embed.swing.JFXPanel();
>>
>> Then you would need the Platform.runLater(). Usually for the whole method 
>> that creates your UI and shows the Stage. In some cases, I would make the 
>> first line of my method that ends up invoking the JFX dialog something like 
>> this:
>>
>> public void doSomething()
>> {
>> // Ensure we're on FX thread
>> if(!Platform.isFXApplicationThread()) {
>> Platform.runLater(new Runnable() { public void run() { 
>> doSomething(); } return; }
>>
>> …  ...
>> }
>>
>> I've done quite a bit of this and it works without problems (for me).
>>
>> jeff martin
>>
>> On May 31, 2014, at 7:27 AM, Robert Krüger  wrote:
>>
>>> Hi,
>>>
>>> I am trying something which I thought would technically be the easiest
>>> way of migrating parts of an existing application from Swing to JFX,
>>> i.e. have a Swing JMenuItem trigger the showing of a JFX stage because
>>> I thought this would technically even be cleaner than to have a swing
>>> dialog containing an JFXPanel.
>>>
>>> Doing this results in the following Exception:
>>>
>>> java.lang.IllegalStateException: Toolkit not initialized
>>> at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:276)
>>> ~[jfxrt.jar:na]
>>> at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:271)
>>> ~[jfxrt.jar:na]
>>> at javafx.application.Platform.runLater(Platform.java:78) ~[jfxrt.jar:na]
>>> at 
>>> de.lesspain.mediatool.menu.ToolsSubmenu$1.actionPerformed(ToolsSubmenu.java:20)
>>> ~[
>>>
>>> javadoc of runLater states:
>>>
>>> This method must not be called before the FX runtime has been
>>> initialized. For standard JavaFX applications that extend Application,
>>> and use either the Java launcher or one of the launch methods in the
>>> Application class to launch the application, the FX runtime is
>>> initialized by the launcher before the Application class is loaded.
>>> For Swing applications that use JFXPanel to display FX content, the FX
>>> runtime is initialized when the first JFXPanel instance is
>>> constructed.
>>>
>>> So this is consistent. Still I am wondering, why it should not be
>>> supported to just trigger opening a stage from a Swing menu? Either by
>>> Platform.runLater autoinitializing or offering a separate method like
>>> Platform.ensureInitialized().
>>>
>>> Am I missing something obvious?
>>>
>>> Thanks,
>>>
>>> Robert
>>
>
>
>
> --
> Robert Krüger
> Managing Partner
> Lesspain GmbH & Co. KG
>
> www.lesspain-software.com



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Re: Integrating JFX Dialog/Stage in Swing application

[Robert Krüger]

Hi Jeff,

thanks, yeah, that's a workaround I have also found. I am just asking
myself (and the JFX developers on this list) why this kind of
Integration is not supported directly.

Good to know that you have used this quite a bit. So I'll try using it
until someone brings up a nicer solution or I run into any problems
:-).

Cheers,

Robert

On Sat, May 31, 2014 at 3:57 PM, Jeff Martin  wrote:
> I'm sure this isn't the proper answer, but I have used this call to 
> initialize the FX toolkit on demand from various Swing contexts and it has 
> always worked for me:
>
> new javafx.embed.swing.JFXPanel();
>
> Then you would need the Platform.runLater(). Usually for the whole method 
> that creates your UI and shows the Stage. In some cases, I would make the 
> first line of my method that ends up invoking the JFX dialog something like 
> this:
>
> public void doSomething()
> {
> // Ensure we're on FX thread
> if(!Platform.isFXApplicationThread()) {
> Platform.runLater(new Runnable() { public void run() { 
> doSomething(); } return; }
>
> …  ...
> }
>
> I've done quite a bit of this and it works without problems (for me).
>
> jeff martin
>
> On May 31, 2014, at 7:27 AM, Robert Krüger  wrote:
>
>> Hi,
>>
>> I am trying something which I thought would technically be the easiest
>> way of migrating parts of an existing application from Swing to JFX,
>> i.e. have a Swing JMenuItem trigger the showing of a JFX stage because
>> I thought this would technically even be cleaner than to have a swing
>> dialog containing an JFXPanel.
>>
>> Doing this results in the following Exception:
>>
>> java.lang.IllegalStateException: Toolkit not initialized
>> at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:276)
>> ~[jfxrt.jar:na]
>> at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:271)
>> ~[jfxrt.jar:na]
>> at javafx.application.Platform.runLater(Platform.java:78) ~[jfxrt.jar:na]
>> at 
>> de.lesspain.mediatool.menu.ToolsSubmenu$1.actionPerformed(ToolsSubmenu.java:20)
>> ~[
>>
>> javadoc of runLater states:
>>
>> This method must not be called before the FX runtime has been
>> initialized. For standard JavaFX applications that extend Application,
>> and use either the Java launcher or one of the launch methods in the
>> Application class to launch the application, the FX runtime is
>> initialized by the launcher before the Application class is loaded.
>> For Swing applications that use JFXPanel to display FX content, the FX
>> runtime is initialized when the first JFXPanel instance is
>> constructed.
>>
>> So this is consistent. Still I am wondering, why it should not be
>> supported to just trigger opening a stage from a Swing menu? Either by
>> Platform.runLater autoinitializing or offering a separate method like
>> Platform.ensureInitialized().
>>
>> Am I missing something obvious?
>>
>> Thanks,
>>
>> Robert
>



-- 
Robert Krüger
Managing Partner
Lesspain GmbH & Co. KG

www.lesspain-software.com

Integrating JFX Dialog/Stage in Swing application

[Robert Krüger]

Hi,

I am trying something which I thought would technically be the easiest
way of migrating parts of an existing application from Swing to JFX,
i.e. have a Swing JMenuItem trigger the showing of a JFX stage because
I thought this would technically even be cleaner than to have a swing
dialog containing an JFXPanel.

Doing this results in the following Exception:

java.lang.IllegalStateException: Toolkit not initialized
at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:276)
~[jfxrt.jar:na]
at com.sun.javafx.application.PlatformImpl.runLater(PlatformImpl.java:271)
~[jfxrt.jar:na]
at javafx.application.Platform.runLater(Platform.java:78) ~[jfxrt.jar:na]
at 
de.lesspain.mediatool.menu.ToolsSubmenu$1.actionPerformed(ToolsSubmenu.java:20)
~[

javadoc of runLater states:

This method must not be called before the FX runtime has been
initialized. For standard JavaFX applications that extend Application,
and use either the Java launcher or one of the launch methods in the
Application class to launch the application, the FX runtime is
initialized by the launcher before the Application class is loaded.
For Swing applications that use JFXPanel to display FX content, the FX
runtime is initialized when the first JFXPanel instance is
constructed.

So this is consistent. Still I am wondering, why it should not be
supported to just trigger opening a stage from a Swing menu? Either by
Platform.runLater autoinitializing or offering a separate method like
Platform.ensureInitialized().

Am I missing something obvious?

Thanks,

Robert

Re: JavaFX 2 + with LWJGL ( OpenGL )

[Robert Krüger]

The same holds for our application which includes a video player where
we need every little bit of performance, especially when dealing with
HD and Ultra-HD content, where every additional copy or pixel format
conversion step hurts, just to add a tiny little bit of weight.

Cheers,

Robert

On Tue, Apr 8, 2014 at 11:20 AM, Matthias Hänel  wrote:
> Hey guys,
>
>
> I followed the discussion with interest. I just checked the lwjdlfx-approach. 
> It looked promising in the first place but it has still major performance 
> issues. It is based on the snapshot functionality
> in the Node base class. This is actually a similar approach we've seen in the 
> JFXPanel
> which indeed has horrible performance. From my point of view it is not the 
> way to go.
>
>
> What I really like to see is a way to get a textureID directly into the JavaFX
> opengl context wraped with an Image object. I know it's pretty hard to do 
> this cross-platform
> and cross-implementation (DirectX, OpenGl) but otherwise JFX can't be mixed 
> with Third-Party
> applications.
>
> Okay, using JFX on top of a OpenGL game just as a replacement of the 
> UI-framework like Ogre-UI
> etc. might still be a good point since there is no high performance need.
>
> In our case we need both high performance UI and high performance additional 
> OpenGL drawings.
> As of today I could only use JavaFX with a SwingPanel that encapsulates a 
> JOGL context...
>
>
> just my 2 cents
> Matthias
>
>
> Am 07.04.2014 um 18:47 schrieb Stephen F Northover 
> :
>
>> The lwjglfx solution.
>>
>> Steve
>>
>> On 2014-04-07 12:45 PM, Exo Verse wrote:
>>> @ Steve
>>> Which approach are you referring too ? The lwjglfx solution or this
>>> transparency background solution ?
>>>
>>> The lwjglfx I am assuming here since its drawing out to an image and back
>>> in again. But if your speaking about my transparency issue I solved, I
>>> didn't realize it was sending out to an image and back again. Could you
>>> please elaborate as to which solution your speaking about ?
>>>
>>> Torak
>>>
>>>
>>> On Mon, Apr 7, 2014 at 12:33 PM, Stephen F Northover <
>>> steve.x.northo...@oracle.com> wrote:
>>>
 This solution is cool, but it draws to an image, sucks out the bits and
 then converts that to an FX image.  This is a good approach because it uses
 API and does not rely on any internals of FX. Hopefully it is fast enough
 for you.

 Steve


 On 2014-04-06 12:41 PM, Exo Verse wrote:

> Yea the OpenGL comes with your graphics drivers for your video card. So
> your correct that it doesn't ship with JavaFX. What I have been going on
> about is trying to find a way to use JavaFX with LWJGL. In case you are
> unaware, LWJGL just means "Light Weight Java OpenGL" and its a wrapper for
> the OpenGL API. It's an alternative to JOGL.
>
> On another note, as I did a search, Thanks to Tom showing me that link I
> examined that code and I found something of interest in the JOGL code
> interface..  well it lead me to a google search, and viola..  LWJGL with
> JavaFX. :)
>
> LINK :
> https://github.com/Spasi/LWJGL-FX
>
> So just wanted to post the link here and say thanks for all of your help.
> :)
>
> Cheers,
> Torak
>
>
> On Sun, Apr 6, 2014 at 12:35 PM, Tom Schindl > wrote:
>  JavaFX does not ship OpenGL binaries on windows you have to build it your
>> own.
>>
>> Please note:
>> a) if there are people who manage to write a prism pipeline on jogl why
>> should you not be able to do the same with lwjgl?
>> b) the talk i mentionned from felipe and steve show how to get access to
>> the native OpenGL context and there from you can use any API you like
>> can't
>> remember which one they used
>>
>> Tom
>>
>> Von meinem iPhone gesendet
>>
>>  Am 06.04.2014 um 18:18 schrieb Exo Verse :
>>> Thanks, but as I mentioned in my original post, I don't like JOGL. It
>>> doesn't work with my setup. I use LWJGL because its only about the
>>> OpenGL
>>> and not other libraries, and its an easy API wrapper to use. There are
>>>
>> many
>>
>>> many reason I hate JOGL.. but this thread is not about hating on JOGL,
>>>
>> its
>>
>>> about finding a way to use LWJGL with JavaFX2+.
>>>
>>> Also, Win32 API calls can use both DirectX and OpenGL APIs. And it
>>>
>> doesn't
>>
>>> matter what Windows OS you're using. I have tested this out from Windows
>>>
>> XP
>>
>>> all the way to Windows 7 - 32/64 Bit with no problem.
>>>
>>> Cheers
>>> Torak
>>>
>>>
>>> On Sun, Apr 6, 2014 at 11:52 AM, Tom Schindl <
>>>
>> tom.schi...@bestsolution.at>wrote:
>>
>>> There is a talk from Felipe and Steve at J1 last year how to embed
>>> OpenGL
>>> into FX using *internal* API!
 Search for it on parleys - this 

Re: Expected frame rates for a full-screen blur

[Robert Krüger]

On Tue, Apr 1, 2014 at 7:49 PM, Mike Hearn  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.

Not exactly the main point of this thread but when was the last time
you tried this? Swing has Retina support now. In some cases, like when
rendering Images, there is some extra work but there is no reason a
Swing app should look blurry on a Retina Mac.

Re: To Be Or Not To Be (Native), was:Look and feel mechanism?

[Robert Krüger]

Amen and +1.

On Tue, Dec 10, 2013 at 9:11 PM, Stephen F Northover
 wrote:
> As I said before, it would be up to the application.  If it was critical
> that your application do something like embed Excel, then it could live with
> the limitations.  Perhaps you work in a company where you have a custom
> native control that you are already embedding in Swing and you want to
> migrate to FX.  These sorts of applications could live with the limitations.
>
> Steve
>
> On 2013-12-10 3:03 PM, Felix Bembrick wrote:
>>
>> Do you think it's either feasible or viable to the extent that a
>> successful implementation would not have the limitations such as lack of
>> transparency or be limited by the inability to apply Node transforms and
>> functionality to native controls?  I mean, such a large undertaking would
>> only made sense if the end result gave us something we don't have now and
>> that it worked well.
>>
>> Felix
>>
>>
>>
>> On 11 December 2013 06:57, Stephen F Northover
>> mailto:steve.x.northo...@oracle.com>> wrote:
>>
>> I was very interesting in heavyweight integration a while back but
>> could not get anyone very enthusiastic about it.
>>
>> Steve
>>
>>
>> On 2013-12-10 1:35 PM, Felix Bembrick wrote:
>>>
>>> Stephen, why do you refer to this discussion as "academic"?
>>>
>>> Felix
>>>
>>>
>>>
>>> On 11 December 2013 05:20, Stephen F Northover
>>> >> > wrote:
>>>
>>> Yes, if it helps an application ship using the components and
>>> technology they need to make their product successful.  In
>>> any case, this discussion is academic.
>>>
>>> Steve
>>>
>>>
>>> On 2013-12-10 12:25 PM, Anthony Petrov wrote:
>>>
>>> We have implemented HW/LW components mixing for AWT/Swing
>>> in the past [1]. However, the feature is very limited (no
>>> transparency support, etc.), and the limitations come
>>> from native system capabilities that can't be worked
>>> around easily.
>>>
>>> Do we really want something limited like this in FX?
>>>
>>> [1]
>>>
>>> http://www.oracle.com/technetwork/articles/java/mixing-components-433992.html
>>>
>>> -- best regards,
>>> Anthony
>>>
>>> On 12/10/2013 06:14 AM, Stephen F Northover wrote:
>>>
>>> At one point,  I was very interested in seeing this
>>> happen but there
>>> wasn't the band width and resources.
>>>
>>> Steve
>>>
>>> On 2013-12-09 1:00 PM, Felix Bembrick wrote:
>>>
>>> What can we expect from the JavaFX team in this
>>> regard in the future?
>>> I know we have talked about mixing lightweight
>>> and heavyweight
>>> controls in the same context but is it going to
>>> happen? Is this
>>> planned for JFX9 perhaps? Is it *really* even
>>> feasible?
>>>
>>> On 10 Dec 2013, at 4:55, Stephen F Northover
>>> >> > wrote:
>>>
>>> Today, you can only exercise the choice by
>>> writing native code and
>>> you face heavyweight / lightweight issues
>>> depending on the platform
>>> and API.
>>>
>>> Steve
>>>
>>> On 2013-12-09 12:31 PM, Felix Bembrick wrote:
>>> Stephen, I thoroughly agree that JavaFX
>>> is by far the best choice
>>> for non-native apps/widgets which is
>>> precisely my point. They are
>>> the kind of apps perfect for using JavaFX.
>>>
>>> But you refer to giving people the choice
>>> to go native where
>>> appropriate. How can I exercise that
>>> choice? Where is the support
>>> for native widgets in JavaFX?
>>>
>>> And isn't the real Holy Grail being able
>>> to mix native and
>>> non-native widgets in the same app with
>>> all features of Node being
>>> available to every widget, with all the
>>> effects and transforms, all
>>> the CSS/styling and with all the performance?
>>>
>>> Could JavaFX ever be such a toolkit?
>>>
>>> On 10 Dec 2013, at 2:24, Stephen F
>>>

Re: Media is now opensource

[Robert Krüger]

Absolutely the best option for the platform. If, before such a
mechanism is in place, interested parties have an option to do
something (even if it is a hack), that's a good thing anyway.

On Fri, Oct 18, 2013 at 8:53 PM, Scott Palmer  wrote:
> I propose the codecs be made pluggable.  The licensing issue can be left to 
> the application developer.
>
> https://javafx-jira.kenai.com/browse/RT-2684
>
> Once that is in place, support for whatever codec you wish can be added. 
> FFMPEG could be used as an example.
> I'm against adding any new codecs without first putting in a user-extensible 
> codec mechanism that does not require modifying JavaFX to support new 
> formats.  I.e. make the dog food first, then eat it.
>
> Scott
>
> On 2013-10-18, at 2:03 PM, Kirill Kirichenko  
> wrote:
>
>> Media is very regulated area in legal terms. Using different codecs may 
>> involve using and even violating some license agreements.
>> Anyway you're welcome to propose anything.
>>
>>
>> On 18.10.2013 21:37, Robert Krüger wrote:
>>> Great news!
>>>
>>> Does this mean that it is now possible to add support for more
>>> demuxers/decoders e.g. by utilizing stuff from other projects (ffmpeg
>>> comes to mind)?
>>>
>>> On Fri, Oct 18, 2013 at 6:35 PM, Kirill Kirichenko
>>>  wrote:
>>>> Hello OpenJFXers !
>>>> We're happy to announce that Media part of JavaFX is now open source.
>>>> Opensourcing touched all Media component except ON2 FLV demuxer and VP6
>>>> decoder. The decoder will remain closed.
>>>>
>>>> You're all welcome to contribute.
>>>>
>>>> Thanks,
>>>> K
>

Re: Media is now opensource

[Robert Krüger]

Great news!

Does this mean that it is now possible to add support for more
demuxers/decoders e.g. by utilizing stuff from other projects (ffmpeg
comes to mind)?

On Fri, Oct 18, 2013 at 6:35 PM, Kirill Kirichenko
 wrote:
> Hello OpenJFXers !
> We're happy to announce that Media part of JavaFX is now open source.
> Opensourcing touched all Media component except ON2 FLV demuxer and VP6
> decoder. The decoder will remain closed.
>
> You're all welcome to contribute.
>
> Thanks,
> K

Re: JDK 8 for ARM Early Access Releases (with JavaFX)

[Robert Krüger]

That is indeed excellent news. Can't wait to use it on my pi :-).

On Wed, Jul 10, 2013 at 4:22 PM, Gerrit Grunwald  wrote:
> I made some tests already and I have to say it works really well. You can
> also use custom JavaFX8 controls without any problem. I just saw some
> problems with complex -fx-shape based paths. The performance improvements
> are really visible, so Oracle did a good job here.
> Because it's based on b97 you can also use lambdas, 3D and even Nashorn
> should be useable (even if I did not tried yet).
>
> Now it's really useful because you could easily use the same jar of your
> application and let it run on the Pi without any modification.
>
> Cheers,
>
> Gerrit
>
>
>
> Am 10.07.2013 um 16:14 schrieb Robert Krüger :
>
> If anyone plays around with this on the Raspberry, please share your
> experience here.
>
> On Wed, Jul 10, 2013 at 3:09 PM,   wrote:
>
> JDK 8 for ARM hard float is now part of the regular JDK 8 Early Access
> releases. You can get it athttps://jdk8.java.net/download.html; this
>
> page will be regularly updated with new builds.
>
> As in the previous Early Access release, this includes JavaFX for the
> Raspberry Pi.
>
> Daniel
>
>

Re: JDK 8 for ARM Early Access Releases (with JavaFX)

[Robert Krüger]

If anyone plays around with this on the Raspberry, please share your
experience here.

On Wed, Jul 10, 2013 at 3:09 PM,   wrote:
> JDK 8 for ARM hard float is now part of the regular JDK 8 Early Access
> releases. You can get it athttps://jdk8.java.net/download.html; this
>
> page will be regularly updated with new builds.
>
> As in the previous Early Access release, this includes JavaFX for the
> Raspberry Pi.
>
> Daniel
>

Re: JDK 8 for ARM Early Access Releases (with JavaFX)

[Robert Krüger]

Probably something wrong with your email software or something eats
the content on the way. You keep sending mails with empty bodies.

On Wed, Jul 10, 2013 at 12:20 PM, Daniel Blaukopf
 wrote:
>

Re: Experience with piecewise migration Swing -> JFX

[Robert Krüger]

So it is basically "be aware of potential problems when doing things
in different threads" which is nothing new for our app as we have some
native stuff that responds to events in the Mac OS app kit thread but
nothing inherent to JavaFX as far as I can see.  This is what I had
hoped.

Thank you.

On Sun, Jun 16, 2013 at 7:19 PM, Pedro Duque Vieira
 wrote:
> I've grabbed my previous blog post about this subject and rewritten it to be
> more up-to-date with the current state of things.
> I'm sorry for the publicity but this is a far easier way to explain what
> I've learned about the subject -
> http://pixelduke.wordpress.com/2013/06/16/integrating-javafx-and-swing-revised/?preview=true&preview_id=542&preview_nonce=e92735d108
>
> Cheers, hope this helps,
>
>
> On Sun, Jun 16, 2013 at 8:28 AM, Robert Krüger  wrote:
>>
>> On Sat, Jun 15, 2013 at 11:39 PM, Pedro Duque Vieira
>>  wrote:
>> > My biggest problems were with having 2 UI threads.
>> >
>> > I ran into some concurrency issues between the 2.
>> >
>> Meaning things that just needed extra care or things that were hard to
>> work around? Could you elaborate a bit?
>
>
>
>
> --
> Pedro Duque Vieira