And with the nVidia GPU again smooth as glass. My driver is listed as:
Driver nvd3dumx.dll, version 10.18.13.5415
Note that the umx.dll driver is the 64-bit display driver (found in
System32 oddly enough because Windows is backwards that way). The
version of the driver named um.dll (
For reference, I just ran the Ensemble8 demo on a Windows 10 laptop with
a 200% scaled HiDPI screen (3000x2000) with integrated Intel HD Graphics
520 and it ran smooth as glass, even the 3D samples.
The laptop also has an embedded nVidia 900 series GPU, but I need to
figure out why it isn't ge
Hi Jim,
I have experimented with all those options with the following results:
1. Turning on verbose proves hardware acceleration is being used.
2. Increasing texture size and fiddling with the amount of VRAM has no
effect on performance.
3. Turning off Hi DPI changes the appearance of the app (i
Other things to try:
-Dprism.verbose=true (output should show the following options
are working)
-Dglass.win.uiScale=1.0 (disables HiDPI)
-Dprism.order=sw (disables HW acceleration)
-Dprism.maxTextureSize=8192 (mentioned before - increases max texture
dims)
-Dp
faster because of the
> differences in hardware... but the lack of performance is the poor code in
> your software.
>
> - Original Message -
> From: "Felix Bembrick"
> To: "Bogdan Ibanescu"
> Cc: "Chris Nahr" , openjfx-dev@openjdk.java
I doubt it would be simply a "number of pixels" issue. I don't have a
4K monitor, but I've run it on some HiDPI monitors that keep up just
fine with much more modest hardware.
There are a couple of possible things that may get in the way:
- Our max texture size is 4096x4096 which should be la
Hi Jim,
I had Windows 10 on my previous machine and my wife's low-end PC is also
running Win10 and the same version of Java.
But I have what is supposed to be the fastest graphics card of all (GeForce GTX
Titan X) and she has a very basic card.
The only real difference is that she has a 22" mo
Have you tried running it with -Dprism.verbose=true flag?
It should provide some debug output.
Best regards,
Alexander Kouznetsov
(408) 276-0387
On 30 окт 2015 3:55, Felix Bembrick wrote:
The NVIDIA Control Panel allowed me to disable SLI completely and I even
rebooted. I also upgraded to Ja
ving 200 cores won't help you with anything unless you explicitly customize
> your code to make use of them.
>
> - Original Message -
> From: "Felix Bembrick"
> To: "Chris Nahr"
> Cc: openjfx-dev@openjdk.java.net
> Sent: Friday, October 30, 20
It should be supported. Which version of Windows were you using before?
We've supported HiDPI on Windows since JDK8u60 on all supported
versions of Windows...
...jim
On 10/27/15 11:24 PM, Felix Bembrick wrote:
I just installed JavaFX on my new Windows 10 machine whic
Nahr" , openjfx-dev@openjdk.java.net
Sent: Friday, October 30, 2015 5:37:35 PM
Subject: Re: Windows Hi-DPI
Yes, but unless you are saying that having more cores, more VRAM, faster VRAM
and a much faster clock speed are actually going to slow down the performance
of JavaFX then I don'
ot;
Cc: "Chris Nahr" , openjfx-dev@openjdk.java.net
Sent: Friday, October 30, 2015 5:37:35 PM
Subject: Re: Windows Hi-DPI
Yes, but unless you are saying that having more cores, more VRAM, faster VRAM
and a much faster clock speed are actually going to slow down the performance
of Ja
Having 200 cores won't help you with anything unless you explicitly customize
your code to make use of them.
- Original Message -
From: "Felix Bembrick"
To: "Chris Nahr"
Cc: openjfx-dev@openjdk.java.net
Sent: Friday, October 30, 2015 11:55:19 AM
Subject: Re: W
The NVIDIA Control Panel allowed me to disable SLI completely and I even
rebooted. I also upgraded to Java 8u72.
Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a
chain.
All other 3D apps, games etc. perform blindingly fast as I would expect.
So, if it's not an SLI
That's curious. SLI is designed specifically with gamers in mind!
I'll investigating running without SLI and report back.
Felix
> On 30 Oct 2015, at 19:44, Chris Nahr wrote:
>
> If it's slower on an SLI machine than on an ordinary one then yes, I suspect
> JavaFX just can't handle SLI proper
I am using Java 8u66 and performance is really poor.
I suspected a driver issue but I have the latest driver for my Titan X card (4
in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in
the top 1% fastest computers ever to run the tests.
It looks to me that JavaFX just c
If it's slower on an SLI machine than on an ordinary one then yes, I
suspect JavaFX just can't handle SLI properly. Among gamers I've often
heard that it's a notoriously problematic configuration. Can you switch
your card to non-SLI mode and retest performance?
--Chris
On 2015-10-30 09:19, Fe
Hi-DPI is supported on Windows, assuming you have 8u60 or later (better
8u66 or later so a ComboBox doesn't freeze the application!). On my Dell
XPS-15 with Windows 10 and 4K displays JavaFX also uses hardware
acceleration, in this case with the Intel 4600 integrated GPU.
However, this causes
I just installed JavaFX on my new Windows 10 machine which is extremely
powerful but has two 4K monitors and while everything looks great and the right
"size", the performance is very sluggish to say the least.
Is this because Hi-DPI is not yet supported in JavaFX on Windows?
Thanks,
Fix
On 2/18/2015 2:13 AM, Werner Lehmann wrote:
Finally, it would be nice to get information about the actual screen
DPI. In my tests Screen.getDpi always returns 96, regardless of what it
actually is...
I'm not sure if there is a legacy API for that value in Windows
pre-Win8.1, but I know that
Thanks for looking at this Werner!
On 2/18/2015 2:13 AM, Werner Lehmann wrote:
Hi Jim,
As to the question of integer vs float
coordinates, there is a lot of snapToPixel stuff going on. And one of
the reasons is to get crisp pixel-aligned lines. Snapping to logical
coordinates could then snap to
My usecase is not about "retina or not". It is about showing a report
result in "actual size" which means I need to scale it depending on the
screen DPI.
Current workaround is this...
-Dcom.sun.javafx.screenDPI=109
...but I can't really advertise this to users.
Werner
On 18.02.2015 12:23, M
>
> Finally, it would be nice to get information about the actual screen DPI.
> In my tests Screen.getDpi always returns 96, regardless of what it actually
> is...
You can reflectively access Screen.getPixelScale() to learn if you're on
Retina. Of course, don't expect to swap out the JRE for a ne
Hi Jim,
interesting read. I guess I learned more about the topic than I can
help. Also found this resource interesting:
http://kynosarges.de/GuiDpiScaling.html
Some thoughts. Obviously it is less desirable to require every
application to do their own scaling. I can't imagine that this would
One interesting point to note that makes one concern seem less
compelling in a practical sense:
On 2/17/2015 5:27 PM, Jim Graham wrote:
To get an idea of the kinds of problems we might encounter when trying
to translate the screens into "virtual coordinates", consider that the
default layout of
I'm currently investigating what changes we need to make to get Windows
HiDPI support up and running. As it stands, anyone with a Hi DPI
Windows machine will see all Java and JavaFX programs run very tiny
since the Java executables have declared that we are "DPI Aware" in the
program manifest
26 matches
Mail list logo
