Re: Scene graph performance

[Dr. Michael Paus]

Hi Felix,
I have written various tests like the ones you use in FXMark and I have
obtained similar results. I have even tried to substitute 2D shapes by
using 3D MeshViews in the hope that this would give better performance
but the results were not that good. Of course all this depends on the
specific test case but in general I see that a JavaFX application which
makes heavy use of graphics animations is completely CPU-bounded.
The maximum performance is reached when one CPU/Core is at 100%.
The performance of your graphics hardware seems to be almost irrelevant.
I could for example run four instances of the same test with almost the
same performance at the same time. In this case all 4 cores of my machine
were at 100%. This proves that the graphics hardware is not the limiting
factor. My machine is a MacBook Pro with Retina graphics and a dedicated
NVidia graphics card which is already a couple of years old and certainly
not playing in the same league as your high-power card.
I myself have not yet found a way to really speed up the graphics 
performance
and I am a little bit frustrated because of that. But it is not only the 
general
graphic performance which is a problem. There are also a lot of other 
pitfalls

into which you can stumble and which can bring your animations to a halt
or even crash your system. Zooming for example is one of these issues.

I would like to have some exchange on these issues and how to best address
them but my impression so far is that there are only very view people 
interested

in that. (I hope someone can prove me wrong on this :-)

Michael

Am 20.07.16 um 04:14 schrieb Felix Bembrick:

Having written and tested FXMark on various platforms and devices, one
thing has really struck me as quite "odd".

I started work on FXMark as a kind of side project a while ago and, at the
time, my machine was powerful but not "super powerful".

So when I purchased a new machine with just about the highest specs
available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X
GPUs in SLI mode, I was naturally expecting to see significant performance
improvements when I ran FXMark on this machine.

But to my surprise, and disappointment, the scene graph animations ran
almost NO faster whatsoever!

So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a
rudimentary (single) GPU and, guess what - almost the same level of
performance (i.e. FPS and smoothness etc.) was achieved on this
considerably less powerful machine (in terms of both CPU and GPU).

So, it seems there is some kind of "performance wall" that limits the
rendering speed of the scene graph (and this is with full speed animations
enabled).

What is the nature of this "wall"? Is it simply that the rendering pipeline
is not making efficient use of the GPU? Is too much being done on the CPU?

Whatever the cause, I really think it needs to be addressed.

If I can't get better performance out of a machine that scores in the top
0.01% of all machine in the world in the 3DMark Index than an entry level
PC, isn't this a MAJOR issue for JavaFX?

Blessings,

Felix

Re: JavaFX with Eclipse and JDK9

[Dr. Michael Paus]

Am 06.07.16 um 12:05 schrieb Tom Schindl:

For what is worth - the problem is that JDT-Beta-Builds are only modules
starting with "java.".

I've started a thread at jdt-core mailing list [1] - I started working
on a patch to also add "javafx." and hope it gets accepted.

I keep my fingers crossed. Keep us informed about the outcome.


Tom

[1]http://dev.eclipse.org/mhonarc/lists/jdt-core-dev/msg02626.html

On 27.05.16 16:04, Dr. Michael Paus wrote:

I recently tried to get a JavaFX application running with the latest EA
build of JDK9 from
within Eclipse but I failed. Can anybody on this list tell me what I
have to do to get that
working? I have the latest milestone release of Eclipse Neon installed
together with the
latest JDK9 and I have also installed the Java 9 Support (BETA) for
Neon. I also installed
e(fx)clipse if that should matter. The problem is that I cannot access
any of the JavaFX
packages. I even added a module-info.java file to the project which
explicitly requires the
JavaFX modules but nothing helped so far. The JRE System Library only
contains the modules
which are in the java.* namespace but none of the other modules
especially the javafx.*
modules and I don't find any option to add these. Did anybody ever try
this and succeeded?

Thanks, Michael

JavaFX with Eclipse and JDK9

[Dr. Michael Paus]

I recently tried to get a JavaFX application running with the latest EA 
build of JDK9 from
within Eclipse but I failed. Can anybody on this list tell me what I 
have to do to get that
working? I have the latest milestone release of Eclipse Neon installed 
together with the
latest JDK9 and I have also installed the Java 9 Support (BETA) for 
Neon. I also installed
e(fx)clipse if that should matter. The problem is that I cannot access 
any of the JavaFX
packages. I even added a module-info.java file to the project which 
explicitly requires the
JavaFX modules but nothing helped so far. The JRE System Library only 
contains the modules
which are in the java.* namespace but none of the other modules 
especially the javafx.*
modules and I don't find any option to add these. Did anybody ever try 
this and succeeded?


Thanks, Michael

Re: [9] Review request: 8091832: Provide API for getting the Screen scale on HiDPI screens

[Dr. Michael Paus]

Hi,
I'd like to know on which systems this distinction between X- and 
Y-direction is actually relevant.

I've never seen such a system before.
Michael

Am 29.03.16 um 03:25 schrieb Jim Graham:

bug: https://bugs.openjdk.java.net/browse/JDK-8091832
webrev: http://cr.openjdk.java.net/~flar/JDK-8091832/webrev.rt.00/

This webrev fixes pixel snapping and application control over pixel 
scaling on HiDPI screens:


- snap*() methods are all updated to take the current scale into account
- new variants of snap*() methods are added for separate X/Y control:
Added: Region.snapSpaceX/Y()
Added: Region.snapSizeX/Y()
Added: Region.snapPositionX/Y()
- the non-X/Y variants of the above methods are now deprecated:
Deprecated: Region.snapSpace()
Deprecated: Region.snapSize()
Deprecated: Region.snapPosition()
- methods to query the scale values of Screen objects:
Added: Screen.getOutputScaleX/Y()
- properties to query and/or modify the scale values of Window objects:
Added Read-Only  DoubleProperty:  Window.getOutputScaleX/Y()
Added Read-Write BooleanProperty: 
Window.set/getForceIntegerRenderScale()

Added Read-Write DoubleProperty: Window.set/getRenderScaleX/Y()

The changes have been compiled and tested on Windows and Mac and there 
were trivial changes needed to the Linux files to adapt to one new 
method signature, but I haven't done the test build on Linux yet...


...jim

Re: report defect

[Dr. Michael Paus]

You can report your issue here:
http://bugreport.java.com/
Don't forget the JavaFX label.

Am 10.01.16 um 11:22 schrieb Peter Penzov:

Hi,
I want to open defect about JavaFX charts. More information here:

http://stackoverflow.com/questions/34571154/limit-width-size-of-stacked-bar-chart/34699937?noredirect=1#comment57153895_34699937

Can you give me some information how to report it?

BR,
Peter

Re: Full Screen Mode in JavaFX WebView

[Dr. Michael Paus]

If I navigate with my WebView to a page with an embedded video player, 
like for example youtube,
and I then hit the full-screen button of this player how would my 
application know that the web page
would now like to be shown in full-screen mode, so that I can handle 
that in the way you explained?


Am 05.01.16 um 16:21 schrieb Kevin Rushforth:
Thank you for filing the RFE. Since WebView is an embedded component 
in a JavaFX scene graph, I'm not sure how easily we can (or whether we 
want to) implement browser full screen, but we can take a look at it 
and see whether it makes sense as a future enhancement.


Note that a JavaFX application Stage can become full-screen via 
Stage.setFullScreen(true). If you set up your scene graph with a 
StackPane as the root and a WebView node is the only child of the 
root, then you should be able to accomplish the same thing.


-- Kevin


BoydEdmondson-NebulaSoftware wrote:

http://bugs.java.com, ID's of JI-9028282 and JI-9028283.

Boyd

-Original Message-
From: BoydEdmondson-NebulaSoftware Sent: January 5, 2016 5:31 AM
To: 'Guru Hb'
Cc: 'openjfx-dev@openjdk.java.net'
Subject: RE: Full Screen Mode in JavaFX WebView

setPrefWidth/Height() do not help.

I submitted a request for enhancement to support 
https://fullscreen.spec.whatwg.org.
I submitted a bug for WebView hanging on 
http://browserbench.org/JetStream compliance test.


Boyd

-Original Message-
From: BoydEdmondson-NebulaSoftware Sent: January 4, 2016 8:36 AM
To: 'Guru Hb'
Cc: openjfx-dev@openjdk.java.net
Subject: RE: Full Screen Mode in JavaFX WebView

I'll give that a try, thanks.

The application works fine in all other browsers I've tested. It just 
fails in WebView.  I'll log defects as you suggest.


Boyd

-Original Message-
From: Guru Hb [mailto:guru...@oracle.com] Sent: January 4, 2016 8:33 AM
To: BoydEdmondson-NebulaSoftware
Cc: openjfx-dev@openjdk.java.net
Subject: RE: Full Screen Mode in JavaFX WebView

Please see comments embedded
-Original Message-
From: BoydEdmondson-NebulaSoftware 
[mailto:boydedmond...@nebulasoftware.com] Sent: Monday, January 04, 
2016 7:01 PM

To: openjfx-dev@openjdk.java.net
Subject: Full Screen Mode in JavaFX WebView

