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) comma
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 :
>
> 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
>
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 wrote:
> Hi Robert,
>
> Please file a Jira issue with a simple t
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 p
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 lo
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 is
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, Morris
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 - http://cr.openjdk.java.net/~morris/RT-38
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 W
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 wrote:
> I searched the bug databas
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 object
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
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 {
List
13 matches
Mail list logo
