Re: In(Sanity) Testing Mondays

[Kevin Rushforth]

Please note that the US went off of daylight saving time yesterday 
morning, so the repo will be unlocked at 1pm PST which is an hour later 
for those outside the US.


-- Kevin


Vadim Pakhnushev wrote:

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PDT until 
1pm PDT.


Happy testing!

Thanks,
Vadim

Debug Flags Wiki Page

[David Hill]

Hi all,
   After Jim reminded me (again) with his recent email - I started a OpenJFX 
wiki page to note/document the various command line flags we have that are 
pretty much only documented in email.

Please take a look at the rather spare page:

https://wiki.openjdk.java.net/display/OpenJFX/Debug+Flags

and either add missing ones in, or send me an email and I will add them. 
Corrections are also welcome, I typed this rather quickly.

There are a handful of other ones I know about (mostly font or monocle related) 
that are covered in other wiki pages, but should be linked back at some point.

Dave

--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

Re: Debug Flags Wiki Page

[David Hill]

On 11/2/15, 4:27 PM, Jim Graham wrote:

Should we have a column for the default setting?

Also, targetvram shouldn't be set higher unless you also set maxvram higher - 
we'll need a place to mention dependent properties.

Should all of that just be mentioned in text in the description field?

Default settings column . humm, probably a good idea, though there is 
precedence for just stuffing it in the description like we do in Javadoc.

As much as I have wanted to do this for a while, I guess I have not thought too 
much about the format
I was more along the lines of "build it, and they will come" (and suggest how 
to do it better). :-)

The challenge of this as I found earlier is that the description is going to be 
95% of the table.

Another way to do this would be to dump the table and do paragraphs with the 
flag as the paragraph heading. That *might* flow better.

Any thoughts on that ?

Dave



...jim

On 11/2/2015 11:01 AM, David Hill wrote:


Hi all,
After Jim reminded me (again) with his recent email - I started a
OpenJFX wiki page to note/document the various command line flags we
have that are pretty much only documented in email.

Please take a look at the rather spare page:

https://wiki.openjdk.java.net/display/OpenJFX/Debug+Flags

and either add missing ones in, or send me an email and I will add them.
Corrections are also welcome, I typed this rather quickly.

There are a handful of other ones I know about (mostly font or monocle
related) that are covered in other wiki pages, but should be linked back
at some point.

Dave




--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

Re: Windows Hi-DPI

[Jim Graham]

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 
completely backwards).


Are you running on the 32-bit VM?  Have you tried the 64-bit VM?

...jim

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

 ...jim

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 ...
 succeeded.
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
 \\.\DISPLAY1
 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 > 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)

 ...jim


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

9-dev unlocked following sanity testing

[Kevin Rushforth]

Re: Windows Hi-DPI

[Jim Graham]

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


...jim

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 ...
 succeeded.
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
 \\.\DISPLAY1
 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 > 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)

 ...jim


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

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
which is extremely powerful but has two 4K monitors and
while everything looks great and the right "size", the
performance is 

Re: Debug Flags Wiki Page

[Jim Graham]

How about a table where there is a line of formatted info and then an 
open box below it with a description.  Kind of like (hate ascii art):


+-+--+---+---+
| foo.bar | 4096 | no dependencies   | Sets the bar of the foo   |
+-+--+---+---+
| This sets the bar for the foo which affects all cases where|
| we foo the bar and the bar doesn't have its own foo.   |
++

Some options won't require a description or will be batched together 
with a single description box perhaps...


...jim

On 11/2/2015 1:40 PM, David Hill wrote:

On 11/2/15, 4:27 PM, Jim Graham wrote:

Should we have a column for the default setting?

Also, targetvram shouldn't be set higher unless you also set maxvram
higher - we'll need a place to mention dependent properties.

Should all of that just be mentioned in text in the description field?

Default settings column . humm, probably a good idea, though there
is precedence for just stuffing it in the description like we do in
Javadoc.

As much as I have wanted to do this for a while, I guess I have not
thought too much about the format
I was more along the lines of "build it, and they will come" (and
suggest how to do it better). :-)

The challenge of this as I found earlier is that the description is
going to be 95% of the table.

Another way to do this would be to dump the table and do paragraphs with
the flag as the paragraph heading. That *might* flow better.

Any thoughts on that ?

Dave



...jim

On 11/2/2015 11:01 AM, David Hill wrote:


Hi all,
After Jim reminded me (again) with his recent email - I started a
OpenJFX wiki page to note/document the various command line flags we
have that are pretty much only documented in email.

Please take a look at the rather spare page:

https://wiki.openjdk.java.net/display/OpenJFX/Debug+Flags

and either add missing ones in, or send me an email and I will add them.
Corrections are also welcome, I typed this rather quickly.

There are a handful of other ones I know about (mostly font or monocle
related) that are covered in other wiki pages, but should be linked back
at some point.

Dave

Re: Debug Flags Wiki Page

[Jim Graham]