I have a custom Java application that uses JavaFX WebView to create a 
web browser (which uses WebKit).  I am trying to get the browser full 
screen mode to work (https://fullscreen.spec.whatwg.org/).




How can I get full screen mode to work in WebKit?
[WebView is an Embedded component and current it doesn't have full 
screen context menu (Like what we see in browser). WebView exposes 
two api setPrefWidth  & setPrefHeight, you can try setting it to max 
allowable view port size based on screen resolution. In addition (But 
I don't suggest), set the stage or group border to 0. But do NOTE 
that there won't be scroll bars visible, But you can drag the webpage]



I'm also trying to get WebKit's Web Inspector to work in my browser 
to help me debug this issue.  How can I activate Web Inspector in 
JavaFX WebView?
[Sorry, Web Inspector is not enabled in this port (Webkit port of 
JavaFX), alternatively you could  debug the application on Chrome or 
Safari. If you find a difference in the Rendering, JavaScript or 
other defect, feel free to log a defect ref 
https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report]

Thanks for any information.

Re: Constant resetting to initial-state when adding/remove styleclasses

[Dr. Michael Paus]

If anyone is counting these votes for better performance I'll add 1+ too :-)

Am 22.12.15 um 07:15 schrieb Tom Schindl:

Hi,

While debugging some code I attached a listener to a property and
noticed that whenever a style-class is added to the control or even
worse somewhere in the parent hierarchy that FX resets the value to its
initial state (Node#reapplyCss & CssStyleHelper) only to set it back to
it's real value with the next CSS-Pass triggered by the next pulse.

I don't want to imagine if this happens with many value set via CSS and
eg adding/remove a styleclass to the scene root. Is this behavior really
by design like this?

You can try that yourself with the attached program below and using the
css at the end. I'm writing this because of Kevins request what the team
should invest time to because of Java9 delays and frankly all of those
bugs/features sound relevant and interesting but JavaFX performance
(most important CSS-Performance) is still miles away from eg browsers
who are the main competitors.

It doesn't help me to get an java.awt.Desktop replacement if my
input-forms do not render in a decent time frame - I would even say
rendering them in 2015 most be almost instant.

Tom


package application;

import javafx.application.Application;
import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.BorderPane;
import javafx.scene.layout.HBox;
import javafx.scene.layout.StackPane;


public class Main extends Application {
@Override
public void start(Stage primaryStage) {
try {
BorderPane root = new BorderPane();

StackPane p = new StackPane();
p.getStyleClass().add("test-css");
p.maxWidthProperty().addListener( (o, ol, ne) -> {
System.err.println("Modified : " + ol + " " + 
ne);
Thread.dumpStack();
});

root.setCenter(p);

HBox box = new HBox();

{
Button b = new Button("Modify Pane CSS");
b.setOnAction( e -> 
p.getStyleClass().add("dummy"));
box.getChildren().add(b);
}

{
Button b = new Button("Modify Root CSS");
b.setOnAction( e -> {
root.getStyleClass().add("dummy");
});
box.getChildren().add(b);
}

root.setBottom(box);

Scene scene = new Scene(root,400,400);

scene.getStylesheets().addAll(getClass().getResource("application.css").toExternalForm());
primaryStage.setScene(scene);
primaryStage.show();
} catch(Exception e) {
e.printStackTrace();
}
}

public static void main(String[] args) {
launch(args);
}
}



.test-css {
-fx-max-width: 300;
}

Re: Update on FX plans for JDK 9

[Dr. Michael Paus]

Hi,
what I am missing in this list are any activities to generally improve 
the interaction of JavaFX applications
with the operating system they are running on. Some of these issues may 
be covered in an OS specific
way by "JDK-8091517: Implement com.apple.eawt APIs ..." but should 
actually be treated in a more general way.


For example double clicking a file and launching an associated JavaFX 
application. This is a concept
which is used by all major operating systems although the internal 
handling is different. For the Mac

this issue is for example discussed here:

http://stackoverflow.com/questions/29101472/pass-parameters-to-javafx-application-by-double-click-on-file

But as this is a general concept I would also appreciate a general 
solution in JavaFX so that you do not have

to clutter your code with various system specific handlers.

Michael

Am 17.12.15 um 15:21 schrieb Kevin Rushforth:
Given the recently announced JDK 9 schedule slip [1], we have taken 
the opportunity to explore what RFE's / Features we could possibly now 
work on for inclusion in JDK 9. We wanted to give you a pre-holiday 
season update on what we are currently thinking.


The following RFEs are in progress or planned for JDK 9:

  JDK-8144585: Encapsulate JavaFX impl_* implementation methods
  JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs
  JDK-8091308: Define fine-grained permissions for JavaFX
  Expose Hi-DPI properties for render scale and screen scale (FX 
equivalent task for JEP 263 JDK-8055212)
  Multi-resolution image support (FX equivalent task for JEP 251 
JDK-8046010)


Additionally, we have started to look into making public API for some 
of the impl_* API that will otherwise be hidden by JDK-8144585. See 
Jonathan's earlier e-mail on the subject [2]. Here is what we have so 
far:


  JDK-8144628: Provide API to expose list of showing Windows
  JDK-8144625: Expose code and char properties on KeyCode
  JDK-8144962: Promote TableColumn reorderable property to public API
  JDK-8144871: Add default method getStyleableNode to Styleable interface
  JDK-8145143: Promote Image.impl_getUrl() to public API as 
Image.getUrl()
  JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and 
Labeled


If there are any we have missed that your application depends on, 
please send e-mail to Jonathan.


Finally, here is an updated list of other RFEs we might consider for 
JDK 9. We will not be able to do all of these, but hope to be able to 
do many of them. We could use the help of the OpenJFX community in 
prioritizing this list or possibly adding something that we missed, as 
long as the scope is small enough.


  JDK-8091107: Add java.awt.Desktop support to javafx
  JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX 
(FX equivalent for JEP 272)

  JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux
  JDK-8092040: Implement Image writers for JavaFX
  JDK-8091673: Runtime should have a published focus traversal API for 
use in custom controls
  JDK-8089311: [TableCell] commit on focus lost not possible in every 
case

  JDK-8090477: Customizable visibility timing for Tooltip
  JDK-8092098: [TabPane] Support for draggable tabs
  JDK-8144556: Add support to allow user specified rendering order
  JDK-8145443: [Mac] Render directly to NSWIndow rather than via 
CALayer for non-applet Stage
  JDK-8145154: Provide public API support for PerformanceTracker 
functionality

  JDK-8090763: Public API for Glass's robot functionality

Let us know what is most important to your application.

We will keep you posted with updates on what exactly is being targeted 
(note that you can track it by looking at the Fix Version in JBS, 
which we strive to keep up-to-date).


Thanks!

-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html
[2] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Dr. Michael Paus]

A lot of the confusion here is probably caused by the fact that I (and 
obviously others too)
did not know about the possibility to distinguish between building for 
the Apple app store
and building a package for self-distribution. Is this distinction made 
by either creating a
DMG for self-distribution or a PKG for the Apple app store or is there 
even some other
switch? I could live with that for the moment but is all this documented 
somewhere?
At least the help function of the javapackager does not even mention the 
possibility

of creating PKG files.

Am 18.11.15 um 14:18 schrieb Kevin Rushforth:

[moving this back to the openjfx alias; Bcc awt-dev]

The javapackager fix for JDK 8u72 does exactly this when generating 
.pkg files. So in short, libjfxwebkit.dylib is unchanged for 8u72, but 
will be excluded when generating an app for the Apple app store.


-- Kevin



Michael Hall wrote:
On Nov 16, 2015, at 2:10 PM, Ondřej Kvasnovský 
mailto:ondrej.kvasnov...@gmail.com>> 
wrote:




I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from 
https://jdk8.java.net/download.html):
otool -L 
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib 
| grep icu


Would a work-around not being implement the current recommended fix 
yourself. Move this aside while you package or app and then put it 
back. Or a little more extreme, just delete it.
I’m not that familiar with packager yet, do you know this is the jdk 
that will be used by it for embedding?


Michael Hall

Re: Java 8 updates are causing "Apps that use non-public APIs will be rejected"

[Dr. Michael Paus]

Just in order to better understand this issue and the fix. Does this 
mean that the packager
will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? 
That would mean
that I could not bundle and distribute any application anymore for the 
Mac which uses
a WebView. Have you considered the fact that many people do bundle their 
apps but
have their own distribution channels and do not upload the apps to the 
Apple store.

There should at least be some switch to override this behavior.
Just my 2+1/2 cents.
Michael




Am 17.11.15 um 18:31 schrieb Kevin Rushforth:

[taking awt-dev off of this thread]

The fix that was put into 8u72-b02 is that the packager will no longer 
include libjfxwebkit.dylib in the packaged app. Is this not working 
correctly?


-- Kevin


Sergey Bylokhov wrote:
I think openjfx-dev@openjdk.java.net (cc) is correct place to ask 
this question.


On 16.11.15 23:10, Ondřej Kvasnovský wrote:

Hi,

We are facing to an issue with latest Java updates when we try to
release apps into Apple app store. I have described the issue here, 
with

all my findings:
http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html 



In short, the issue is that we are not able to release Java app into 
app

store since 1.8_60 because it uses private API (see the link above if
you want to know how to verify that).

I spoke about this issue with Martijn Verburg and he pointed me to 
these

two issues:
https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72
https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9
(replace private libs with public ones)

I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from
https://jdk8.java.net/download.html):
otool -L
/Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib 


| grep icu
/usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current
version 51.1.0)
And it the issue is still there, Build b05 still references private 
API.


I could even try to build and app and try to publish it for code review
by Apple... but since there is this reference, I do not believe it is
going to be successful.

Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is
considered to be fixed, but it seems it is not, could someone help with
that?


Best wishes,
Ondrej Kvasnovsky

Re: Missing Mac APIs in JavaFX

[Dr. Michael Paus]

Hi,

I agree with you that these things should work as expected with JavaFX. 
Have you filed a bug report for them?
In addition to the platform specific APIs I would prefer a common 
solution for common things though, like opening

a file which is associated with your application.

Michael

Am 04.11.15 um 04:41 schrieb Neil Brown:

Hi,

Short version: I believe JavaFX is lacking some Mac-related APIs which 
cannot be worked around without an internal com.sun.* call, and would 
like to request that the APIs be added/made public for JDK 9, perhaps 
as part of Jonathan Giles' work around JEP 253.


I stand to be corrected on any of this...

Long version: On Windows and Linux, files are generally opened via 
command-line arguments.  On Mac, there is a file-open event issued to 
an application, e.g. you double-click a .txt file, TextEdit gets a 
file-open event.  If TextEdit is not open, it will be launched, then a 
file-open event will be sent to it.


Pre-JavaFX, the Java solution to receive these events was to use the 
com.apple.eawt.* packages, which Oracle added in JDK 7. However, it 
seems that these APIs don't play nice with FX.


I've put some source code at the end of the email for a simple 
application which I bundled with infinitekind's appbundler fork for 
testing (https://bitbucket.org/infinitekind/appbundler/).  No matter 
where you uncomment the setEAWTFileHandler call (search AAA, or BBB in 
the source), the .app always misses the initial load event which 
caused the application to open.  The net result is if the user 
double-clicks an associated file, the JavaFX application will launch, 
but not load the file in question unless the user double-clicks it 
again.  Needless to say, this is problematic.


If you look at the FX source code, you can see that FX does set a 
file-open event handler with an empty implementation 
(com.sun.glass.ui.Application, line 83 in 8u60).  Grepping the source 
code shows this method is not implemented anywhere in the source code, 
so FX is simply discarding the event.  The only Java way I've found to 
let an FX application listen to the open files event is using a 
com.sun call in the Application constructor (see CCC in the source, 
and setFXFileHandler).  Suggestions for a better work-around very 
welcome!



The second API is a similar problem.  JavaFX installs an application 
menu with standard options, including "Quit" (bound to Cmd-Q).  If you 
leave Platform.setImplicitExit to its default value of true, all is 
well.  Cmd-Q quits the application. However, if you 
setImplicitExit(false) (see YYY in the source), as our actual 
application must, problems arise.  The quit handler now is a no-op, 
with no way of overriding it.  Pressing Cmd-Q or right-clicking the 
dock and selecting quit is now totally ignored by the application, and 
from the user's perspective the app is unquittable by these normal 
means.  The only work-around I've found is to set a quit handler in 
the same spot we set the file open handler (see ZZZ in the source: 
I've used Platform.exit for this example, in reality we have a nicer 
custom shutdown routine).



My proposal is fairly straight-forward: the 
com.sun.glass.ui.Application.EventHandler class (and associated 
setEventHandler call) needs to become a public API in JDK 9, or else 
these issues will be impossible to work around post-modularisation. 
Initial file open and quit handler are the only ones biting us at the 
moment, but I suspect that whole handler class should be public, 
either as-is or by repurposing it into an EventHandler with some sort 
of AppEvent extends Event class.


Thanks,

Neil.

==
src/example/OpenApp.java
==
package example;

import java.io.File;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.stream.Collectors;
import javafx.application.Application;
import javafx.application.Platform;
import javafx.collections.FXCollections;
import javafx.collections.ListChangeListener;
import javafx.collections.ObservableList;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.control.Menu;
import javafx.scene.control.MenuBar;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;

public class OpenApp extends Application
{
private static ObservableList requestedFiles = 
FXCollections.observableArrayList();


public static void main(String[] args)
{
// AAA: Uncommenting here, we miss initial load events:
//setEAWTFileHandler();
launch(args);
}

@Override
public void start(Stage stage) throws Exception
{
// YYY: this causes problems.
//Platform.setImplicitExit(false);
// BBB: Here also misses initial load events:
//setEAWTFileHandler();

BorderPane bp = new BorderPane();
Label filename = new Label("");
bp.setCenter(filename);
Runnable updateFiles = () -> 
filename.setText(requestedFiles.stream().map(File::getAbsoluteP

Re: Windows Hi-DPI

[Dr. Michael Paus]

I'd really like to know how you would add the remaining 99% of resources 
to the system once your scene graph is set up and you have started an 
animation which then turns out to be running slowly. JavaFX just uses 1 
rendering thread and there is nothing you can do about that. Even with 
99 additional cores you could do nothing to make that faster unless you 
would be using the new Marlin rasterizer. Even then only JavaFX itself 
could make use of that because it does not have any public API that you 
could mess with.


Am 30.10.15 um 17:56 schrieb Bogdan Ibanescu:

The point I'm trying to make is that if you're running a single threaded 
application, it'll use 1 core.

What you need to understand is that javafx does not magically figure out how 
organize rendering procedures across the systems' resources.

The reason for which whatever you're trying to test seems to be about as fast 
on your computer as it is on your wife's' is because it's most likely not 
multi-threaded, or plainly badly implemented.
Cross-fire and SLI and all that other crap is useless if you're only using 1% 
of your resources. All windows does when you select the GPU is the driver 
end-point. Activating it makes it run slightly faster because of the 
differences in hardware... but the lack of performance is the poor code in your 
software.

- Original Message -
From: "Felix Bembrick" 
To: "Bogdan Ibanescu" 
Cc: "Chris Nahr" , openjfx-dev@openjdk.java.net
Sent: Friday, October 30, 2015 5:37:35 PM
Subject: Re: Windows Hi-DPI

Yes, but unless you are saying that having more cores, more VRAM, faster VRAM 
and a much faster clock speed are actually going to slow down the performance 
of JavaFX then I don't know what point you are trying to make.


On 31 Oct 2015, at 01:03, Bogdan Ibanescu  wrote:

Having 200 cores won't help you with anything unless you explicitly customize 
your code to make use of them.

- Original Message -
From: "Felix Bembrick" 
To: "Chris Nahr" 
Cc: openjfx-dev@openjdk.java.net
Sent: Friday, October 30, 2015 11:55:19 AM
Subject: Re: Windows Hi-DPI

The NVIDIA Control Panel allowed me to disable SLI completely and I even 
rebooted.  I also upgraded to Java 8u72.

Sadly JavaFX still performs like a one-legged dog dragging a cannon ball on a 
chain.

All other 3D apps, games etc. perform blindingly fast as I would expect.

So, if it's not an SLI or driver problem, what is going on here (or not going 
on)?

Felix


On 30 Oct 2015, at 19:47, Felix Bembrick  wrote:

That's curious. SLI is designed specifically with gamers in mind!

I'll investigating running without SLI and report back.

Felix


On 30 Oct 2015, at 19:44, Chris Nahr  wrote:

If it's slower on an SLI machine than on an ordinary one then yes, I suspect 
JavaFX just can't handle SLI properly. Among gamers I've often heard that it's 
a notoriously problematic configuration. Can you switch your card to non-SLI 
mode and retest performance?

--Chris


On 2015-10-30 09:19, Felix Bembrick wrote:
I am using Java 8u66 and performance is really poor.

I suspected a driver issue but I have the latest driver for my Titan X card (4 
in SLI mode) and running the 4K monitor tests in 3DMark says my machine is in 
the top 1% fastest computers ever to run the tests.

It looks to me that JavaFX just can't deliver acceptable performance on 4K 
monitors, even with the most powerful graphics cards on the planet. Or maybe it 
doesn't support SLI?

It could be Windows 10 related but I don't think so. And I am definitely 
getting hardware acceleration according to the output so I suspect JavaFX has 
trouble moving so many pixels around on these hi-res monitors.

All other 3D apps and games run blindingly fast but JavaFX actually runs slower 
on this beast than on my wife's little i5 powered Dell machine with a low range 
graphics card, also running Windows 10.

Any ideas?

Felix


On 30 Oct 2015, at 17:33, Chris Nahr wrote:

Hi-DPI is supported on Windows, assuming you have 8u60 or later (better 8u66 or 
later so a ComboBox doesn't freeze the application!). On my Dell XPS-15 with 
Windows 10 and 4K displays JavaFX also uses hardware acceleration, in this case 
with the Intel 4600 integrated GPU.

However, this causes frequent Intel display driver crashes and restarts because 
the Windows 10 drivers are still so immature. Same happens in WPF applications, 
so it's not specific to JavaFX. I've grabbed my driver directly from the Intel 
website. Possibly your system runs an older driver that causes JavaFX not to 
use HA.

Given how unstable it currently is on Windows 10, that might not be a bad idea. 
But of course you could try manually updating and see what happens to JavaFX 
performance.

Cheers, Chris



On 2015-10-28 17:24:38, Felix Bembrick  wrote:
I just installed JavaFX on my new Windows 10 machine which is extremely powerful but has 
two 4K monitors and while everything looks great and the right "size", the 
performance is very sluggish to say the least.

Is 

Re: Fx questions

[Dr. Michael Paus]

I have done so.

 (Review ID: 9068159) - JVM crashes when selecting video on youtube in 
WebView



Am 30.10.15 um 16:46 schrieb Alexander Kouznetsov:

Hi Michael,

Could you please file a bug on this?

Best regards,
Alexander Kouznetsov
(408) 276-0387

On 30 окт 2015 3:21, Dr. Michael Paus wrote:

This is good to know but I just gave it a try on my MacBookPro Retina
and it failed.

I opened the youtube start page and there was an add at the top
(from Porsche :-)) which indeed played a video. Cool!

But when I then clicked on the link to close the add java crashed
completely.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00014946489e, pid=4440, tid=87311
#
# JRE version: Java(TM) SE Runtime Environment (8.0_72-b05) (build 
1.8.0_72-ea-b05)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.72-b05 mixed mode 
bsd-amd64 compressed oops)

# Problematic frame:
# C  [libjfxmedia_avf.dylib+0x789e] 
_ZN18AVFKernelComponent18ProcessBufferListsERjRK15AudioBufferListRS1_j+0x22

#

Obviously I'm having sticky fingers or so because I always catch all 
bugs which are lurking arround.

Frustrating.



Am 30.10.15 um 10:37 schrieb John Maton:

JDK 8u72 (1.8.0_72-ea) makes a big difference here.
Using 8u66 I was not able to see any HTML5 videos on youtube, they 
all reverted to Flash.
8u72 makes it all work, last time I checked I was unable to find a 
video on youtube which did not work.

You can download 8u72 at https://jdk8.java.net/download.html
Best regards,
John Maton

On Fri, Oct 30, 2015 at 9:14 AM, Dr. Michael Paus <mailto:m...@jugs.org>> wrote:


Am 29.10.15 um 22:58 schrieb Brian Harris:

- when embedding html5 pages into fx apps, should we expect 
it to

render/behave similar to popular browsers like chrome? I'm
wondering if we
can expect this to just work or if things may be a bit wonky.

In theory it is just Webkit and as such it should behave like any
popular browser
and in many cases it does. However, I have stumbled over several
pages where
this is not the case and sometimes it even depends on the system
you are
running your application on. It may work on Windows but fail on a
Mac Retina.

Your best bet is to just give it a try with the pages that are
important for you
and see how it behaves.

Here are a few pages where I have problems with.

https://www.google.com/maps - (enters "Lite-Mode" because of
unsupported features.)

https://www.youtube.com - (I am not able to watch any video there.
Same on vimeo.)

https://www.windyty.com - (No wind trails on MacBook Pro Retina.)

(Tested with JDK 8u66-b17)

Re: Fx questions

[Dr. Michael Paus]

This is good to know but I just gave it a try on my MacBookPro Retina
and it failed.

I opened the youtube start page and there was an add at the top
(from Porsche :-)) which indeed played a video. Cool!

But when I then clicked on the link to close the add java crashed
completely.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00014946489e, pid=4440, tid=87311
#
# JRE version: Java(TM) SE Runtime Environment (8.0_72-b05) (build 
1.8.0_72-ea-b05)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.72-b05 mixed mode 
bsd-amd64 compressed oops)

