Re: Proposed fix for JDK-8170972

2016-12-09 Thread Jonathan Giles
Thanks for sending in this patch - I have attached it to the jira issue on your behalf. -- Jonathan On 9/12/16 8:44 AM, Itai wrote: It seems to me the source of the problem is line 466 in com.sun.javafx.util.Utils: //TODO - testing for an instance of Stage seems wrong but works

[9] Review request for 8170938: Memory leak in JavaFX WebView

2016-12-09 Thread Murali Billa
  Hi Kevin, Arun, Guru Please review the simple fix for JDK-8170938. JIRA: https://bugs.openjdk.java.net/browse/JDK-8170938 Webrev: http://cr.openjdk.java.net/~mbilla/8170938/webrev.00/   Thanks, Murali

Re: [9] Review request: JDK-8170030 Code in Marlin-based rasterizers may have an off-by-1 bug

2016-12-09 Thread Jim Graham
Hi Laurent, Normally we'd isolate fixes for different bugs even if they are just preparatory formatting changes on comments. Some comments on the formatting changes: line 35 - you should also upper-case the E line 148 - I don't understand why this "float" was a formatting danger, but the one

Re: Planning for JavaFX.next

2016-12-09 Thread Felix Bembrick
I think what Abu says here is a good concept to apply more "globally". I believe there should be a way to get access to the native APIs or contexts "in general" across all of the main JavaFX features (such as the OpenGL context etc.), just in case you find yourself in a situation where the

[9] Review request: JDK-8170030 Code in Marlin-based rasterizers may have an off-by-1 bug

2016-12-09 Thread Laurent Bourgès
Please review this simple fix for MarlinFX: JBS: https://bugs.openjdk.java.net/browse/JDK-8170030 webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8170030.0/ PS: I will provide asap a Marlin2D patch incorporating changes made in MarlinFX (including this one) Cheers, Laurent

Proposed fix for JDK-8170972

2016-12-09 Thread Itai
It seems to me the source of the problem is line 466 in com.sun.javafx.util.Utils: //TODO - testing for an instance of Stage seems wrong but works for menus if (scene.getWindow() instanceof Stage) { layoutX = layoutX + parentBounds.getWidth() - anchorWidth;

Planning for JavaFX.next

2016-12-09 Thread Wolfgang Zitzelsberger
Hi, new features are pretty welcome. +1 Public APIs for UI control behaviors, very important on the desktop to support keyboard shortcuts properly, maybe some Action/InputMap too +1 Focus traversal API +1 A JavaFX equivalent of the AWT Desktop APIs +1 CSS performance +1 CSS animations +1 Any

[9] Review request for 8166414: Scene returns incorrect coordinates

2016-12-09 Thread Semyon Sadetsky
Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8166414 webrev: http://cr.openjdk.java.net/~ssadetsky/8166414/webrev.00/ According to GTK iib documentation on X11 WMs the gtk_window_get_position() function doesn't return the exact window

Re: Planning for JavaFX.next

2016-12-09 Thread Abu Abdullah
- RTSP support for MediaPlayer - expose gstreamer API for public that allows you to build the pipeline yourself

RE: Planning for JavaFX.next

2016-12-09 Thread Markus KARG
+1 for CSS performance Also I would sing and dance if some fine day the following *smaller* features would finally make using FXML really fun: * Complete FXML binding syntax (JDK-8088368 [Support for Hash-Operator], JDK-8132450 [Custom Conversions in FXML], JDK-8137089) * More bindings

[9] Review request: JDK-8170979: Update for Jigsaw etc. the openFX functional tests

2016-12-09 Thread Yuri Nesterenko
Colleagues, please review this test bug fix: http://cr.openjdk.java.net/~yan/8170979/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8170979 The changes are mostly in tests/functional/. This is a merge of current testbase in http://hg.openjdk.java.net/openjfx/9-dev/tests and whatever

Re: Planning for JavaFX.next

2016-12-09 Thread Felix Bembrick
Rather than a "GLNode", I'm a strong advocate for a more API-agnostic "3D Canvas Node", given that JavaFX supports both OpenGL and Direct 3D currently (and one would expert Vulkan as well in the longer run). But such a node type is IMHO absolutely critical for JavaFX and, for me, is the most

Re: Planning for JavaFX.next

2016-12-09 Thread Nikos132
Hi again, I really miss a way to reuse all the OpenGL (jogamp) code developed for many years. A kind of GLNode would be nice, and maybe the jogamp community could be ready to contribute? Erik De Rijcke's answer really speaks to me since I've experienced very poor performances with the basic

Re: Planning for JavaFX.next

2016-12-09 Thread Tom Eugelink
Well, a lot of people already have made suggestions. For me the focus-lost issue is a very important thing. But more exotic is the easy data entry; this is something that for administrative applications is a real gain (and where is Java used a lot?). I had to hammer JTable into obedience to

Re: Planning for JavaFX.next

2016-12-09 Thread Laurent Bourgès
Hi, I would like to promote performance & quality improvements on the rasterizer that I could do in jdk10 within a tiger team focused on fx rendering: - multithreaded rendering (Marlin is thread-safe) ie the javafx could do parallel rendering of layers or shapes - software rasterizers: optimize

Re: Planning for JavaFX.next

2016-12-09 Thread Matthieu BROUILLARD
Hi Folks, for us in my company I would said the most important topics are related to performances: * CSS performances * TableView performances * ensure correctness, including memory leaks, of software-rendering pipeline (lot of our customers use Citrix farms with no GPU acceleration) for