Hi,
I agree with most that has been said here, but I want to add a few things.
I've seen a number of "performance issues" with JavaFX in customer
projects. Most of them are simply due to the application doing things on
the FX App Thread that shouldn't be done there.
Apart from these obvious thin
Sorry, take 2.
Thanks - that's very helpful.
I have been concentrating on profiling the Java aspects of FXMark so this gives
me more things to try.
I will report back with my findings.
Blessings,
Felix
> On 22 Jul 2016, at 19:02, Vadim Pakhnushev
> wrote:
>
>> On 22.07.2016 11:15, Felix B
> On 22 Jul 2016, at 19:02, Vadim Pakhnushev
> wrote:
>
>> On 22.07.2016 11:15, Felix Bembrick wrote:
>> Hi Vadim,
>>
>> I am very open-minded about this. Anything is possible (including, as I
>> mentioned, that I wrote FXMark very poorly).
>>
>> Can you help by detailing what tools you use
On 22.07.2016 11:15, Felix Bembrick wrote:
Hi Vadim,
I am very open-minded about this. Anything is possible (including, as I
mentioned, that I wrote FXMark very poorly).
Can you help by detailing what tools you use to track CPU/GPU usage?
I personally use Process Hacker (I'm on Windows) and
Hi Vadim,
I am very open-minded about this. Anything is possible (including, as I
mentioned, that I wrote FXMark very poorly).
Can you help by detailing what tools you use to track CPU/GPU usage?
I am sure finding out the exact nature of what is happening and what is causing
it will help every
Felix,
For me it's very useful to track CPU/GPU usage while running a benchmark.
Could it be that your very fast machine is limited by some
synchronization issues and CPU/GPU is essentially idle while slower
machine is running 100% CPU?
Vadim
On 22.07.2016 3:35, Felix Bembrick wrote:
I am w
I am willing to accept that perhaps FXMark is written so poorly that it
does not permit JavaFX to perform as well as it could (possibly
significantly so) on any particular platform.
And I am indeed going through the code line-by-line and doing all manner of
profiling to try to answer this question
> On Jul 21, 2016, at 6:18 PM, Richard Bair wrote:
>
> Hi Steve,
>
> It could be a benchmark problem, although I wouldn’t be surprised at all if
> the benchmark was exercising the platform in some way that was CPU limited.
> Assuming it is CPU limited (and not going multi-core), I think the p
We use a lot of Nodes which we update dynamically from another Client App. We
also use JavaFX animations, but admittedly not a lot of them concurrently.
In our case JavaFX animations are mainly linked to user interactions, a lot of
what is dynamic in our apps is directly a result of real data c
Hi Steve,
It could be a benchmark problem, although I wouldn’t be surprised at all if the
benchmark was exercising the platform in some way that was CPU limited.
Assuming it is CPU limited (and not going multi-core), I think the problem
really comes down to what Markus said:
> The limiting fac
Hi Herve,
Thanks for chiming in. I agree. From my own experience and benchmarking with
other app-dev GUI toolkits, JavaFX performs very well for a very wide range of
use cases. That being said, performance was always a passion of mine and I know
there is more to be had. I like Kevin’s idea of
I agree that the original question has led to a discussion of a somewhat
different nature and I accept that the benchmark itself may be problematic.
But others have reported similar observation using different benchmarks.
> On 22 Jul 2016, at 07:42, Steve Hannah wrote:
>
> I've just been a fly
Are you using nodes, transitions, effects and animations? Or are you using the
Canvas node only?
> On 22 Jul 2016, at 07:33, Hervé Girod wrote:
>
> I really don't understand all this. We use Java FX 8 in a graphic framework
> where we need high performance (prototyping Cockpit Display Systems
I've just been a fly on the wall for this thread, but ... I think this
thread has gone off track a bit. Felix's original observation was that he
got the same benchmark results from two machines that should produce
different results because one is more powerful than the other in both CPU
and GPU).
I really don't understand all this. We use Java FX 8 in a graphic framework
where we need high performance (prototyping Cockpit Display Systems with
dynamic Maps and Head Up Displays), and we find that JavaFX performance is
pretty good our use case. For example, Qt / QML performance is far worse
Yes, well I think this the problem:
1) Going on history, it would be a best case scenario for Java 10 to be
released in 2020 (but more likely 2021).
2) With JavaFX, we are already "behind the game" (pun intended).
3) JavaFX itself has evolved much slower than its competitors.
4) Technology in
net] On Behalf Of
Dr. Michael Paus
Sent: Donnerstag, 21. Juli 2016 12:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Scene graph performance
Hi Felix,
I have written various tests like the ones you use in FXMark and I have
obtained similar results. I have even tried to substitute 2D shapes by u
Paus
Sent: Donnerstag, 21. Juli 2016 12:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Scene graph performance
Hi Felix,
I have written various tests like the ones you use in FXMark and I have
obtained similar results. I have even tried to substitute 2D shapes by using 3D
MeshViews in the hop
d rendering (a.k.a tiled rendering).
>>>>>
>>>>> I am pretty sure you can add a lot more ideas to the list and produce
>>>>> great performance, scaling linearly with number of CPU cores / GPU cores,
>>>>> but this somes at a cost: Risk to introduce hard to track
aus
Sent: Donnerstag, 21. Juli 2016 12:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Scene graph performance
Hi Felix,
I have written various tests like the ones you use in FXMark and I have
obtained similar results. I have even tried to substitute 2D shapes by using 3D
MeshViews in the ho
has at least a lot of free spare time, I am pretty sure Kevin
>>> could easily provide a huge set of work items in this area. :-)
>>>
>>> -Markus
>>>
>>> -Original Message-
>>> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.jav
Hi Richard,
Wow! Thanks - you really know your stuff!
Yes, it's not a "one LOC change" and I get that it has a lot to do with the
difficult marriage of 2D and 3D worlds.
And it does seem like a large project in itself to solve these problems but, I
really believe it *has* to be done and I inte
r. Michael Paus
Sent: Donnerstag, 21. Juli 2016 12:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Scene graph performance
Hi Felix,
I have written various tests like the ones you use in FXMark and I have
obtained similar results. I have even tried to substitute 2D shapes by using 3D
MeshViews i
-
> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
> Dr. Michael Paus
> Sent: Donnerstag, 21. Juli 2016 12:07
> To: openjfx-dev@openjdk.java.net
> Subject: Re: Scene graph performance
>
> Hi Felix,
> I have written various tests like the
uge set of work items in this area. :-)
-Markus
-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
Dr. Michael Paus
Sent: Donnerstag, 21. Juli 2016 12:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Scene graph performance
Hi Felix,
I have
Have you guys profiled the application to see where the CPU time is spent? How
many nodes in the app?
In the past the majority of CPU time has been spent in one or more of the
following (not sure if it still applies):
- Computing changed bounds (a lot of work was done to speed this up, but I
I would add that neither JOGL nor LWJGL have these issues.
Yes, I know they are somewhat different "animals", but the point is, clearly
*Java* is NOT the cause.
> On 21 Jul 2016, at 20:07, Dr. Michael Paus wrote:
>
> Hi Felix,
> I have written various tests like the ones you use in FXMark and
Hi Michael,
Thanks for your response.
This is what I suspected: what is ostensibly a hardware accelerated toolkit
seems to barely utilise the GPU for scene graph animations.
But, even with that, my machine has dual high performance 16-core Xeons while
my wife's machine has a single 2-core i5 a
Hi Felix,
I have written various tests like the ones you use in FXMark and I have
obtained similar results. I have even tried to substitute 2D shapes by
using 3D MeshViews in the hope that this would give better performance
but the results were not that good. Of course all this depends on the
spec
29 matches
Mail list logo