# Problematic frame:
# C  [libjfxmedia_avf.dylib+0x789e] 
_ZN18AVFKernelComponent18ProcessBufferListsERjRK15AudioBufferListRS1_j+0x22

#

Obviously I'm having sticky fingers or so because I always catch all 
bugs which are lurking arround.

Frustrating.



Am 30.10.15 um 10:37 schrieb John Maton:

JDK 8u72 (1.8.0_72-ea) makes a big difference here.
Using 8u66 I was not able to see any HTML5 videos on youtube, they all 
reverted to Flash.
8u72 makes it all work, last time I checked I was unable to find a 
video on youtube which did not work.

You can download 8u72 at https://jdk8.java.net/download.html
Best regards,
John Maton

On Fri, Oct 30, 2015 at 9:14 AM, Dr. Michael Paus <mailto:m...@jugs.org>> wrote:


Am 29.10.15 um 22:58 schrieb Brian Harris:

- when embedding html5 pages into fx apps, should we expect it to
render/behave similar to popular browsers like chrome? I'm
wondering if we
can expect this to just work or if things may be a bit wonky.

In theory it is just Webkit and as such it should behave like any
popular browser
and in many cases it does. However, I have stumbled over several
pages where
this is not the case and sometimes it even depends on the system
you are
running your application on. It may work on Windows but fail on a
Mac Retina.

