Update Netbeans test dependancies for Javafx

Kevin, A small change so that a couple of modules can resolve dependent test shims. https://bugs.openjdk.java.net/browse/JDK-8146018 http://cr.openjdk.java.net/~ddhill/8146018 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his

Re: CFV: New OpenJFX Committer: Johan Vos

Vote: YES --morris On 12/21/15 2:45 PM, David Hill wrote: I hereby nominate Johan Vos to OpenJFX Committer. Johan Vos (jvos) has been active in the OpenJFX community, and instrumental in the maturity of Monocle, the owner of the Android and IOS ports and is an OpenJFX Author. A list of

Re: CFV: New OpenJFX Committer: Johan Vos

Vote: yes On 21.12.2015 22:45, David Hill wrote: I hereby nominate Johan Vos to OpenJFX Committer. Johan Vos (jvos) has been active in the OpenJFX community, and instrumental in the maturity of Monocle, the owner of the Android and IOS ports and is an OpenJFX Author. A list of Johan's

Re: CFV: New OpenJFX Committer: Johan Vos

Vote: yes Best regards, Alexander Kouznetsov (408) 276-0387 On 21 дек 2015 11:45, David Hill wrote: I hereby nominate Johan Vos to OpenJFX Committer. Johan Vos (jvos) has been active in the OpenJFX community, and instrumental in the maturity of Monocle, the owner of the Android and IOS

Re: CFV: New OpenJFX Committer: Johan Vos

Vote: yes Sent from my iPhone > On Dec 22, 2015, at 5:03 PM, Alexander Kouznetsov > wrote: > > Vote: yes > > Best regards, > Alexander Kouznetsov > (408) 276-0387 > >> On 21 дек 2015 11:45, David Hill wrote: >> >> I hereby nominate Johan Vos to OpenJFX

Re: CFV: New OpenJFX Committer: Johan Vos

Vote: yes ...jim On 12/21/15 11:45 AM, David Hill wrote: I hereby nominate Johan Vos to OpenJFX Committer. Johan Vos (jvos) has been active in the OpenJFX community, and instrumental in the maturity of Monocle, the owner of the Android and IOS ports and is an OpenJFX Author.

Re: Huge JavaFX performance drop in Debian Jessie

Hi Kevin, The JavaFX performance when forcing the sw pipeline is still much slower with Jessie than Wheezy so I'm hoping there is something I can do at the OS level to get back to previous sw performance. Will let you know if I find it! Cheers, Chris Sent from my iPhone > On 22 Dec 2015,

Re: Huge JavaFX performance drop in Debian Jessie

Hi @all, i had just a quick look at the stack trace may be you can make your app perform better with setting javafx.animation.pulse. i have never used this by my own. (but may be you can slow down the pulse of repainting) there are much more options for debug and testing [1,2] On Linux maybe

RE: Huge JavaFX performance drop in Debian Jessie

Just to understand "not supported GPU" better: Is there GPU-specific code in JavaFX? I thought JFX is using vendor-neutral APIs to access the GPU? -Markus -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Chien Yang Sent: Dienstag, 22.

RE: Huge JavaFX performance drop in Debian Jessie

Chris, can you please check what the JFX thread does whilst the scroll-freeze (e. g. using jstack or jvisualvm)? It would be great to learn whether it is related to JDK-8145565. -Markus -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Chris

RE: Constant resetting to initial-state when adding/remove styleclasses

+1 -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl Sent: Dienstag, 22. Dezember 2015 07:16 To: openjfx-dev@openjdk.java.net Subject: Constant resetting to initial-state when adding/remove styleclasses Hi, While debugging some

RE: Constant resetting to initial-state when adding/remove styleclasses

+1 I also vote for performance related optimizations From: Gerrit Grunwald Sent: 22.12.15, 07:55 To: Tom Schindl Cc: OpenJFX Subject: Re: Constant resetting to initial-state when adding/remove styleclasses Hi, I just can confirm what Tom wrote, figured that out some time ago when playing

Re: Constant resetting to initial-state when adding/remove styleclasses

If anyone is counting these votes for better performance I'll add 1+ too :-) Am 22.12.15 um 07:15 schrieb Tom Schindl: Hi, While debugging some code I attached a listener to a property and noticed that whenever a style-class is added to the control or even worse somewhere in the parent

Re: Huge JavaFX performance drop in Debian Jessie

Hi Chien, Thanks, using -Dprism.order=sw prevents the multi-second hangs but JavaFX desktop performance is still noticably worse than in Wheezy (probably because the CPU is now doing all the work and this little Atom is maxed out). Something has definitely changed under the hood in Jessie but

RE: Huge JavaFX performance drop in Debian Jessie

Thanks for the stacktrace. This is definitively a separate issue. Yours actually waits for the renderer to complete the previous frame. Mine is heavily working inside ToolbarSkin. Technically unrelated, but leading to the same outcome: frozen UI. What seems odd is that the object reference the

Re: Huge JavaFX performance drop in Debian Jessie

Hi Chris, JavaFX may run on Intel GMA 3150, but it is not a supported GPU. There is a high likelihood that the drop in performance is caused by the switch from sw pipe (Debian Wheezy) to es2 pipe (Debian Jessie). GMA 3150 is an underpowered GPU for JavaFX's es2 pipe. You can try forcing

Re: Huge JavaFX performance drop in Debian Jessie

We require Pixel Shader 3 support and this GPU doesn't really have full HW support. Most drivers will attempt to emulate with somewhat mixed results. If this card were in a system running Windows we would automatically detect and fall back to SW. This isn't as easy to do in Linux, but maybe it

Re: Huge JavaFX performance drop in Debian Jessie

This is the normal stack trace I would expect when waiting for rendering to complete and the rendering is taking a long time. So in short: I see nothing strange or remarkable about the stack trace. -- Kevin Markus KARG wrote: Thanks for the stacktrace. This is definitively a separate issue.

RE: Huge JavaFX performance drop in Debian Jessie

What I meant with "odd" is the fact that a thread is waiting for a lock instance which is not told by the stack trace as locked by another thread, and that there is a thread which is waiting for a lock obtained by itself. I haven't seen this patterns before, but I also must confess that I am not

Re: Constant resetting to initial-state when adding/remove styleclasses

Adding/removing style-classes is simply bad practice. And not just in JavaFX. It is better to use pseudo-class state. When the style-class changes, the set of styles that match a node can, and is very likely to, change. The css implementation 're-applies' css to the node and its children by

review: Cannot run gradle test tasks using a Jigsaw (jake) build

Kevin, Please review this JDK9/Jake specific change: Cannot run gradle test tasks using a Jigsaw (jake) build Note, that this change only enabled JDK9 based testing for base, graphics, controls. Coming soon: fxml and web which have been refactored and will be enabled later. SystemTest