On Fri, Mar 27, 2015 at 12:16 AM, Scott Palmer swpal...@gmail.com wrote:
I am successfully using the javafx gradle plugin to produce a packaged app
on Windows and Linux. (Thanks Danno!)
I haven't tried much with Mac yet, but I believe it will make an
application bundle.
That sounds great. I
I am experimenting with JavaFX and I am trying to add a check box Item in
tree table, but it looks like it supports only simple tree item.
My Code is modified version of [Oracle's TreeTableView Example][1]:
public class TreeTableViewSample extends Application implements
Runnable {
Reminder, Monday is our weekly sanity testing.
You can find your testing assignment at:
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing
Also please remember that the repo will be locked from 1am PST until 1pm
PST.
And after that there will be new rules in effect regarding pushing
Hi, Morris.
Just curiously, does it mean that after the fix, there is no way to
maximize the window on two monitors in multi-monitors configuration?
Does this issue affects an applets? Seems that on Windows the clipping
on the screen bounds is a default native behavior.
27.03.15 22:39,
Looks like someone is adding weak listeners to ProgressBarSkin$1 in
the first case and to Node$NodeTransformation$2 in the second case,
but does not bother removing them, relying on the WeakReference to
enable their garbage collection. Well, the listeners themselves get
garbage collected, but the
Kevin, David and Chien,
Please review this patch, which fixes RT-38836 (a critical) and RT-23363
(a medium). It clips the frame to screen size in Glass-Mac in a similar
fashion to what happens in Glass-Windows.
Thanks much,
--morris
WEBREV -
I don't have a two monitor display setup for the Mac platform. Will run
CircleApp1, CircleApp2, CircleApp3 and MaxStage in applet on both
Windows 8.1 and Mac and report back.
--mm
On 3/27/15 4:05 PM, Sergey Bylokhov wrote:
Hi, Morris.
Just curiously, does it mean that after the fix, there
I searched the bug database and though ProgressBar leaks have been reported
before, they are supposed to be fixed in 8u40. I'm seeing tons of leaks in
8u40.
Comparing heap dumps with jvisualvm I see in three minutes that my app has
accumulated 11,000 WeakReference and BindingHelperObserver
Another chain to the GC root looks like:
WeakReference
BindingHelperObserver
InvalidationListener[]
ExpressionHelper$Generic
Node$NodeTransformation$2
Node$NodeTransformation
StackPane
ProgressBarSkin
ProgressBar
On Fri, Mar 27, 2015 at 2:28 PM, Scott Palmer swpal...@gmail.com wrote:
I
Hi Robert,
Please file a Jira issue with a simple test case. Arcs are handled as a
generalized shape rather than via a predetermined shader, but it
shouldn't be that slow. Something else may be going on.
Another test might be to replace the arcs with rectangles or ellipses
and see if the
The bad full screen performance is without the arcs. It is just one call to
fillRect, two to strokeOval and one to fillOval, that's all. I will build a
simple test case and file an issue.
On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham james.gra...@oracle.com wrote:
Hi Robert,
Please file a Jira
In my opinion the whole graphics performance on MacOSX isn’t good at all with
JavaFX….
Am 27.03.2015 um 22:10 schrieb Robert Krüger krue...@lesspain.de:
The bad full screen performance is without the arcs. It is just one call to
fillRect, two to strokeOval and one to fillOval, that's all.
Hi,
I have a super-simple animation implemented using AnimationTimer and Canvas
where the canvas just performs a few draw operations, i.e. fills the screen
with a color and then draws and fills 2-3 circles and I have already
observed that each drawing operation I add, results in significant CPU
Possibly related:
I can reproduce a massive (90%) performance drop on OSX between drawing a
wireframe polygon on a Canvas using a series of gc.strokeLine(double x1,
double y1, double x2, double y2) commands versus using a single
gc.strokePolygon(double[] xPoints, double[] yPoints, int count)
14 matches
Mail list logo