Your best bet is to just give it a try with the pages that are
important for you
and see how it behaves.

Here are a few pages where I have problems with.

https://www.google.com/maps - (enters "Lite-Mode" because of
unsupported features.)

https://www.youtube.com - (I am not able to watch any video there.
Same on vimeo.)

https://www.windyty.com - (No wind trails on MacBook Pro Retina.)

(Tested with JDK 8u66-b17)

Re: Fx questions

[Dr. Michael Paus]

Am 29.10.15 um 22:58 schrieb Brian Harris:

- when embedding html5 pages into fx apps, should we expect it to
render/behave similar to popular browsers like chrome? I'm wondering if we
can expect this to just work or if things may be a bit wonky.
In theory it is just Webkit and as such it should behave like any 
popular browser

and in many cases it does. However, I have stumbled over several pages where
this is not the case and sometimes it even depends on the system you are
running your application on. It may work on Windows but fail on a Mac 
Retina.


Your best bet is to just give it a try with the pages that are important 
for you

and see how it behaves.

Here are a few pages where I have problems with.

https://www.google.com/maps - (enters "Lite-Mode" because of unsupported 
features.)


https://www.youtube.com - (I am not able to watch any video there. Same 
on vimeo.)


https://www.windyty.com - (No wind trails on MacBook Pro Retina.)

(Tested with JDK 8u66-b17)

Re: Mac App Store Refusal because of QTKit API's

[Dr. Michael Paus]

Am 09.10.15 um 13:43 schrieb Scott Selvia:


So my question now, Is there a JavaFX application in the Mac OSx Store?

There still is the Ensemble 8 app in the OSX store. But it is already more
than a year old.


com.apple.security.temporary-exception.files.absolute-path.read-write

—>

Thanks,

Scott


On Oct 9, 2015, at 6:32 AM, Scott Selvia  wrote:

Same results…Apple just does not like API’s used within the JRE

October 8, 2015 at 9:10 PM
 From Apple
2.5 - Apps that use non-public APIs will be rejected
2.31 - Apps that are not sandboxed appropriately may be rejected
2.5

The use of non-public APIs can lead to a poor user experience should these APIs 
change in the future, and is therefore not permitted. The following non-public 
APIs are included in your application:

com.apple.security.temporary-exception.files.absolute-path.read-write: True

If you have defined methods in your source code with the same names as the 
above-mentioned APIs, we suggest altering your method names so that they no 
longer collide with Apple's private APIs to avoid your application being 
flagged in future submissions.

Additionally, one or more of the above-mentioned APIs may reside in a library included with your application. If you do 
not have access to the library's source, you may be able to search the compiled binary using "strings" or 
"otool" command line tools. The "strings" tool can output a list of the methods that the library 
calls and "otool -ov" will output the Objective-C class structures and their defined methods. These 
techniques can help you narrow down where the problematic code resides.

2.31

Your app incorrectly implements sandboxing, or it contains one or more 
entitlements with invalid values. Please review the included entitlements and 
sandboxing documentation and resolve this issues before resubmitting a new 
binary.

ubrk_getRuleStatus
ubrk_setUText
ucnv_getCanonicalName
ucnv_reset
ucol_strcollIter

For information on common app sandboxing issues, please see Technical Q&A QA1773 
Common app sandboxing issues 
.

See App Sandboxing  for 
links to essential video and documentation to learn how to sandbox your application.

As of June 1, 2012, apps must be sandboxed. New apps that are not sandboxed 
will be rejected. Updates to non-sandboxed apps may be submitted if they only 
addresses bug fixes and new OS X feature adoption provided that your app was on 
the Mac App Store prior to June 1st.

Should you need code-level assistance implementing sandboxing, contact Apple 
Developer Technical Support 
.

If you are unable to reproduce this issue, ensure you are testing the exact version of 
the app that you submitted for review, and that you're doing so in a minimally privileged 
environment. See Technical Q&A QA1778: How to reproduce bugs reported against Mac App 
Store submissions .

For information on how to symbolicate and read a crash log, please see Technical Note 
TN2123 - CrashReporter 
.

Here is my entitlements, so it must be somewhere, I just don’t know where:


http://www.apple.com/DTDs/PropertyList-1.0.dtd 
">


com.apple.security.app-sandbox
 
com.apple.security.files.user-selected.read-write
 





On Oct 2, 2015, at 2:36 PM, Scott Selvia mailto:ssel...@gmail.com>> wrote:

Chris,

The app is in "waiting for review" state again.  Last time it sat there for 
about 5 days then was rejected. Based on the app getting past the deprecated APIs issue I 
hope I will hear something soon. The bugs, I plan on updating them with a status note ??? 
This weekend.

I thinking Apple has some integration issues between OS X apps and iOS apps. My 
current bundle has a note the it does not include beta testing entitlement. 
From our understanding of the apple docs, that is for iOS apps only. We do not 
have that option enabled in iTunes connect

Scott

Sent from my iPhone


On Oct 2, 2015, at 1:53 PM, Chris Bensen mailto:chris.ben...@oracle.com>> wrote:

Hi Scott,

Let me know what happens with this because we are tracking it with two bugs on 
our end — one in the packager and one in WebKit. I’ve spoken with a couple 
friends at Apple and they don’t think it’s right either but none of them have 
control over the AppStore. At this point there’s really nothing we can do. With 
regards tot he CFBundleIndentifier collision, that’s another problem on their 
end as far as I can tell.

Thanks,
Chris



On Sep 30, 2015, at 3:41 PM, Scott Selvia mailto:ssel...@gmail.com>> wrote:

See you at JavaOne, hopefully I’ll have good results to pass along.

Again thanks to ALL, there are two Apple 

Smooth continuous scrolling in JavaFX

[Dr. Michael Paus]

I have a MacBook Pro with a touch enabled trackpad. When I open a large 
image with the Mac preview app I can let the image slide softly over the 
screen with a two finger gesture. Now I would like to do the same inside 
a JavaFX app but this doesn't seems to work. The image jumps in roughly 
10 pixel increments which just looks ugly. I experimented with the 
JavaFX gestures but I did not get it to move smoothly. The scroll events 
are always delivered in very coarse intervals in contrast to the zoom 
and rotation events where this works perfectly.


So I have the following questions here:

Is this behavior the same on all touch enabled platforms or is this a 
Mac issue?


Is there anything I can do to get more fine grained scroll events?

Why is there such a difference between the scroll and the other events 
(zoom, rotate)?


Is this a bug or a feature?

Michael

Re: Usage of Toolkit firePulse

[Dr. Michael Paus]

Hi,
I updated the file on dropbox with the additions made by Tomas.
Michael

Am 25.09.15 um 16:57 schrieb Anthony Vanelverdinghe:

Hi Michael

Would you mind to share your updated test program through dropbox please?

Kind regards
Anthony Vanelverdinghe

On 25/09/2015 11:24, Dr. Michael Paus wrote:

Hi,
this really works great and is in my opinion the best approach to ensure
a super smooth canvas update. So the trick is to spread the whole 
work over
several smaller chunks via Platform.runLater calls but instead of 
creating

all these chunks at once, one has to chain these in such a way that the
first call issues the next call at the end if there is still more 
work to do. This way

there is never more than one call in the queue and the pulses to update
the scene graph are not delayed. I think this may become a general 
pattern

of how to update a canvas with complex drawings.
Michael

Am 25.09.15 um 00:03 schrieb Tomas Mikula:

Hi Michael,

attached see your original file updated with the continuation-style 
solution.


Regards,
Tomas

On Thu, Sep 24, 2015 at 2:44 PM, Dr. Michael Paus <mailto:m...@jugs.org>> wrote:


I have written a little test program to evaluate the various
strategies which have
been discussed here. You can download it via this link:

<https://www.dropbox.com/s/vmg9nyn7pdfk4b1/SmoothButterflies.java?dl=0>

The program creates a large canvas inside a scroll pane and fills
it with some
butterflies. When you scroll the pane the canvas is redrawn when a
certain
threshold is exceeded. With some boolean flags at the top of the
program
you can select the redraw strategy.

