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
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
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
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
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
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.
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,
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
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.
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
+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
+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
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
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
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
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
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
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.
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
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
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
21 matches
Mail list logo