Thanks but it does not seem to improve the situation.
btw, I am using 1.8.0_05-b13 on Mac OS 10.9.3 on a retina MBP.
On Sun, Jun 1, 2014 at 9:59 PM, Jeff Martin j...@reportmill.com wrote:
I haven't seen this, but here's a hack you can try:
// Show stage transparent once to get proper
To rule out CSS is the reason you could directly set the background:
pane.setBackground(new Background(new BackgroundFill(Color.rgb(54, 54,
54), CornerRadii.EMPTY, Insets.EMPTY)));
Does that improve the situation?
Tom
On 02.06.14 09:51, Robert Krüger wrote:
Thanks but it does not seem to
No, it does not. So it is not the CSS.
On Mon, Jun 2, 2014 at 10:04 AM, Tom Schindl
tom.schi...@bestsolution.at wrote:
To rule out CSS is the reason you could directly set the background:
pane.setBackground(new Background(new BackgroundFill(Color.rgb(54, 54,
54), CornerRadii.EMPTY,
Hi Robert,
Which of the
two mailing lists is the more appropriate one to post these things
(JFX problems which look like they might be platform-specific) to?
FYI: the JDK Mac OS X Port Project has been completed long time ago, so
currently the macosx-port-dev@ mailing list isn't appropriate
Platform.setImplicitExit(false)
This is the correct answer. Please see the javadoc for more details.
--
best regards,
Anthony
On 5/31/2014 10:19 PM, Jeff Martin wrote:
You might try calling that new JFXPanel() in your application main. Maybe go
ahead and call
Hi,
I have encountered severe lag in my application when resizing the stage
while an animation is running.
I've made this very simple example code to reproduce the issue:
https://github.com/Drakkoon/LWJGL-FX/blob/master/src/JavaFXResizeTest.java
This is only a tread that acquires a semaphore,
My guess would be that the number of resize events is swamping the event queue.
On Jun 2, 2014, at 7:20 AM, Guillaume Anctil drakk...@gmail.com wrote:
Hi,
I have encountered severe lag in my application when resizing the stage
while an animation is running.
I've made this very simple
It might be something like that. But it seems to be in the platform, not
application related.
When detecting a resize, I tried putting the thread to sleep for a long
amount of time. Something like 5 seconds before adding a new Runnable in
the Platform.runLater queue. It's still very slow when it
You may be hitting this bug: https://javafx-jira.kenai.com/browse/RT-36796
Please try running with -Dprism.order=sw and see if this changes anything.
--
best regards,
Anthony
On 6/2/2014 6:20 PM, Guillaume Anctil wrote:
Hi,
I have encountered severe lag in my application when resizing the
Yes. -Dprism.order=sw does fix the issue. Looking at that bug's sample code
and how to reproduce, it looks very similar.
Thank you. I'll run it in software mode for now and see how bad it affects
performance. I can always apply a hacky workaround of stopping animations
when I detect a resize and
I suggest you add yourself to the bug. At this time, we are not sure
what is causing it. It could be graphics or event queue related as
there is evidence that changing either solves the problem.
Steve
On 2014-06-02, 10:51 AM, Guillaume Anctil wrote:
Yes. -Dprism.order=sw does fix the
We also experienced laggy animation with a stage slide out/down
animation. The animation would change stage size and it appeared to have
only 2 or 3 frames. Workaround was to use a different animation style:
keep stage size but move it 20 px down while changing opacity from low
to full, both
Does running with the software pipeline fix the problem as suggested in
https://javafx-jira.kenai.com/browse/RT-36796 ?
Steve
On 2014-06-02, 11:10 AM, Werner Lehmann wrote:
We also experienced laggy animation with a stage slide out/down
animation. The animation would change stage size and it
Hi Anthony
On Mon, Jun 2, 2014 at 3:01 PM, Anthony Petrov
anthony.pet...@oracle.com wrote:
Hi Robert,
Which of the
two mailing lists is the more appropriate one to post these things
(JFX problems which look like they might be platform-specific) to?
FYI: the JDK Mac OS X Port Project has
Probably not (that code is gone so I don't know for sure). For some
other (Mac-related) reason, the software pipeline was already used for
our internal testing. Didn't seem to make a difference.
FWIW, there was also an NPE occurring if someone was crazy enough to
show that popup many times by
Hi Steve, Petr,
Please review the fix: https://javafx-jira.kenai.com/browse/RT-37304
--
best regards,
Anthony
We are done with JavaFX 8u20 (in)sanity testing for this week. The repo
is open for commits again.
-- Kevin
Except the license.txt page points to the OSI page that is... BSD 2 Clause.
Here's the zoom pane as BSD 2 clause...
https://github.com/shemnon/FollowTheBitcoin/commit/effd601965875fec8891f8202afea1f84f1daf54
If you really want me to add the non-endorsement clause I can, but it is
kind of
Changeset: f3841fb9697d
Author:lisa.se...@oracle.com
Date: 2014-06-02 16:39 -0400
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f3841fb9697d
RT-36844 [Monocle] Implement modality support for monocle
Reviewed by dblaukopf
Tested with HelloSanity
!
Changeset: b245bc977cc5
Author:ddhill
Date: 2014-06-02 17:04 -0400
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b245bc977cc5
[BUILD] adding include file to fix errors in monocle
Reviewed-by: kselle
! buildSrc/crosslibs/crosslibs-armv6hf.sh
!
Changeset: edb590702b98
Author:snorthov
Date: 2014-06-02 17:25 -0400
URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/edb590702b98
[ACCESSIBILITY ONLY] Remove unnecessary ROLE code
!
modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PaginationSkin.java
21 matches
Mail list logo