This was just a quick and dirty hack, so I hope I haven't made any
mistakes
but the result so far is that only the AnimationTimer strategy
leads to a amazingly
smooth result. For all other strategies the scrolling performance
is terrible.
(I have not yet tried the proposal from Tomas.)

Give it a try yourself. The initial setting are for AnimationTimer.

Michael


Am 24.09.15 um 17:17 schrieb Kevin Rushforth:

Yes, I think this might be a better approach.

-- Kevin


Scott Palmer wrote:

For some of these use cases I wonder if an AnimationTimer
could be used to handle spreading work out.
E.g in the case of rendering to a canvas across multiple
pulses, do a bit at a time in the AnimationTimer’s
handle() method.

Scott

On Sep 24, 2015, at 5:53 AM, Fisher, Robert
mailto:robert.fisher@zeiss.com>> wrote:

I was naively thinking something like:

1. Make small change to canvas
2. Fire pulse
3. Make next small change to canvas
4. Fire pulse
5. Etc..

But I was actually also unaware of this firePulse
method until this morning (and I couldn't have used it
anyway since it's not public API).

-Original Message-
From: openjfx-dev
[mailto:openjfx-dev-boun...@openjdk.java.net
<mailto:openjfx-dev-boun...@openjdk.java.net>] On
Behalf Of Dr. Michael Paus
Sent: Donnerstag, 24. September 2015 11:07
To: openjfx-dev@openjdk.java.net
<mailto:openjfx-dev@openjdk.java.net>
Subject: Re: Usage of Toolkit firePulse

Hi,
I wasn't aware of this Toolkit method when I wrote the
mail you are referring to. Can you or anybody else
explain what this method exactly does. It sounds
indeed as if I could solve some problems with it
although I am not sure yet and of course only if
Jonathan does not block it in the future :-) Michael

Am 24.09.15 um 09:31 schrieb Fisher, Robert:

I think it would be great to have in the public
API. It looks like it would allow you to spread
large UI updates out over several pulses in a
well-defined way.

See also this post from a month or so ago:

Hi,
I want to do some performance tuning of a
JavaFX application of mine but before I can
start with that I have to learn a little bit
about the scene graph redraw handling.
Maybe there is someone on this list who can
help me there.

What I want to achieve is a super smooth
animation (movement) of my scene graph.
Let's assume the scene graph itself can be
redrawn 

Re: Usage of Toolkit firePulse

[Dr. Michael Paus]

Hi,
this really works great and is in my opinion the best approach to ensure
a super smooth canvas update. So the trick is to spread the whole work over
several smaller chunks via Platform.runLater calls but instead of creating
all these chunks at once, one has to chain these in such a way that the
first call issues the next call at the end if there is still more work 
to do. This way

there is never more than one call in the queue and the pulses to update
the scene graph are not delayed. I think this may become a general pattern
of how to update a canvas with complex drawings.
Michael

Am 25.09.15 um 00:03 schrieb Tomas Mikula:

Hi Michael,

attached see your original file updated with the continuation-style 
solution.


Regards,
Tomas

On Thu, Sep 24, 2015 at 2:44 PM, Dr. Michael Paus <mailto:m...@jugs.org>> wrote:


I have written a little test program to evaluate the various
strategies which have
been discussed here. You can download it via this link:

<https://www.dropbox.com/s/vmg9nyn7pdfk4b1/SmoothButterflies.java?dl=0>

The program creates a large canvas inside a scroll pane and fills
it with some
butterflies. When you scroll the pane the canvas is redrawn when a
certain
threshold is exceeded. With some boolean flags at the top of the
program
you can select the redraw strategy.

This was just a quick and dirty hack, so I hope I haven't made any
mistakes
but the result so far is that only the AnimationTimer strategy
leads to a amazingly
smooth result. For all other strategies the scrolling performance
is terrible.
(I have not yet tried the proposal from Tomas.)

Give it a try yourself. The initial setting are for AnimationTimer.

Michael


Am 24.09.15 um 17:17 schrieb Kevin Rushforth:

Yes, I think this might be a better approach.

-- Kevin


Scott Palmer wrote:

For some of these use cases I wonder if an AnimationTimer
could be used to handle spreading work out.
E.g in the case of rendering to a canvas across multiple
pulses, do a bit at a time in the AnimationTimer’s
handle() method.

Scott

On Sep 24, 2015, at 5:53 AM, Fisher, Robert
mailto:robert.fisher@zeiss.com>> wrote:

I was naively thinking something like:

1. Make small change to canvas
2. Fire pulse
3. Make next small change to canvas
4. Fire pulse
5. Etc..

But I was actually also unaware of this firePulse
method until this morning (and I couldn't have used it
anyway since it's not public API).

-Original Message-
From: openjfx-dev
[mailto:openjfx-dev-boun...@openjdk.java.net
<mailto:openjfx-dev-boun...@openjdk.java.net>] On
Behalf Of Dr. Michael Paus
Sent: Donnerstag, 24. September 2015 11:07
To: openjfx-dev@openjdk.java.net
<mailto:openjfx-dev@openjdk.java.net>
Subject: Re: Usage of Toolkit firePulse

Hi,
I wasn't aware of this Toolkit method when I wrote the
mail you are referring to. Can you or anybody else
explain what this method exactly does. It sounds
indeed as if I could solve some problems with it
although I am not sure yet and of course only if
Jonathan does not block it in the future :-) Michael

Am 24.09.15 um 09:31 schrieb Fisher, Robert:

I think it would be great to have in the public
API. It looks like it would allow you to spread
large UI updates out over several pulses in a
well-defined way.

See also this post from a month or so ago:

Hi,
I want to do some performance tuning of a
JavaFX application of mine but before I can
start with that I have to learn a little bit
about the scene graph redraw handling.
Maybe there is someone on this list who can
help me there.

What I want to achieve is a super smooth
animation (movement) of my scene graph.
Let's assume the scene graph itself can be
redrawn fast enough in less than 1/60s.
In addition let's assume the scene graph
contains a canvas which only has to be updated
from time to time but an update of the canvas
takes subs

Re: Usage of Toolkit firePulse

[Dr. Michael Paus]

I have written a little test program to evaluate the various strategies 
which have

been discussed here. You can download it via this link:

<https://www.dropbox.com/s/vmg9nyn7pdfk4b1/SmoothButterflies.java?dl=0>

The program creates a large canvas inside a scroll pane and fills it 
with some

butterflies. When you scroll the pane the canvas is redrawn when a certain
threshold is exceeded. With some boolean flags at the top of the program
you can select the redraw strategy.

This was just a quick and dirty hack, so I hope I haven't made any mistakes
but the result so far is that only the AnimationTimer strategy leads to 
a amazingly
smooth result. For all other strategies the scrolling performance is 
terrible.

(I have not yet tried the proposal from Tomas.)

Give it a try yourself. The initial setting are for AnimationTimer.

Michael


Am 24.09.15 um 17:17 schrieb Kevin Rushforth:

Yes, I think this might be a better approach.

-- Kevin


Scott Palmer wrote:
For some of these use cases I wonder if an AnimationTimer could be 
used to handle spreading work out.
E.g in the case of rendering to a canvas across multiple pulses, do a 
bit at a time in the AnimationTimer’s handle() method.


Scott

On Sep 24, 2015, at 5:53 AM, Fisher, Robert 
 wrote:


I was naively thinking something like:

1. Make small change to canvas
2. Fire pulse
3. Make next small change to canvas
4. Fire pulse
5. Etc..

But I was actually also unaware of this firePulse method until this 
morning (and I couldn't have used it anyway since it's not public API).


-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On 
Behalf Of Dr. Michael Paus

Sent: Donnerstag, 24. September 2015 11:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Usage of Toolkit firePulse

Hi,
I wasn't aware of this Toolkit method when I wrote the mail you are 
referring to. Can you or anybody else explain what this method 
exactly does. It sounds indeed as if I could solve some problems 
with it although I am not sure yet and of course only if Jonathan 
does not block it in the future :-) Michael


Am 24.09.15 um 09:31 schrieb Fisher, Robert:
I think it would be great to have in the public API. It looks like 
it would allow you to spread large UI updates out over several 
pulses in a well-defined way.


See also this post from a month or so ago:


Hi,
I want to do some performance tuning of a JavaFX application of 
mine but before I can start with that I have to learn a little bit 
about the scene graph redraw handling.

Maybe there is someone on this list who can help me there.

What I want to achieve is a super smooth animation (movement) of 
my scene graph.
Let's assume the scene graph itself can be redrawn fast enough in 
less than 1/60s.
In addition let's assume the scene graph contains a canvas which 
only has to be updated from time to time but an update of the 
canvas takes substantially longer.

Let's say it takes 1s.

When an update of the canvas is in progress will this delay the 
next pulse until all internal drawing within the canvas is 
finished? From my observations I think so.


If I submit my drawing calls to the canvas in smaller chunks via 
Platform.runLater calls will these also delay the next pulse or 
will the execution of these calls be delayed in favor of the scene 
graph update?


I hope my goal has become clear. I would like to be able to spread 
the update of the canvas over several scene graph redraw cycles so 
that an animation of the canvas stays smooth although the content 
builds up more slowly.


Michael

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On 
Behalf Of Jonathan Giles

Sent: Donnerstag, 24. September 2015 01:49
To: openjfx-dev@openjdk.java.net
Subject: Usage of Toolkit firePulse

Hi all,

Today I am keen to get your help on understanding use of the
Toolkit.getToolkit().firePulse() private API. If you could spare a 
few minutes to grep your source directory for any usage of 
'firePulse', and email me your findings, that would be really 
interesting.


As a gentle motivational tool I'll conclude by saying that, 
surprisingly, this private API is barely used inside the openjfx 
production code. If you look at the openjfx unit tests, it is used 
massively. The question is - how much is this being used by other 
community members. If the answer is 'not much' or less, then this 
private API may not be made public in JDK 9. Your feedback 
therefore is critical!


Thanks,
-- Jonathan

Re: Usage of Toolkit firePulse

[Dr. Michael Paus]

I also thought about using an AnimationTimer but I see a problem with 
the load balancing there.
If you do too much in the handle() method, then the pulses will be 
delayed but if you do not do enough,
your canvas update is unnecessarily stretched and you are wasting time. 
You would have a similar

