james.graham at oracle.com
Mon Nov 2 21:50:10 UTC 2015
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 (which your run seems to be using) is
the 32-bit version of the driver (found in SysWOW64 which is where
Windows puts 32-bit drivers on a Win64 system just to make things
Are you running on the 32-bit VM? Have you tried the 64-bit VM?
On 11/2/2015 1:24 PM, Jim Graham wrote:
> 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 getting used when I run FX. I'll note, though,
> that this laptop is using an older version of the nVidia drivers
> (354.15) which was installed by Windows and which is considered "up to
> date" when I run an update check in the nVidia Control Panel. You
> appear to be running 358.50 which is the latest WHQL version from
> nVidia's web site? I looked and nVidia doesn't even offer 354.15 even
> in their history of drivers...
> On 10/30/2015 5:40 PM, Felix Bembrick wrote:
>> 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.e. controls
>> are too small etc.) but has no effect on performance.
>> 4. Disabling hardware acceleration makes it another order of magnitude
>> slower than before.
>> So none of the options improved performance at all. All we know for
>> sure is that it's using D3D and that it is running so much slower than I
>> expected and so much so that it is unusable.
>> Here's some of the initial output which hopefully shows something about
>> the issue:
>> */Prism pipeline init order: d3d
>> Using native-based Pisces rasterizer
>> Using dirty region optimizations
>> Not using texture mask for primitives
>> Not forcing power of 2 sizes for textures
>> Using hardware CLAMP_TO_ZERO mode
>> Opting in for HiDPI pixel scaling
>> Prism pipeline name = com.sun.prism.d3d.D3DPipeline
>> Loading D3D native library ...
>> D3DPipelineManager: Created D3D9Ex device
>> Direct3D initialization succeeded
>> (X) Got class = class com.sun.prism.d3d.D3DPipeline
>> Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline
>> Maximum supported texture size: 16384
>> Maximum texture size clamped to 8192
>> OS Information:
>> Windows version 10.0 build 10240
>> D3D Driver Information:
>> NVIDIA GeForce GTX TITAN X
>> Driver nvd3dum.dll, version 10.18.13.5850
>> Pixel Shader version 3.0
>> Device : ven_10DE, dev_17C2, subsys_113210DE
>> Max Multisamples supported: 4
>> vsync: true vpipe: true
>> Loading Prism common native library .../*
>> */ succeeded.
>> PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_28
>> PPSRenderer: scenario.effect - createShader: LinearConvolve_8
>> PPSRenderer: scenario.effect - createShader: LinearConvolve_64
>> PPSRenderer: scenario.effect - createShader: Blend_ADD
>> PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_16
>> PPSRenderer: scenario.effect - createShader: LinearConvolve_12/*
>> On 31 October 2015 at 07:21, Jim Graham <james.graham at oracle.com
>> <mailto:james.graham at oracle.com>> wrote:
>> 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)
>> -Dprism.maxvram=2G (increases maximum texture pool to 2GB)
>> -Dprism.targetvram=2G (combined with maxvram, increases
>> initial pool to 2GB)
>> On 10/30/15 12:59 PM, Felix Bembrick wrote:
>> 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" monitor with a
>> resolution of 1920 X 1024 (?) and I have 2 4K monitors.
>> Hi-DPI is supported in the sense that everything renders at the
>> correct size etc (unlike Swing) but it performs so slowly that
>> there must be something fundamentally wrong, especially since
>> JavaFX seems to be the only technology that's affected.
>> On 31 Oct 2015, at 06:49, Jim Graham
>> <james.graham at oracle.com <mailto:james.graham at oracle.com>>
>> 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...
>> On 10/27/15 11:24 PM, Felix Bembrick wrote:
>> 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
More information about the openjfx-dev