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 t
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
!
modules/base/src/main/java/com/sun/javafx/collections/Observa
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
! modules/graphic
+1
David
Sent from my iPhone
On Jul 12, 2013, at 3:15 PM, Richard Bair 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 {
>Paint() { } // <--- Add
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 for the enum approach...will make it easier to enhance for future options...
Gerrit
Am 12.07.2013 um 19:55 schrieb Richard Bair :
> 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
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
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 wrote:
> Is possible to setting different color for individually element
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, wi
afaik this is not possible. You might want to build the structure out of lines
for that you could set the color separately on each line. But this will inly
make sense with not too complex paths.
Cheers,
Gerrit
Am 13.07.2013 um 09:38 schrieb fajar :
> Is possible to setting different color fo
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 javafx.scene.shape
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
! modules/graphics/src/main/java/com/sun/glass/ui/Appli
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 impl_proc
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 process
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, Tab
I hesitate to mention Node#impl_processCSS(boolean) which is very very close to
your notion of applyCss(); impl_processCSS(boolean) is a thorn in my side, but
is used in certain places in controls code to ensure CSS is applied before
layout in order to ascertain a node's dimensions. What it doe
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 th
>> Is there any reason why I might want to measure a node independent of the
>> layout of its parent? If I have a Button in a StackPane, is there a time I
>> might want to measure the Button independent of the StackPane? I suppose so,
>> if for example I wanted to get snapshots of it at its min
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++)
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
It's quite interesting and hard to say so I won't speculate other than
to say that for some of the low level FPS test, RoboVM was slower.
However, the numbers were suspicious in that they seemed to be capped at
a maximum frame rate. Needs more investigation to make sure that the
measurements
Painting a plain rectangle is ok. But using a stackpane to draw a javafx styled
button over a plain painted rectangle node is very slow.
Am 12.07.2013 um 17:03 schrieb Richard Bair :
> BTW, we've run a VM performance benchmark against HotSpot on PI vs. RoboVM on
> iOS and for raw power RoboVM s
> 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 w
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
RoboVM doesn't do release builds yet (virtually none of LLVM's
optimizations are enabled) and virtual and interface method dispatch is
horribly slow (linear search on every call!!!). So there are A LOT of
opportunities for improvements. The focus so far has been to get something
up and running whic
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 AM
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.
Rich
The performance is much better than JavaFX8 on iOS :(
Am 12.07.2013 um 15:37 schrieb August Lammersdorf, InteractiveMesh
:
> 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 that
Found this on YouTube: http://www.youtube.com/watch?v=-scxqJjTJKI
August
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 i
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 wr
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
Changeset: c6a7452039b6
Author:Alex X. Lee
Date: 2013-07-11 18:23 -0700
URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/c6a7452039b6
Joints' transforms were sometimes not marked dirty when they were; this caused
the animation of multiple meshes to be desynchronized.
!
a
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: 82163cce
35 matches
Mail list logo