problem with the firePulse() method.

Am 24.09.15 um 15:13 schrieb Scott Palmer:

For some of these use cases I wonder if an AnimationTimer could be used to 
handle spreading work out.
E.g in the case of rendering to a canvas across multiple pulses, do a bit at a 
time in the AnimationTimer’s handle() method.

Scott


On Sep 24, 2015, at 5:53 AM, Fisher, Robert  wrote:

I was naively thinking something like:

1. Make small change to canvas
2. Fire pulse
3. Make next small change to canvas
4. Fire pulse
5. Etc..

But I was actually also unaware of this firePulse method until this morning 
(and I couldn't have used it anyway since it's not public API).

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Dr. Michael Paus
Sent: Donnerstag, 24. September 2015 11:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Usage of Toolkit firePulse

Hi,
I wasn't aware of this Toolkit method when I wrote the mail you are referring 
to. Can you or anybody else explain what this method exactly does. It sounds 
indeed as if I could solve some problems with it although I am not sure yet and 
of course only if Jonathan does not block it in the future :-) Michael

Am 24.09.15 um 09:31 schrieb Fisher, Robert:

I think it would be great to have in the public API. It looks like it would 
allow you to spread large UI updates out over several pulses in a well-defined 
way.

See also this post from a month or so ago:


Hi,
I want to do some performance tuning of a JavaFX application of mine
but before I can start with that I have to learn a little bit about the scene 
graph redraw handling.
Maybe there is someone on this list who can help me there.

What I want to achieve is a super smooth animation (movement) of my scene graph.
Let's assume the scene graph itself can be redrawn fast enough in less than 
1/60s.
In addition let's assume the scene graph contains a canvas which only
has to be updated from time to time but an update of the canvas takes 
substantially longer.
Let's say it takes 1s.

When an update of the canvas is in progress will this delay the next
pulse until all internal drawing within the canvas is finished? From my 
observations I think so.

If I submit my drawing calls to the canvas in smaller chunks via
Platform.runLater calls will these also delay the next pulse or will
the execution of these calls be delayed in favor of the scene graph update?

I hope my goal has become clear. I would like to be able to spread
the update of the canvas over several scene graph redraw cycles so
that an animation of the canvas stays smooth although the content builds up 
more slowly.

Michael

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On
Behalf Of Jonathan Giles
Sent: Donnerstag, 24. September 2015 01:49
To: openjfx-dev@openjdk.java.net
Subject: Usage of Toolkit firePulse

Hi all,

Today I am keen to get your help on understanding use of the
Toolkit.getToolkit().firePulse() private API. If you could spare a few minutes 
to grep your source directory for any usage of 'firePulse', and email me your 
findings, that would be really interesting.

As a gentle motivational tool I'll conclude by saying that, surprisingly, this 
private API is barely used inside the openjfx production code. If you look at 
the openjfx unit tests, it is used massively. The question is - how much is 
this being used by other community members. If the answer is 'not much' or 
less, then this private API may not be made public in JDK 9. Your feedback 
therefore is critical!

Thanks,
-- Jonathan

Re: Usage of Toolkit firePulse

[Dr. Michael Paus]

Hi,
I wasn't aware of this Toolkit method when I wrote the mail you are 
referring to. Can you or anybody
else explain what this method exactly does. It sounds indeed as if I 
could solve some problems with
it although I am not sure yet and of course only if Jonathan does not 
block it in the future :-)

Michael

Am 24.09.15 um 09:31 schrieb Fisher, Robert:

I think it would be great to have in the public API. It looks like it would 
allow you to spread large UI updates out over several pulses in a well-defined 
way.

See also this post from a month or so ago:


Hi,
I want to do some performance tuning of a JavaFX application of mine but before
I can start with that I have to learn a little bit about the scene graph redraw 
handling.
Maybe there is someone on this list who can help me there.

What I want to achieve is a super smooth animation (movement) of my scene graph.
Let's assume the scene graph itself can be redrawn fast enough in less than 
1/60s.
In addition let's assume the scene graph contains a canvas which only has to be 
updated from
time to time but an update of the canvas takes substantially longer.
Let's say it takes 1s.

When an update of the canvas is in progress will this delay the next pulse 
until all internal
drawing within the canvas is finished? From my observations I think so.

If I submit my drawing calls to the canvas in smaller chunks via 
Platform.runLater calls will
these also delay the next pulse or will the execution of these calls be delayed 
in favor of the
scene graph update?

I hope my goal has become clear. I would like to be able to spread the update 
of the canvas over
several scene graph redraw cycles so that an animation of the canvas stays 
smooth although the
content builds up more slowly.

Michael


-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Jonathan Giles
Sent: Donnerstag, 24. September 2015 01:49
To: openjfx-dev@openjdk.java.net
Subject: Usage of Toolkit firePulse

Hi all,

Today I am keen to get your help on understanding use of the
Toolkit.getToolkit().firePulse() private API. If you could spare a few minutes 
to grep your source directory for any usage of 'firePulse', and email me your 
findings, that would be really interesting.

As a gentle motivational tool I'll conclude by saying that, surprisingly, this 
private API is barely used inside the openjfx production code. If you look at 
the openjfx unit tests, it is used massively. The question is - how much is 
this being used by other community members. If the answer is 'not much' or 
less, then this private API may not be made public in JDK 9. Your feedback 
therefore is critical!

Thanks,
-- Jonathan

Internal scene graph redraw handling

[Dr. Michael Paus]

Hi,
I want to do some performance tuning of a JavaFX application of mine but 
before
I can start with that I have to learn a little bit about the scene graph 
redraw handling.

Maybe there is someone on this list who can help me there.

What I want to achieve is a super smooth animation (movement) of my 
scene graph.
Let's assume the scene graph itself can be redrawn fast enough in less 
than 1/60s.
In addition let's assume the scene graph contains a canvas which only 
has to be
updated from time to time but an update of the canvas takes 
substantially longer.

Let's say it takes 1s.

When an update of the canvas is in progress will this delay the next 
pulse until all
internal drawing within the canvas is finished? From my observations I 
think so.


If I submit my drawing calls to the canvas in smaller chunks via 
Platform.runLater
calls will these also delay the next pulse or will the execution of 
these calls be

delayed in favor of the scene graph update?

I hope my goal has become clear. I would like to be able to spread the 
update of
the canvas over several scene graph redraw cycles so that an animation 
of the

canvas stays smooth although the content builds up more slowly.

Michael

Re: OpenGLNode or NativeSurfaceNode

[Dr. Michael Paus]

Am 08.09.15 um 07:45 schrieb Edu García:

So, years ago somebody asked on this list if it was possible to have some
sort of OpenGL or NativeSurface node, to be able to integrate OpenGL or
DirectX rendering on top of JavaFX (in my case, to embed something like
LibGDX).

Has any work been done on this at all? If it hasn't, are there any plans to
support this in the near future? If both answers are negative, is there any
way of using heavyweight Swing controls on top of JavaFX?

Thanks.

I assume you are aware of this discussion/bug report.


Michael

Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats

[Dr. Michael Paus]

Am 27.08.15 um 13:18 schrieb Kirill Kirichenko:

On 27.08.2015 9:29, Dr. Michael Paus wrote:

To me this sounds again like a Java/JavaFX specific solution which, to
my opinion, is a dead-end road. I think it would be much more important
that JavaFX can directly use all system installed codecs. I simply don't
understand why it is possible to install a codec pack on a machine and
almost all software, with the exception of JavaFX, is able to
immediately use that and only JavaFX based applications are not.


Although this is an off-topic I'll answer to your question.

Security and testing are the reasons.
It's virtually impossible to test every possible codec on every 
possible platform. Many of them are proprietary so we don't control 
their code/can't fix their bugs. And all blame that JavaFX can't play 
this/can't play that will fall on our heads.

And it can open many potential security vulnerabilities.
1. Why do you consider my comment off-topic? It's a direct response to a 
statement made by Scott Palmer.


2. Why do you want to control other peoples code? Actually, if you were 
just using the system APIs it should
be completely transparent to you whether the user has installed 
additional codecs on his system or not.


3. How do you explain to your customers that a JavaFX-based application 
cannot even play a .mov file on a

Mac whereas every other media-aware application can?

Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats

[Dr. Michael Paus]

Am 26.08.15 um 22:25 schrieb Scott Palmer:


Then legacy formats could be provided in optional downloads and new formats can 
be supported without the need to integrate them within the JRE code.


To me this sounds again like a Java/JavaFX specific solution which, to 
my opinion, is a dead-end road. I think it would be much more important 
that JavaFX can directly use all system installed codecs. I simply don't 
understand why it is possible to install a codec pack on a machine and 
almost all software, with the exception of JavaFX, is able to 
immediately use that and only JavaFX based applications are not.


Michael

Google Maps and WebView on Retina Mac

[Dr. Michael Paus]

I just ran Google Maps inside a JavaFX WebView and was a bit shocked
when I saw how blurry the display was compared to the display of any
other browser on my MacBook Pro Retina. The other browsers seem to
correctly report the system screen resolution to the server so that it
can serve high resolution tiles for the map display and WebView
obviously does not. Is there anything that could be done about this?

Re: Windows support for HiDPI displays, call for feedback and testing

[Dr. Michael Paus]

Hi Jim

let me answer your last questions first.

> Just to be sure I understood that last paragraph correctly
> - adding a ColorAdjust to a group of ImageViews makes it slow down on 
8u60, but not on 8u40.


Yes, but I was not able to reproduce that behavior in a simple example. 
Otherwise I would have written an official bug report already.


> Having the same group without the ColorAdjust does not affect 
performance between 8u40 and 8u60.


Yes.

> Setting the cache hints on the group slows it down on 8u60, but not 8u40.

No. Setting group.setCache(true) also fixes the problem. So I currently 
have too options on the Mac.
Either eliminate the ColorAdjust effect OR setCache(true). The first one 
is no real option because
I need the functionality and the second seemed to be a waste of memory 
to me and was not needed

until now.

Now to your other questions. There was typo in my mail. Of course I 
wanted to say "Screen.getRenderScale"

