Changeset: 230a187a7746
Author:mv157916
Date: 2013-07-07 19:34 -0700
URL: http://hg.openjdk.java.net/openjfx/8/master/rt/rev/230a187a7746
RT-31472: Update the JDK build number to b97 in rt/build.properties file in the
JavaFX 8 Master forest.
! build.properties
Changeset:
Changeset: 8ed8e95a28d2
Author:jgiles
Date: 2013-07-11 09:44 +1200
URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/8ed8e95a28d2
Remove unused EmbeddedResources and embedded.properties files.
! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/FXVKSkin.java
What you suggest would be quite hard to use. Actually I think most of
the developers will not know how to use it properly in order to get the
right measurement.
Simple validate call would be more convenient and less error-prone.
-Martin
On 07/12/2013 12:02 AM, steve.x.northo...@oracle.com
I don't agree. It's pretty clear that when you call applyCSS(), then
CSS is applied. The rest of the JFX API works exactly as expected and
as documented. The programmer has precise control over what happens,
when it happens and where it happens.
Can you summarize what validate does? Is it
Found this on YouTube: http://www.youtube.com/watch?v=-scxqJjTJKI
August
The thing is that in order to compute the layout correctly, you have to
start from the layout root. The concept of layout roots is not
documented well in the API ( we use the term in few place, but never
define it) and people would have to know how to identify the layout root
and also know
The performance is much better than JavaFX8 on iOS :(
Am 12.07.2013 um 15:37 schrieb August Lammersdorf, InteractiveMesh
s...@interactivemesh.com:
Found this on YouTube: http://www.youtube.com/watch?v=-scxqJjTJKI
August
That should be encouraging, since the CPU on the PI is *way* worse than the CPU
on an iPhone or iPad. Is the difference HotSpot vs. RoboVM? The graphics code
being executed should be pretty much exactly the same, and I would expect the
PowerVR to be able to handle this without any trouble.
BTW, we've run a VM performance benchmark against HotSpot on PI vs. RoboVM on
iOS and for raw power RoboVM seems faster (lower time to invoke a method, read
a field, etc etc). However in the real world RoboVM is slow and I don't know
why (GC overhead maybe)?
Richard
On Jul 12, 2013, at 7:52
On 07/12/2013 04:49 PM, Richard Bair wrote:
The thing is that in order to compute the layout correctly, you have to start
from the layout root.
I think where you start the computation from depends on what you are trying to do. I
think that validate or whatever we would call it would just be a
The thing is that in order to compute the layout correctly, you have to start
from the layout root.
I think where you start the computation from depends on what you are trying to
do. I think that validate or whatever we would call it would just be a
convenient wrapper that did whatever we
I think these are the sample apps:
http://interactivemesh.org/testspace/j3dmeetsjfx.html
I take that back, the PI HotSpot numbers are generally faster than the RoboVM
iOS numbers (but RoboVM is faster than HotSpot when run as an interpreter,
obviously). We need to get our benchmark open source
Here's my acid test, put a square grid of circles in a scroll pane. Scale
up until pain is felt.
GridPane gp = new GridPane();
//int size = 3;
int size = 10;
//int size = 32;
// int size = 100;
//int size = 317;
for (int x = 0; x size; x++)
Have you tried running with the perf logger turned on? -Djavafx.pulseLogger=true
This will tell you a little something about where the time is spent. It might
not be detailed enough, but you can then put additional log statements in the
code to get more direct answers to questions about where
My thought was that applyCSS could for now just call impl_processCSS(true) --
so it is Thor's Hammer and will just hammer everything to be updated. Not
necessarily fast. Then in subsequent releases we could maybe tune it up. Do we
*need* the boolean? I know it is sometimes false (TreeView,
There is Node#impl_processCSS() that is the normal css processing path
(Scene#doCSSPass - Node#processCSS - Node#impl_processCSS() -
CssStyleHelper#transitionToState) .
impl_processCSS(boolean) was left in because it is a way of forcing the reapply
in cases where CSS was needed to be processed
I'm thinking applyCSS would just call impl_processCSS(true) and then we should
work towards removing impl_processCSS(boolean) if possible, so that we're all
just using applyCSS() all the time (once impl_processCSS(boolean) can be
removed and all bugs sorted out, then we could just move
Changeset: 1297b31c4bec
Author:Alexander Zvegintsev
Date: 2013-07-12 14:51 +0400
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/1297b31c4bec
RT-31441: FX doesn't care about nested event loops and shutdowns too early
!
Is possible to setting different color for individually element in path?
for example:
package test;
import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.layout.StackPane;
import javafx.scene.paint.Color;
import javafx.scene.shape.ArcTo;
import
Thor recently pushed an implementation for MSAA for those cases when the
feature is supported by the card and where a Scene (or SubScene) is created
with the antiAliasing flag set to true. MSAA is Multi-sampled Anti Aliasing,
which means that the graphics card, when configured in this mode,
No, it is not possible. Each path is a single shape, and all shapes have a
single fill / stroke / etc. You will need to use several paths and position
them accordingly.
Thanks
Richard
On Jul 13, 2013, at 12:38 AM, fajar si.siput.ngan...@gmail.com wrote:
Is possible to setting different color
I have two different changes I might want to make, both of which are definitely
incompatible for subclasses, but are otherwise source compatible.
public abstract class Paint {
Paint() { } // --- Add this package constructor. Anybody who subclassed
Paint will die
}
public final class Color
+1 for the enum approach...will make it easier to enhance for future options...
Gerrit
Am 12.07.2013 um 19:55 schrieb Richard Bair richard.b...@oracle.com:
Thor recently pushed an implementation for MSAA for those cases when the
feature is supported by the card and where a Scene (or
totally agree on this, if I could clone myself we would have FXAA shaders :P
-J
On 7/12/2013 10:55 AM, Richard Bair wrote:
public enum SceneAntiAliasing {
DISABLED,
DEFAULT,
MSAA_2X,
MSAA_4X
}
+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 which are
definitely incompatible for subclasses, but are otherwise source compatible.
public abstract class Paint {
Changeset: 2f8df448a0c5
Author:raginip
Date: 2013-07-12 14:59 -0700
URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2f8df448a0c5
RT-31629 : Change accessibility from Control to Node level
! modules/controls/src/main/java/javafx/scene/control/Control.java
!
Changeset: ddbfe8ed6e7b
Author:Alexander Kouznetsov
Date: 2013-07-12 19:17 -0700
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/ddbfe8ed6e7b
Fix for RT-31109 Make ObservableArrays to grow as ObservableLists
!
Usually questions of this kind are better answered on
https://forums.oracle.com/community/developer/english/java/javafx/javafx_2.0_and_later
(which I see just go a face-lift, looks great!).
What you should do depends on what you need. Have you looked into the Canvas
node? I agree trying to do
28 matches
Mail list logo