Should we have a column for the default setting?

Also, targetvram shouldn't be set higher unless you also set maxvram 
higher - we'll need a place to mention dependent properties.


Should all of that just be mentioned in text in the description field?

...jim

On 11/2/2015 11:01 AM, David Hill wrote:


Hi all,
After Jim reminded me (again) with his recent email - I started a
OpenJFX wiki page to note/document the various command line flags we
have that are pretty much only documented in email.

Please take a look at the rather spare page:

https://wiki.openjdk.java.net/display/OpenJFX/Debug+Flags

and either add missing ones in, or send me an email and I will add them.
Corrections are also welcome, I typed this rather quickly.

There are a handful of other ones I know about (mostly font or monocle
related) that are covered in other wiki pages, but should be linked back
at some point.

Dave

Re: pisces, produceFillAlphas

[Felix Bembrick]

Johan? I really need this kind of information and you seem to be the most 
qualified person to provide it.

Cheers,

Felix

> On 31 Oct 2015, at 19:23, Felix Bembrick  wrote:
> 
> Hi Johan,
> 
> Now that your workload has hopefully lessened a bit after J1, do you think 
> you could find some time to address this question of mine from earlier?
> 
> Thanks,
> 
> Felix
> 
>> On 18 Oct 2015, at 19:01, Felix Bembrick  wrote:
>> 
>> Hi Johan,
>> 
>> If you have been getting acceptable but not stunning performance on Android 
>> and all this time hardware acceleration was not being utilised then it 
>> sounds like there is some serious room for some dramatic performance 
>> increases.
>> 
>> Not being that familiar with the finer points of how JavaFX is implemented 
>> on Android, just how much work is involved in accessing that hardware 
>> acceleration?  Any timeline?
>> 
>> I expect that implementing this significant change could be a make-or-break 
>> factor in determining whether JavaFX is truly viable and successful on 
>> Android.
>> 
>> Good luck Johan!
>> 
>> Cheers,
>> 
>> Felix 
>> 
>>> On 17 Oct 2015, at 19:49, Johan Vos  wrote:
>>> 
>>> As a follow-up on the second part: after about 2 years working on JavaFX on
>>> Android, I discovered we are not even using Hardware Acceleration. We
>>> create a SurfaceView and render on that, but it turns out SurfaceView is
>>> never Hardware Accelerated. The positive thing is that this means there is
>>> even more room for optimization :)
>>> 
>>> - Johan
>>> 
 On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos  wrote:
 
 Hi,
 
 Thanks for the suggestions. There are 2 different things:
 
 1. It seems indeed there is not much being cached, so there are definitely
 improvements possible. It also require e.g. VirtualFlow to use the
 Node.setCache(true) in order to cache. The combination of this with the
 prism.scrollcacheopt reduces the rendering calls. I think the only penalty
 is memory, but so far, we didn't run into issues with too high GC activity.
 
 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times
 longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns).
 I'll have to look into some EGL options.
 
 - Johan
 
 
 On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham 
 wrote:
 
> Chien pointed out a system property that is currently disabling the
> scrolling optimization.  For its implementation look at CacheFilter.java,
> in particular the invalidateByTranslation() method and all that it kicks
> off.
> 
> Another thing to look at is that we added alpha batching to the code
> which should be batching all of the output of the produceAlphas calls into
> a texture and then drawing all of the quads together - provided that they
> are all being filled with simple colors (they can have alpha, but they
> can't be gradients, etc.).  This should be managed by the
> BaseContext.updateMaskTexture() method which controls the single batch
> texture.
> 
> Again, are there similar number of invocations of the glDrawElements on
> the 2 platforms?
> 
>  ...jim
> 
>> On 10/15/15 12:30 PM, Johan Vos wrote:
>> 
>> Thanks Jim.
>> I tried with different optimization flags, but it doesn't make a big
>> difference. Tracing it down to system calls, somehow the gl
>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads
>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS)
>> per invocation. The number of invocations is comparable between iOS and
>> Android.
>> 
>> If you can give me a direction on where to search for the disabled
>> scrolling optimization, I'll try to re-enable that and see how it
>> improves performance. It might be a huge and quick win...
>> 
>> Thanks again,
>> 
>> - Johan
>> 
>> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham > > wrote:
>> 
>>  Perhaps optimization flags with the native compiler?  Also, was it
>>  called a similar number of times on both?
>> 
>>  Ideally we'd just be using copyArea for the scrolling, but at one
>>  point we disabled the scrolling optimizations on retina MBP because
>>  they didn't work with a scale factor and I don't think we reenabled
>>  them yet.  That would kill scrolling performance on mobile as a
>>  result of having to rerender the scene on each scroll regardless of
>>  how long produceAlphas takes...
>> 
>>   ...jim
>> 
>> 
>>  On 10/15/15 4:27 AM, Johan Vos wrote:
>> 
>>  After spending lots of time optimizing JavaFX on iOS, I am now