Btw, there is a JIRA issue filed against BrickBreaker specifically:
https://javafx-jira.kenai.com/browse/RT-29801
Richard Bair wrote:
Have you tried to determine what the FPS is? My guess is that FPS is not
anywhere near the limit and it is the occasional stutter that is the problem,
but I'm
Is this from FX 2.2.x or FX 8? The stack trace suggests an earlier
version of FX. The only thing I can think of off hand is that the HW
texture couldn't be created, probably because you ran out of resources.
There are a few issues relating to this, which we believe are fixed in
FX 8 with the
I missed the fact that this is using the non-public
impl_fromExternalImage() method. This was replaced in FX 2.2 by
SwingFXUtils.toFXImage as Werner mentions and has been removed from FX 8
entirely.
One more thing to check is that jfxImage is non-null, although it is
still more likely than
You cannot run gradle in the rt repo just yet.
For now (i.e., until the switch to gradle with the accompanying repo
reorg), you must run the generator.gradle script which reorganizes the
repo to its new layout, and puts it, by default, in ../javafx
Among other things it copies gradleBuildSrc
I can confirm that yes, the native font code is turned on for b96 on
Windows (it was turned on for Mac in b94).
-- Kevin
John C. Turnbull wrote:
So Phil, is that now in b96?
On 29/06/2013, at 14:30, Phil Race philip.r...@oracle.com wrote:
For most Windows users and use cases the main
I don't really like the single enum approach. I would prefer to keep the
existing MSAA boolean, and then, if needed, add a separate attribute for
requesting the number of samples; if desired there could be a read-only
attribute that returns the actual number of samples used. Most chipsets
give
+1
In practice I agree with Richard that this should not cause any issues
for applications.
-- Kevin
David Ray wrote:
+1
David
Sent from my iPhone
On Jul 12, 2013, at 3:15 PM, Richard Bair richard.b...@oracle.com wrote:
I have two different changes I might want to make, both of
options can't be honored?
On Jul 13, 2013, at 12:00 PM, Kevin Rushforth
kevin.rushfo...@oracle.com mailto:kevin.rushfo...@oracle.com
wrote:
I don't really like the single enum approach. I would prefer to
keep the existing MSAA boolean, and then, if needed, add a
separate
I´m trying to build a jar containing all sources for jfxrt.jar, so I can attach
it in Eclipse. For this I´ve added the following lines to the root build.gradle:
...
Is this the correct way to go about it?
This looks like the right approach, yes (although rather than excluding
a list of
No, it will not be part of src.zip for JDK 8, but a parallel
javafx-src.zip file in the same directory as src.zip.
-- Kevin
Tom Schindl wrote:
Do you already have an idea of the nameing location? Or will it be
part of src.zip?
Tom
On 16.07.13 13:35, Kevin Rushforth wrote:
I´m trying
Yes, Jennifer and I both saw this during integration testing. Jennifer
also saw this when running the toys. She will file a bug.
-- Kevin
Richard Bair wrote:
Is anybody else seeing this?
javafx.scene.control.ComboBoxTest test_rt31479 FAILED
java.util.ConcurrentModificationException
This is an issue for Debbie not for Nicolas, since the apps are not
included in the release bundles that are being produced by the build.
RT-31410 https://javafx-jira.kenai.com/browse/RT-31410 was recently
marked as fixed, but seems not to have completely fixed the problem. I
filed a new
Are you sure you tried b99? This issue should be fixed now, and we have
seen no other reports that it is still broken.
-- Kevin
向雅 wrote:
Hi,
3 builds both got this in notebook:
java.lang.UnsatisfiedLinkError: X:\JDK8\jre\bin\glass.dll: Can't find
dependent libraries
but in my pc, b96
+1 on having DISABLED be first.
-- Kevin
Richard Bair wrote:
Just to be picky, I would put DISABLED first in the list. It seems more consistent
to have the only OFF mode to be first and then all the rest of the options (which
happen to then have ordinals 0) will be some form of ON mode.
Yes, jfxrt.jar is platform-specific. On the desktop there are
platform-specific glass and Prism classes (not sure about the WebKit
classes). On embedded platforms (Linux-arm, IOS, Android) there are many
differences.
-- Kevin
Daniel Zwolenski wrote:
Obviously there are native libs (dlls,
What version of JDK 7u/FX 2.2.x is this reproduced in? Have you tried
this with a recent build of JDK 7u40? There is a vanishingly small
window to get changes into 7u40 / FX 2.2.40 which is scheduled for
release in the first half of September. The next opportunity would be
January.
-- Kevin
Vote: yes
David Hill wrote:
I hereby nominate Seeon Birger to OpenJFX Committer.
Seeon is a member of the Embedded Device team, which means he works
across various aspects of the platform, but in particular, Lens and
Virtual Keyboard.
His recent work can be seen here:
Vote: yes
David Hill wrote:
I hereby nominate Daniel Blaukopf to OpenJFX Committer.
Daniel is a member of the Embedded Device team, which means he works
across various aspects of the platform. He is also the architect for
the embedded device space.
His recent work can be seen here:
Vote: Yes
Artem Ananiev wrote:
I hereby nominate Chien Yang to OpenJFX Committer.
Chien is a member of JavaFX graphics group at Oracle. Here is the list
of his fixes and reviews:
http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=chien
Votes are due by Aug 29, 2013.
Only current
Vote: Yes
Artem Ananiev wrote:
I hereby nominate Alexander Zvegintsev (OpenJDK user name: alexz) to
OpenJFX Committer.
Alexander is a primary maintainer of Gtk port of Glass (windowing
toolkit for JavaFX), and also an active contributor to other Glass
platforms. Here is the list of
Vote: Yes
Artem Ananiev wrote:
I hereby nominate Felipe Heidrich (OpenJDK user name: felipe) to
OpenJFX Committer.
Felipe is a member of JavaFX graphics group at Oracle. He is mostly
responsible for JavaFX text and fonts, but not only for that. Here is
the list of changesets he has
Vote: Yes
Artem Ananiev wrote:
I hereby nominate Mick Fleming (OpenJDK user name: mickf) to OpenJFX
Commmitter.
Mick is a member of JavaFX Controls team at Oracle. He fixed many bugs
and implemented tons of features in virtually every JavaFX Control,
from buttons to tables. Here is a
Correct. There might be a respin in case of a release stopper, but it's
otherwise done.
-- Kevin
Scott Palmer wrote:
I see the latest jdk7 EA build is now labelled FCS.. I guess that means
it's a done deal and is just soaking a bit before being put up on oracle.com?
Scott
https://javafx-jira.kenai.com/browse/RT-32004
I pushed a fix earlier today. It will be in b107.
-- Kevin
John C. Turnbull wrote:
Sorry to harp on about this but the media classes are missing from b106
JavaDoc as well in case Oracle is not aware of this.
From: John C. Turnbull
Did the system go into screen lock during that time? If so, then this is:
https://javafx-jira.kenai.com/browse/RT-32636
Otherwise it sounds like a new bug.
-- Kevin
John C. Turnbull wrote:
I am not sure if it is a known issue but any JavaFX application I run and
then leave minimised for
What build are you using? There were several dirty region optimization
(dirtyopts) bugs in b104 that have since been fixed. To see whether this
is the case, you can try:
java -Dprism.dirtyopts=false ...
-- Kevin
John C. Turnbull wrote:
Hmm, I am not sure that is the same issue. That
(I guess I should read the whole thread before replying...please ignore
my already-answered questions in earlier messages)
Can you file a JIRA for this issue? Also, can you comment as to whether
disabling prism.dirtyopts helps?
Thanks.
-- Kevin
John C. Turnbull wrote:
I notice this issue
Yes, it should be working for both D3D (as of b105) and OpenGL (earlier
than that).
-- Kevin
John C. Turnbull wrote:
Could someone please let me know if support for 3D scene antialiasing is
supposed to be working in JDK8 b106?
If not, when is this feature expected to be implemented?
Btw, making ImageView and MediaView resizable is filed as
https://javafx-jira.kenai.com/browse/RT-10610
-- Kevin
John Hendrikx wrote:
+1 on the ImageView case... getting ImageViews to resize properly,
like a Button or other node would, is tricky and often gives
unexpected results or doesn't
Yes.
User-defined normals: RT-29012
https://javafx-jira.kenai.com/browse/RT-29012
More than 3 lights: RT-26462 https://javafx-jira.kenai.com/browse/RT-26462
-- Kevin
Richard Bair wrote:
Do we have feature requests filed for overcoming these limitations?
On Sep 26, 2013, at 2:18 PM, Joseph
Yes, this is a known issue: https://javafx-jira.kenai.com/browse/RT-33015
-- Kevin
Richard Bair wrote:
Is anybody else seeing these? Have we seen them on hudson?
javafx.scene.control.ListViewKeyInputTest test_rt21375_scenario_2_down FAILED
java.lang.AssertionError: expected:3 but was:5
FX does not use JBS -- we have a separate JIRA instance. Your question
is probably best asked on an OpenJDK alias.
-- Kevin
Pete Brunet wrote:
For those without JBS accounts what is the right web site to use to
report bugs?
All,
There is a bug in JDK 8, introduced in b108, that will cause a clean
build of FX to fail.
https://bugs.openjdk.java.net/browse/JDK-8025173
It is expected that this will be fixed in b110.
Until then, you can either stick with an older JDK, or use the following
workaround, to compile
There is a known bug introduced in JDK 8 b108. See:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-October/010592.html
It is fixed in b110.
-- Kevin
Oscar Vargas Torres wrote:
This is the error I keep getting:
http://pastie.org/8377161
http://pastie.org/8377161
I am using Ubuntu
Yes, that pretty much captures the thinking behind it.
My thought is that there is no real reason that subdivisions need to be
immutable, although I wouldn't want to change it at this late date for
FX 8 unless it is needed for FXML support.
The fixedEyeAtCameraZero mode is not something I
mutable state in FX, the range of possible values should
not be hindered by the evil unbind pattern).
Richard
On Oct 4, 2013, at 12:46 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote:
Yes, that pretty much captures the thinking behind it.
My thought is that there is no real reason
*not* expose a ReadOnly property for these properties
(and I don't think we do)
- The FXML changes must be backwards compatible (they should be but
we need to verify)
- The SceneBuilder can do something reasonable as is (not sure).
Richard
On Oct 4, 2013, at 1:08 PM, Kevin Rushforth
5. Should we enable more -Xlint warnings in OpenJFX build?
6. Any chances anything of this can still go in 8 (e.g. get rid of warnings
We have 2 weeks where we can still accept P4-P5 bugs into FX 8, and
getting rid of warnings would be a P4 bug. I guess it depends on how
intrusive the
?
Should I split test and library code changes?
-Sven
P.S. Shall I try to get this done as well for other modules? Which
would be preferred? (Just in case I have some more time to spend)
On Mon, Oct 7, 2013 at 1:26 PM, Kevin Rushforth
kevin.rushfo...@oracle.com mailto:kevin.rushfo...@oracle.com
I know that David DeHaven looked into this. Maybe he will have something
to add?
For production, we need to use gcc (not clang) and the 10.7 SDK, but
having a solution that makes it easy for developers to build with latest
would be a good thing.
-- Kevin
Sven Reimers wrote:
Hi,
since I
In the top-level JDK directory, next to src.zip, there will be a
javafx-src.zip.
-- Kevin
Tom Schindl wrote:
So where the src.zip end up, so that k can adjust the tooling?
Tom
Von meinem iPhone gesendet
Am 08.10.2013 um 18:32 schrieb hang...@oracle.com:
Changeset: 61727bf6e832
In order to let community members know what is going on with the bugs,
etc., targeted to Lombard (FX 8), here is the current status.
We are continuing to ramp-down the FX 8 release in conjunction with the
ramp-down of JDK 8. Here are the key dates to be aware of for FX fixes
that are going
Note: I have synced up the pending FX changes from the just-release
October 2013 CPU release into FX 8. I also pulled them into the
graphics/rt repo.
-- Kevin
Regarding #2, I'm OK with an exception being thrown.
Regarding #1, do you think moving the clip planes to PerspectiveCamera
(rather than in the base class) be better for FX 8? We can compatibly
move it up to a superclass in a future release. Or would this be too
disruptive?
-- Kevin
Not to mention Tom's point that it can't be in the fxml module without
created unwanted (and circular) module dependencies. Seems like it needs
to be in the base module then, right?
-- Kevin
Richard Bair wrote:
+1 this is my preference. It is useful for things other than FXML, and should
Would IllegalStateException be better here? Usually UOE is for
operations that are simply not supported by the class in question. In
this case, the operation is only unsupported if the camera on the scene
(i.e., the state of an object) is of a certain type which can change at
runtime.
I'm OK
Steve: if Pavel throws IllegalStateException(not yet supported for
parallel camera) or similar, do you think that would be OK or do you
not want to see any exception?
-- Kevin
Kevin Rushforth wrote:
Would IllegalStateException be better here? Usually UOE is for
operations that are simply
, not when we can't decide how an API works. If the exception
goes in, it's API and it stays forever.
Steve
On 2013-10-16 5:23 PM, Kevin Rushforth wrote:
Steve: if Pavel throws IllegalStateException(not yet supported for
parallel camera) or similar, do you think that would be OK or do you
throwing an
exception from a compatibility perspective. Bugs are bugs.
On Oct 16, 2013, at 3:46 PM, Kevin Rushforth kevin.rushfo...@oracle.com wrote:
I can see your point. There are cases where it can make sense to have a
restriction now and relax it later, but this isn't exactly that case. It's
All of the JavaFX runtime is open source except for the third-party code
that we cannot ship (e.g., the On2 codec that Kirill mentioned, and the
T2K font library, for which we have an open replacement), and the FX
deploy code, which depends on the JRE deploy code. Additionally, the JMX
code,
Regarding JMX:
Kevin, if it is easy to open it, lets just do it and use it as a starting point.
Should be pretty easy. I'll file a JIRA.
-- Kevin
Richard Bair wrote:
That's pretty much it. VP6, T2K, deploy, FX JMX tooling.
VP6 won't ever be opened because it is licensed 3rd
https://javafx-jira.kenai.com/browse/RT-33682
Kevin Rushforth wrote:
Regarding JMX:
Kevin, if it is easy to open it, lets just do it and use it as a starting point.
Should be pretty easy. I'll file a JIRA.
-- Kevin
Richard Bair wrote:
That's pretty much it. VP6, T2K, deploy, FX JMX
During integration testing, we just pushed a change that makes JDK
8-b112 the minimum JDK needed. It really isn't need to build openjfx
(there were some deploy UI interface changes that motivated this), you
can just manually set this back to b111 and continue building.
I expected that b112
-jfx.build.jdk.buildnum.min=112
+jfx.build.jdk.buildnum.min=111
-- Kevin
Kevin Rushforth wrote:
During integration testing, we just pushed a change that makes JDK
8-b112 the minimum JDK needed. It really isn't need to build openjfx
(there were some deploy UI interface changes that motivated
Vote: YES
Btw, the correct repo is:
http://hg.openjdk.java.net/openjfx/8/master/tests
-- Kevin
Artem Ananiev wrote:
I hereby nominate Oleg Barbashov (OpenJDK user name: ogb) to OpenJFX
Committer.
Oleg is a member of JavaFX SQE team at Oracle. He is currently an
Author in OpenJFX and is
Vote: YES
David Hill wrote:
I hereby nominate Assaf Yavnai to OpenJFX Committer.
Assaf is a member of JavaFX Embedded team at Oracle. Most of Assaf's
changes are in Glass/Lens support code:
hg log -u Assaf Yavani
An incomplete list of Assaf's commits and reviews is also available by
As a heads-up, I need to bump the minimum JDK 8 version number required
for building FX to b113 (is currently b112) to fix a problem building
one of our closed files that uses a java.net class in the JDK which has
changed.
FX JIRA: https://javafx-jira.kenai.com/browse/RT-34085
JDK issue
I see this from time to time. This is a bug in the version of ant that
is used by gradle for dependencies. It has been reported that gradle 1.8
may have a newer version of ant that fixes this bug.
In the mean time, a less intrusive workaround is:
gradle -PUSE_DEPEND=false ...
If enough
---BeginMessage---
Hi Phil, Kevin,
Please review RT-34111.
Bug Description and Webrev : https://javafx-jira.kenai.com/browse/RT-34111
Bug summary: Printout shows a scaled down version of the screen output.
Thank you.
Jennifer
---End Message---
Changeset: b80799b32c69
Author:kcr
Date: 2013-11-06 16:41 -0800
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rev/b80799b32c69
RT-32156: Cleanup top-level openjfx repo for FX 8
- .hgignore
! README
- build-defs.xml
- build-src/build-cache.xml
-
Yes, several of us have kicked the tires of Crucible for internal
reviews. Many of us, including me, like it quite a bit. I am hopeful
that OpenJDK will move to a modern tool than webrev + JIRA comments, and
Crucible seems a good choice given that we already use JIRA.
-- Kevin
Richard Bair
A NoSuchMethodError is almost always the result of running classes that
were compiled against one version of the class files with a class
library that has make incompatible changes.
In particular, there was an incompatible change in b114 that makes SB
compiled with b113 not run.
-- Kevin
Never mind. I see that you already resolved this by downgrading ant.
-- Kevin
Kevin Rushforth wrote:
Since this is in the closed part of the build, few people on the
list would have seen it.
update-cached-sdk:
[java] Buildfile:
/export/anthony/ws/g-7-gradleJdkVersion-RT-34174
Please add that to the JIRA, then. For FX, all discussion should happen
there. See https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
-- Kevin
David DeHaven wrote:
Looks fine to me.
-DrD-
Thanks Mark. Can you please add this information to the JIRA (including the
link to the
I haven't thought through all of the implications, but my initial take
is the same as Jim's. Namely, that using the fill bounds for
proportional paints is the most consistent and will have the least
degree of unpleasant surprises.
-- Kevin
Jim Graham wrote:
Felipe mentioned recently that we
Hi Philipp,
There is a JIRA filed to track the open sourcing or SceneBuilder:
https://javafx-jira.kenai.com/browse/RT-34175
Someone from the SceneBuilder team can comment on the status of this.
-- Kevin
Philipp Dörfler wrote:
Hello list,
I can’t but acknowledge the work put into
I see Joe already responded with status (my e-mail crossed his).
-- Kevin
Kevin Rushforth wrote:
Hi Philipp,
There is a JIRA filed to track the open sourcing or SceneBuilder:
https://javafx-jira.kenai.com/browse/RT-34175
Someone from the SceneBuilder team can comment on the status
Please open a new bug. If you can link it to the original bug that would
be helpful.
Thanks!
-- Kevin
ngalarn...@abinitio.com wrote:
Hello,
How do I report a regression?
It looks to me like RT-32636/RT-30362 has regressed on b114.
On Win7, my JavaFX app ScenicView DP4, both running
as in my email below.
JIRA has turned those into links to those issues.
Is that the kind of link you mean? If not, how do I add the links?
Thanks,
Neil
From:Kevin Rushforth kevin.rushfo...@oracle.com
To:ngalarn...@abinitio.com
Cc:openjfx-dev@openjdk.java.net
Date:11
From:Kevin Rushforth kevin.rushfo...@oracle.com
To:ngalarn...@abinitio.com
Cc:openjfx-dev@openjdk.java.net
Date:11/20/2013 10:59 AM
Subject:Re: How to report RT-30362 regressing on b114?
Sent by:openjfx-dev-boun...@openjdk.java.net
All,
Primarily to fix https://javafx-jira.kenai.com/browse/RT-34171 we are
upgrading our build environment for JavaFX 8 from gradle 1.4 to gradle
1.8. This will be done prior to next week's build for b118. I've been
running gradle 1.8 for almost two weeks with no issues, and I know other
as part of a milestone build or similar.
-- Kevin
Mario Torre wrote:
2013/11/20 Kevin Rushforth kevin.rushfo...@oracle.com
mailto:kevin.rushfo...@oracle.com
All,
Primarily to fix https://javafx-jira.kenai.com/browse/RT-34171 we
are upgrading our build environment for JavaFX 8 from
a lot of bugs out of 8. Any new features will be done in 9,
but probably not until after 8u20 is in very good shape.
-- Kevin
Mario Torre wrote:
2013/11/20 Kevin Rushforth kevin.rushfo...@oracle.com
mailto:kevin.rushfo...@oracle.com
We might do an upgrade during some JDK 8u release (e.g
Mark,
https://javafx-jira.kenai.com/browse/RT-31888
Can you review this, please?
Thanks.
-- Kevin
Chien,
Please review: https://javafx-jira.kenai.com/browse/RT-32379
Thanks.
-- Kevin
Anthony, Felipe, Steve,
Please review: https://javafx-jira.kenai.com/browse/RT-23840
Thanks.
-- Kevin
As a reminder, we are rapidly approaching ZBB (Zero Bug Bounce) for FX
8, which is also the start of RDP2 (Rampdown Phase 2) after which all
fixes (except docs, test, and samples) will need release team approval.
All fixes must be in JDK 8 b119. The deadline to push changes to the FX
8
As a follow-on to this. The deadline for Docs, Samples, and Test fixes
is one week later, on 10-Dec-2013.
-- Kevin
Kevin Rushforth wrote:
As a reminder, we are rapidly approaching ZBB (Zero Bug Bounce) for FX
8, which is also the start of RDP2 (Rampdown Phase 2) after which all
fixes
I know some of you were waiting for this, JDK 8 b117 is now on java.net:
https://jdk8.java.net/download.html
-- Kevin
Jim,
Please review the following:
https://javafx-jira.kenai.com/browse/RT-32983
Thanks.
-- Kevin
Felipe David,
Please review: https://javafx-jira.kenai.com/browse/RT-33796
-- Kevin
We have created new repositories for the 8 update releases as following.
As with 8, the only repo you need to build OpenJFX is the rt repo.
http://hg.openjdk.java.net/openjfx/8u-dev
http://hg.openjdk.java.net/openjfx/8u-dev/rt
http://hg.openjdk.java.net/openjfx/8u-dev/tests
David,
Please review the following:
https://javafx-jira.kenai.com/browse/RT-34389
Tom: can you make sure that the output is what you expect?
Thanks.
-- Kevin
Please review the following javadoc change (post-commit).
https://javafx-jira.kenai.com/browse/RT-19968
-- Kevin
-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth
Sent: Monday, December 09, 2013 3:43 PM
To: Anthony Petrov
Cc: openjfx-dev@openjdk.java.net
Subject: 8 post-commit review request: RT-19968: Document that
Platform.runLater must not be called
Mong,
Please review the following (in the JIRA).
https://javafx-jira.kenai.com/browse/RT-32512
Thanks.
-- Kevin
Please review the following:
https://javafx-jira.kenai.com/browse/RT-21569
-- Kevin
It would be helpful if the release for which a review is requested is in
the subject line now that we have multiple releases in flight. A
suggestion for this (from the Wiki
https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews) is:
8 review request: RT-12345: summary of the bug
Wrong URL. Here is the right one:
http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1332ba0d7f6a
Martin Sladecek wrote:
Thanks,
-Martin
Also, if none is the answer for Unit test, then we should add a
label added to indicate why there is no unit (regression) test. For
example noreg-hard or noreg-build. See the following:
http://openjdk.java.net/guide/changePlanning.html#noreg
In the case of this specific bug noreg-trivial
I saw something similar to this when I had a newer version of Microsoft
.net installed, but I can't remember if it was exactly the same error.
-- Kevin
Francisco Javier Godino wrote:
Hello:
I ran the build process gradle sdk and I'm receiving the following error:
LNK1112 module machine
/ccbe7ffdd867
-- Kevin
Tom Schindl wrote:
So you say the IDEs must learn that when they encounter a method which
has no JavaDoc to search for the property definition and show that one?
Tom
On 17.12.13 23:12, Kevin Rushforth wrote:
Actually, the JDK 8 doclet that handles this automatically
Happy New Year OpenJFX folks!
Since it is now 2014, when you modify any source code file, please
update the last copyright year in the Oracle copyright header to reflect
this. Here are the three cases to consider.
1) A new file created this year
You would use this:
* Copyright (c) 2014,
A couple other thoughts.
1) JavaFX doesn't use software loops for the actual rendering as long as
the card is capable of supporting Prism. We do mix HW and SW in that we
generate masks from a path in SW, but we cache that on the card and
render it using shaders.
2) JavaFX can support Intel
Anthony Steve,
If you are interested, I added a unit test for batching large numbers of
runLater operations (as a follow up to RT-21569
https://javafx-jira.kenai.com/browse/RT-21569), which in FX 8 works on
Windows platforms only because of the InvokeLaterDispatcher.
JIRA:
As a reminder, review comments should be made in JIRA. Can you add it there?
-- Kevin
Scott Palmer wrote:
A couple quick questions: Why is the property Read-Only? Can the setter
only be called once? Does it have to be set before the Stage is shown?
Should it be an initAlwaysOnTop(boolean
Hi Scott,
The Java 8 launcher has been modified to recognize JavaFX applications
-- that is, classes that extend javafx.application.Application -- and
launch them directly by calling into the JavaFX launcher code. See
JDK-8001533 https://bugs.openjdk.java.net/browse/JDK-8001533. This is
why
This may, in fact, be the root cause of
https://javafx-jira.kenai.com/browse/RT-20988 which was resolved for FX
8 when we moved jfxrt.jar into lib/ext so I didn't look into it further.
It is unlikely that we will fix this for an FX 2 release, so can you try
it with FX 8 and see if it works
Unfortunately, this is not currently available, as we don't have a good
way to track and tag the bugs as to which build they were fixed in.
-- Kevin
Herve Girod wrote:
Hello,
I just noticed that the new JDK 8 build 123 appeared today or yesterday. As
usual it include the change list for the
Mong,
Please review the following (in the JIRA).
https://javafx-jira.kenai.com/browse/RT-34791
Thanks.
-- Kevin
1 - 100 of 4743 matches
Mail list logo