and not "System...". (I know this is private but read on ...)

If I understand you correctly you are saying that all this 
HiDPI-handling is done under the covers and should
be fully transparent to the programmer, whereas I think that this is not 
possible for non-trivial cases.

(Is this foo. versus foo@2x. handling documented anywhere?)

Just a few questions:

How do you determine which images to download from a server or database 
if you don't know the render scale?


How do you handle cases where your images are read from a stream where 
you do not have a @2x name extension?

(Same for other non-named image sources.)

How do you draw thin (single pixel wide) lines if you don't know the 
render scale?


How do you display an image at exactly 100% scale (like the option in 
Photoshop for example) if you don't know the render scale?


How do you take a snapshot of a node at full resolution? For example a 
500x500 canvas will be internally backed by a 1000x1000
image which looks crisp on your Retina screen. When you now take a 
snapshot of this canvas it will be a blurry 500x500 image.

(At least that was the result when I last tried it.)

There are workarounds for all these issues but only if you know the 
render scale.


Michael


Am 10.06.15 um 00:19 schrieb Jim Graham:

Hi Michael,

I'm not sure I understand the problem you were having with 
getRenderScale.


What is "System.getRenderScale()"?  Where are you getting that from?

What is the tile cache and why was it affected by the hidden scale 
that we have been intending to not affect applications in any way 
(other than what the user can see visually on the screen)?  Is this 
something you implement in your code?


Since we apply the render scale under the covers it shouldn't matter 
what size your images are - they should be displayed scaled by the 
render scale.  The only "scaling" that affects images is if you 
request foo. and we find a foo@2x. then we will load 
it and internally downscale it by 2x when we render it, but that 
should be the same on both Mac and Windows.


Just to be sure I understood that last paragraph correctly - adding a 
ColorAdjust to a group of ImageViews makes it slow down on 8u60, but 
not on 8u40.  Having the same group without the ColorAdjust does not 
affect performance between 8u40 and 8u60. Setting the cache hints on 
the group slows it down on 8u60, but not 8u40.  Did I get all of that 
correctly?


...jim

On 6/9/2015 12:45 PM, Dr. Michael Paus wrote:

Hi
I finally managed to set up a non-retina Windows 7 box and
get my software running on it. I tried it with JDK 8u45 and 8u60b18.

It worked with 8u45 out of the box and the performance was ok.

With 8u60 the whole application seemed to be broken because all
tiles where displayed at only half their normal size. The reason for 
this

was that the system suddenly behaves like a retina device and
System.getRenderScale returns 2.0 instead of 1.0 as before.
This problem was easy to fix though because I just had to erase
the tile cache manually. The decision to download retina tiles
(512x512) or normal tiles (256x256) is based on this factor.
I did not expect such a change between runs of the software.

After fixing this issue the application behaved in the same way
as with 8u45. So a semi-retina :-) Windows box does not seem to
suffer from the performance drop.

But there is something else I observed on the Mac. I found out
that the performance drop seems to be triggered by an effect
that I have added to the group containing all the ImageViews.
Its a ColorAdjust effect which I used to control the brightness
of the map. As soon as I remove it from the group the performance
is ok again. Something else that has the same effect is to activate
the caching of the group but I wonder why that was not necessary
before.

But again I failed to create some simple example to show this
effect. It drives me nuts.

Michael

PS: I also tried the options proposed b

Re: Windows support for HiDPI displays, call for feedback and testing

[Dr. Michael Paus]

Hi
I finally managed to set up a non-retina Windows 7 box and
get my software running on it. I tried it with JDK 8u45 and 8u60b18.

It worked with 8u45 out of the box and the performance was ok.

With 8u60 the whole application seemed to be broken because all
tiles where displayed at only half their normal size. The reason for this
was that the system suddenly behaves like a retina device and
System.getRenderScale returns 2.0 instead of 1.0 as before.
This problem was easy to fix though because I just had to erase
the tile cache manually. The decision to download retina tiles
(512x512) or normal tiles (256x256) is based on this factor.
I did not expect such a change between runs of the software.

After fixing this issue the application behaved in the same way
as with 8u45. So a semi-retina :-) Windows box does not seem to
suffer from the performance drop.

But there is something else I observed on the Mac. I found out
that the performance drop seems to be triggered by an effect
that I have added to the group containing all the ImageViews.
Its a ColorAdjust effect which I used to control the brightness
of the map. As soon as I remove it from the group the performance
is ok again. Something else that has the same effect is to activate
the caching of the group but I wonder why that was not necessary
before.

But again I failed to create some simple example to show this
effect. It drives me nuts.

Michael

PS: I also tried the options proposed by Kevin but they did not change 
anything

and the output suggest that I am not using too much vram.


Am 08.06.15 um 20:33 schrieb Jim Graham:
The only thing that might affect this was the change in the default 
size of the vram pool, but that happened in 8u40 which predates both 
of the builds involved in the experiment.  I'd be curious as well to 
hear how the application is affected on non-retina screens, and 
Windows/D3D for that matter...


...jim

On 6/8/15 5:42 AM, Kevin Rushforth wrote:

Does the same slowdown happen on a non-Retina system?

How large is your image? How large are the individual tiles? One thing
that occurs to me is that your application might be thrashing texture
memory (although I can't think of anything that changed in 8u60 that
would affect this). You might try the following debug flag:

java -Dprism.poolstats=true

and see if there is a lot of thrashing of texture memory. Also, you can
increase the memory that will be used for textures to, say, 1Gbyte
(default is 512Mbytes) by:

java -Dprism.maxvram=1g

and see if that makes a difference. Jim might have additional 
suggestions.


-- Kevin


Dr. Michael Paus wrote:

Many thanks for the clarification.

I'd also like to be more specific on the performance drop I observed
but I have to
admit that I don't have any idea what is going on there. The only
thing I can say
for sure is that I can consistently reproduce this drop in performance
by switching
between 8u45 and 8u60 (tested with b08 and b15).

My application contains a map view (something similar to Google Maps)
which
displays an area of retina map tiles. By dragging with the mouse I can
move this
map around within the map pane. This works smoothly with 8u45 but is
completely
shaky with 8u60. I even experimented with various techniques to
implement such
a map view (single large image, single large canvas, individual
images/canvases for
each map tile) and they all show the same behavior, so it cannot be
something which
is specific to a particular implementation approach. During my test
all tiles where already
cached in memory, so I can exclude any file or network IO related 
issues.


I tried to implement a little example where I just move around a large
image but in
this simple scenario the problem does not show up.

So in order to do a bit more precise measuring I added an
AnimationTimer to my map pane
which I use to compute a new position of the map for each frame so
that a point on the map
moves along a circle. This helps to show the performance drop more
precisely than moving
around the map by hand. This is a smooth movement with 8u45 but shaky
with 8u60.

But one other observation puzzles me completely. The handle-method of
the timer is called with
a frame rate of 60 Hz even though the graphics output is shaky and has
a visual frame rate
of something between 2 - 5 Hz. It is new to me that something like
this is technically possible.
It looks as if the system is running at full speed but skips
displaying most of the generated
frames for some reason. Is such a behavior possible at all?

Am 05.06.15 um 22:49 schrieb Jim Graham:

I actually use a retina MBP for testing - dual booting Windows and
MacOS.

There should be no changes at all on other platforms, particularly in
regard to rendering speed.  There was one small regression on Linux
resulting in a bad first paint due to asynchronous initialization of
the Window size, but no performance issues.  Can you be more specific
about where you see the perform

Re: Windows support for HiDPI displays, call for feedback and testing

[Dr. Michael Paus]

Many thanks for the clarification.

I'd also like to be more specific on the performance drop I observed but 
I have to
admit that I don't have any idea what is going on there. The only thing 
I can say
for sure is that I can consistently reproduce this drop in performance 
by switching

between 8u45 and 8u60 (tested with b08 and b15).

My application contains a map view (something similar to Google Maps) which
displays an area of retina map tiles. By dragging with the mouse I can 
move this
map around within the map pane. This works smoothly with 8u45 but is 
completely
shaky with 8u60. I even experimented with various techniques to 
implement such
a map view (single large image, single large canvas, individual 
images/canvases for
each map tile) and they all show the same behavior, so it cannot be 
something which
is specific to a particular implementation approach. During my test all 
tiles where already

cached in memory, so I can exclude any file or network IO related issues.

I tried to implement a little example where I just move around a large 
image but in

this simple scenario the problem does not show up.

So in order to do a bit more precise measuring I added an AnimationTimer 
to my map pane
which I use to compute a new position of the map for each frame so that 
a point on the map
moves along a circle. This helps to show the performance drop more 
precisely than moving
around the map by hand. This is a smooth movement with 8u45 but shaky 
with 8u60.


But one other observation puzzles me completely. The handle-method of 
the timer is called with
a frame rate of 60 Hz even though the graphics output is shaky and has a 
visual frame rate
of something between 2 - 5 Hz. It is new to me that something like this 
is technically possible.
It looks as if the system is running at full speed but skips displaying 
most of the generated

frames for some reason. Is such a behavior possible at all?

Am 05.06.15 um 22:49 schrieb Jim Graham:

I actually use a retina MBP for testing - dual booting Windows and MacOS.

There should be no changes at all on other platforms, particularly in 
regard to rendering speed.  There was one small regression on Linux 
resulting in a bad first paint due to asynchronous initialization of 
the Window size, but no performance issues.  Can you be more specific 
about where you see the performance drop? What kind of scene 
graph/animation?


The system properties are all Windows specific, thus the "glass.win" 
prefix.  In 9 we might generalize all of the HiDPI support and offer 
something more centralized, but those are just there for testing the 
new Windows support for now.  We'll also look at how to advertise the 
pixel scaling to applications at that time.


One thing to note is that the way that Mac retina support is done, if 
the user ever sets their control panel to anything other than "just 
pick the best conditions for this display" then there is pixel-scaling 
going on behind the scenes in the OS, so any attempts to try to line 
up with pixels will be muddied by the virtual DPI they are emulating 
at the system level.  We'll also be looking at ways to bypass their 
built-in "virtualized" HiDPI support in a later release so that we can 
actually talk directly to display pixels regardless of CP settings.


This virtualized scaling is mitigated by the fact that this HiDPI 
pixel stretching is happening on a HiDPI display and so any linear 
interpolation is hidden by tiny pixel sizes.


To that end, we are doing something similar with Windows scaling. 
There are a number of places in the FX code that assume that it can 
predict an integer translation from the FX code and so we always 
render at integer scales so that integers in FX Scene coordinates map 
to integers in rendered pixel coordinates.  We'll try to fix those in 
9 so that we can do non-integer scaling, but until then there will be 
the same disconnect between trying to line up with display pixels and 
the actions of HiDPI as Mac OS already has...


...jim

On 6/5/15 3:03 AM, Dr. Michael Paus wrote:

I cannot provide any Windows specific feedback on HiDPI displays because
I don't own one but I am working on a MacBook Pro with Retina display
and thus would like to ask a few questions in this context.

How are other platforms (Mac, Linux) affected by the changes you made
for the Windows support? (On my Mac I noticed a severe performance drop
when using 8u60 which may possibly be related to these changes.)

Are any of the special system properties you mentioned also usable on
other platforms?

Is there any way now to find out what the current pixel scale factor is?
Without that knowledge it is impossible to do proper graphics on any
HiDPI screen. (E.g., you can't position graphic elements correctly in
order to get crisp lines or you can't get a crisp snapshot of a node if
you don't take special actions based on the pixel scale.)

Re: Understanding the com.sun.* APIs being (ab)used by the community

[Dr. Michael Paus]

I promise to ditch that code as soon as there is a viable alternative. :-)

Am 05.06.15 um 17:28 schrieb Kevin Rushforth:

Yes, this will still work, although dipping into non-public state
continues to be something we wouldn't recommend that an application
rely on...

-- Kevin


Dr. Michael Paus wrote:

As nobody has stated it explicitly so far I would like to ask what
will happen
to classes in Java9 which access methods that are within the javafx
namespace but
are declared private? Will code like this still work or not?

public static double getPixelScale(Screen screen) throws
NoSuchMethodException, SecurityException, IllegalAccessException,
IllegalArgumentException, InvocationTargetException {
Method m = Screen.class.getDeclaredMethod("getScale");
m.setAccessible(true);
return ((Float) m.invoke(screen)).doubleValue();
}

This hack for example is currently necessary because there is no
other way to get at
the current pixel scale of a HiDPI screen.

Windows support for HiDPI displays, call for feedback and testing

[Dr. Michael Paus]

I cannot provide any Windows specific feedback on HiDPI displays because
I don't own one but I am working on a MacBook Pro with Retina display 
and thus would like to ask a few questions in this context.


How are other platforms (Mac, Linux) affected by the changes you made 
for the Windows support? (On my Mac I noticed a severe performance drop 
when using 8u60 which may possibly be related to these changes.)


Are any of the special system properties you mentioned also usable on 
other platforms?


Is there any way now to find out what the current pixel scale factor is?
Without that knowledge it is impossible to do proper graphics on any 
HiDPI screen. (E.g., you can't position graphic elements correctly in 
order to get crisp lines or you can't get a crisp snapshot of a node if 
you don't take special actions based on the pixel scale.)

Understanding the com.sun.* APIs being (ab)used by the community

[Dr. Michael Paus]

As nobody has stated it explicitly so far I would like to ask what will 
happen
to classes in Java9 which access methods that are within the javafx 
namespace but

are declared private? Will code like this still work or not?

public static double getPixelScale(Screen screen) throws 
NoSuchMethodException, SecurityException, IllegalAccessException, 
IllegalArgumentException, InvocationTargetException {

Method m = Screen.class.getDeclaredMethod("getScale");
m.setAccessible(true);
return ((Float) m.invoke(screen)).doubleValue();
}

This hack for example is currently necessary because there is no other 
way to get at

the current pixel scale of a HiDPI screen.

Re: Canvas blowing up (was Re: JavaFX Media issues)

[Dr. Michael Paus]

What would be the performance penalty for using this quick-fix? The 
clear/fill commands do not
just clear the command buffer. They also fill the canvas area with a 
certain color. So in normal

operation the canvas is always filled twice for each frame, isn't it?


Am 09.08.13 17:23, schrieb Richard Bair:

I mean, it looks like it is working for a few seconds,
but then as the memory fills with the Canvas backlog it can lead to the GC
using a lot more CPU, thus reducing the ability for Canvas to process its
command queue even further, well it just collapses in on itself  and dies.

Forking the thread.

The problem with Canvas is that if you have a canvas and you scribble on it, 
and then scribble on it some more, and then scribble on it some more, then in 
order for us to get the right result in the end, we need to replay all those 
scribbles in order. If pulses are not happening, we still need to remember 
these scribbles so we can draw the right result.

BUT, if you issue a command to the canvas which will cause it to "clear" all 
its contents, then we could throw away any previously buffered data. Right now the only 
way to do that would be a fillRect with a solid fill where the fillRect encompasses the 
entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area.

This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should 
both (under the right conditions) throw away the previously buffered commands. Then all you have to 
do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll 
never buffer more than a single frame's worth of data. We could also add a "clear" method 
which is "clearRect(0, 0, w, h)" to make this more foolproof, and then document it as a 
best practice to clear the canvas before each rendering if you intend to redraw the entire thing on 
each frame.

If you're making use of manually operated "dirty rects" so that you only clear the 
damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till 
kingdom come. So we still need a mechanism exposed in the scene graph of "liveness" and 
associated events so that when the scene is no longer live (for example, when minimized) you could 
stop your animation timer, but for your specific media use case this isn't as important.

Richard

Re: Mixing 2D and 3D

[Dr. Michael Paus]

Am 23.07.13 02:19, schrieb Richard Bair:

Alea iacta est!

I guess so, Google translate failed me though so I'm not sure :-D


http://en.wikipedia.org/wiki/Alea_iacta_est

" The phrase is still used today to mean that events have passed a point 
of no return, that something inevitably will happen."


Just in order to avoid misinterpretations :-)

Michael

Re: JavaFX graphics performance and suitability for advanced animations

[Dr. Michael Paus]

On 31.05.13 23:35, Richard Bair wrote:

We should start simple and work our way up. Since we've spent most of our time 
working on raw frame rates, perhaps it would be best to face down the jitter 
problem first. Lets start with something simple: a basic translate transition 
of a rectangle, and see how that goes.


Hi,
I'd like to add a very similar problem - a translate transition of a 
simple image.

This is something you see very often in animation examples but although the
JavaFX problem associated with this has already been reported many years ago
(on monday it will be exactly 3 years) this has not been fixed until now.
(I just checked it with JDK8 b92) My original report
 was marked as a duplicate,
although I am still not sure it really is but I can't check this because 
the explanation

of the possible reason in RT-6933 is kept secret.

Anyway - you still can't animate images smoothly with JavaFX out of the box
because although the image itself is placed at sub-pixel positions the 
border
of the image is clipped to exact pixel boundaries which makes the 
animation look bad.


I have attached code to show this. You can also switch between a smooth 
and a

non-smooth animation by clicking into the image with the mouse. When you
click into the image I apply a little hack so the animation becomes 
smooth. But
one should not be forced to use such tricks with a framework like JavaFX 
in order

to get a smooth animation for such a trivial use case.

Here comes the code: (You can use the image from the original bug report)


package bugs.smoothness;

import java.awt.image.BufferedImage;
import java.io.IOException;
import java.io.InputStream;

import javafx.animation.Animation;
import javafx.animation.Interpolator;
import javafx.animation.TranslateTransition;
import javafx.application.Application;
import javafx.embed.swing.SwingFXUtils;
import javafx.event.EventHandler;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.image.Image;
import javafx.scene.image.ImageView;
import javafx.scene.input.MouseEvent;
import javafx.scene.paint.Color;
import javafx.stage.Stage;
import javafx.util.Duration;

import javax.imageio.ImageIO;

public class ImageAnimation extends Application {
private static final String INPUT_IMAGE = "image1.jpg";

private static final double WIDTH = 1024;
private static final double HEIGHT = 768;

private static final Duration DURATION = Duration.millis(10);

private Image image1;
private Image image2;

private ImageView imageView;

private TranslateTransition moveAnim;

private Stage currentStage;

public Image createImage(String relFilePath, boolean smooth) {
InputStream is = getClass().getResourceAsStream(relFilePath);
Image image = null;

if (smooth) {
try {
BufferedImage i1 = ImageIO.read(is);

BufferedImage i2 = new BufferedImage(i1.getWidth()+2, 
i1.getHeight()+2, BufferedImage.TYPE_INT_ARGB);
i2.getGraphics().drawImage(i1, 1, 1, new 
java.awt.Color(0, 0, 0, 0), null);


image = SwingFXUtils.toFXImage(i2, null);
} catch (IOException e1) {
e1.printStackTrace();
}
} else {
image = new Image(is);
}

if (image != null && !image.isError()) {
return image;
} else {
System.err.println("Could not open " + relFilePath);
return null;
}
}

public void adjustStageTitle() {
if (imageView.getImage() == image1) {
currentStage.setTitle("image1 - standard border");
} else {
currentStage.setTitle("image2 - one pixel transparent border");
}
}

@Override public void start(Stage stage) {
System.out.println("javafx.runtime.version: " + 
System.getProperties().get("javafx.runtime.version"));


currentStage = stage;

image1 = createImage(INPUT_IMAGE, false);
image2 = createImage(INPUT_IMAGE, true);

imageView = new ImageView(image1);
imageView.setSmooth(true);
imageView.addEventHandler(MouseEvent.MOUSE_CLICKED, new 
EventHandler() {

@Override
public void handle(MouseEvent event) {
Image currentImage = imageView.getImage();
if (currentImage == image1) {
imageView.setImage(image2);
} else {
imageView.setImage(image1);
}
adjustStageTitle();
}
});

Group root = new Group();
root.getChildren().add(imageView);

// create scene
Scene scene = new Scene(root, WIDTH, HEIGHT);
scene.setFill(Color.LIGHTGRAY);

stage.setScene(scene);

adjustStageTitle();

// show stage
s