Fwd: JavaFx roadmap?
Classic, forgot to post to list. -- Forwarded message -- From: Robert Krüger krue...@lesspain.de Date: Thu, Aug 14, 2014 at 10:29 AM Subject: Re: JavaFx roadmap? To: Adam Granger a...@adamish.com On Mon, Aug 11, 2014 at 11:08 PM, Adam Granger a...@adamish.com wrote: The official java fx roadmap on oracle.com seems to have been taken down, without replacement. http://www.oracle.com/technetwork/java/javafx/overview/roadmap-1446331.html I've had a search in JIRA and there is clearly a lot of work going on. - What's the long term plan, target release dates, long term support dates? We're interested in this at work, but need to know oracle is committed to it. - What about features like multi-touch on Linux? - How will WebView ever keep up with the constantly evolving HTML5 platform? - Is Swing development really over? As I am probably in a similar situation like you (wild guess) and I have posted questions here with probably similar motivation (making informed decisions regarding our product technology strategy), here are my two cents: Swing is likely to be available for at least another few years. It's not deprecated in 8, so earliest to deprecate it is 9 and 10 is not officially scheduled but Wikipedia guesses around 2018. Additionally there are probably many Oracle support contract customers out there that run Swing-based applications and I do not think it's likely Oracle wants to piss them off by rushing out of Swing. The amount of Swing development at Oracle (making new things like Retina support work) is something nobody can predict. Depending on your product, something like this may become a problem for you before Swing hits end of life. In addition to that there are probably a number of larger Swing-based Oracle applications (Netbeans being the largest one probably) that would have to be migrated to JFX (or dumped) before getting rid of Swing. Having said that, I don't think Oracle folks will likely say anything that encourages people to wait with their adoption of JFX for obvious reasons. The amount of work that is obviously put into JFX is significant (judging by following this list and Jira) and it does look very unlikely that it is going away. Regarding adoption of JFX for me there is a bit of a chicken-egg problem. My first research into migrating our stuff to JFX gave me the impression that it is a great platform to work with, easily learned by Swing developers with a lot of advantages over Swing regarding maintainability of code among other things but there are still quite a few bugs that simply show, it has not been used that much (as in thousands or tens of thousands of production-quality applications having been developed with it, not hello-world-style or free academic applications where people do not complain as much about problems) and that may be a reason to wait with adoption for some people (after all pretty complex high-profile applications like Idea still work very well with Swing although development, especially as look-and-feel customization is concerned, is very clumsy compared to JFX). Response to JFX Jira bug reports is outstanding, though. All in all not an easy call. Cheers, Robert
hg: openjfx/8u-dev/rt: RT-38169: Pass/fail swipe condition is problematic; RT-37822:[Unit Tests] Adding swipe tests
Changeset: cba4400b96aa Author:Elina Kleyman elina.kley...@oracle.com Date: 2014-08-14 12:36 +0300 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/cba4400b96aa RT-38169: Pass/fail swipe condition is problematic; RT-37822:[Unit Tests] Adding swipe tests ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/SwipeGestureRecognizer.java + tests/system/src/test/java/com/sun/glass/ui/monocle/SwipeSimpleTest.java
hg: openjfx/8u-dev/rt: RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store bundles
Changeset: f7cf21c9e487 Author:shemnon Date: 2014-08-14 10:48 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/f7cf21c9e487 RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store bundles Summary: update the part of the MacAppBundler where the JDK runtime rules are calculated, so we pay attention to what libraries are present and exclude based on what is there. Also, update some outdated web links in comments relating to JDK stripping ! modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxAppBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WindowsBundlerParam.java ! modules/fxpackager/src/main/resources/com/oracle/tools/packager/mac/MacAppBundler.properties ! modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppBundlerTest.java ! modules/fxpackager/src/test/java/com/oracle/tools/packager/mac/MacAppStoreBundlerTest.java
hg: openjfx/8u-dev/rt: [TEST ONLY] Fix tests for RT-38012. The explicit TimeZone was not uniformly applied to all objects.
Changeset: 54d3f711ae54 Author:leifs Date: 2014-08-14 10:40 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/54d3f711ae54 [TEST ONLY] Fix tests for RT-38012. The explicit TimeZone was not uniformly applied to all objects. ! modules/base/src/test/java/javafx/util/converter/DateStringConverterTest.java ! modules/base/src/test/java/javafx/util/converter/DateTimeStringConverterTest.java ! modules/base/src/test/java/javafx/util/converter/TimeStringConverterTest.java
Overhead for table columns.
We've been looking at very large tables for use in data grid display. Row count scales very nicely indeed, but column count is much more problematic. In the March time frame, our tests showed that each column had approximately 100KB overhead (using VisualVM), which is negligible at 100 columns, but at 10,000 columns becomes an issue. We have real world use cases of more columns than that . Is there planned effort to reduce the overhead, or are we looking at likely having to build our own table component to serve these large needs? -- Sean
hg: openjfx/8u-dev/rt: [Accessibility] JavaDoc for AccessibleRole major update
Changeset: 9ba20c17e0f9 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-08-14 12:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/9ba20c17e0f9 [Accessibility] JavaDoc for AccessibleRole major update ! modules/graphics/src/main/java/javafx/scene/AccessibleRole.java
hg: openjfx/8u-dev/rt: RT-37959: [Accessibility] Review a11y enums
Changeset: 8f77e2f47662 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-08-14 12:46 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8f77e2f47662 RT-37959: [Accessibility] Review a11y enums Removed AccessibleRole#HEADER, not used. Note AccessileAttribute#HEADER is used and stays ! modules/graphics/src/main/java/com/sun/glass/ui/mac/MacAccessible.java ! modules/graphics/src/main/java/javafx/scene/AccessibleRole.java
Re: Render bug
Okay, here’s the jira:
Render bug animating over node with lighting effect
I also simplified the example (happens with a Rectangle background as well as
ImageView).
jeff
On Aug 13, 2014, at 3:20 PM, Chien Yang chien.y...@oracle.com wrote:
This looks like a bug in JavaFX when applying the lighting effect. I was able
to reproduce the dirty rect rendering on my system. The bug went away if I
commented out the following line:
iview.setEffect(lighting);
Can you please file a JIRA so that we will fix it?
Thanks,
- Chien
On 8/13/2014 8:33 AM, Jeff Martin wrote:
I’m getting a rendering bug with a simple rotating path in front of an
ImageView (with lighting effect) on Mac OS with 8u20:
http://reportmill.com/examples/Renderbug/Renderbug.jpg
Looks like some sort of dirty rect problem. Am I doing something wrong or
should I file a bug?
The code is below. If anyone has an idea for a quick work around, let me
know.
jeff
import javafx.animation.RotateTransition;
import javafx.application.Application;
import javafx.scene.*;
import javafx.scene.effect.*;
import javafx.scene.paint.Color;
import javafx.scene.shape.*;
import javafx.stage.Stage;
import javafx.util.Duration;
public class DrawTurd extends Application {
public void start(Stage aStage)
{
// Creat background rect with lighting effect
Rectangle rect = new Rectangle(0,0,500,400); rect.setFill(Color.YELLOW);
Light.Distant light = new Light.Distant(); light.setAzimuth(60);
light.setElevation(120);
Lighting lighting = new Lighting(); lighting.setLight(light);
lighting.setSurfaceScale(10);
rect.setEffect(lighting);
// Create foreground path triangle with rotation transition animation
Path path = new Path();
path.getElements().add(new MoveTo(100,100)); path.getElements().add(new
LineTo(180,180));
path.getElements().add(new LineTo(260,100)); path.getElements().add(new
ClosePath());
path.setFill(Color.RED); path.setStroke(Color.BLACK);
RotateTransition rt = new RotateTransition(Duration.millis(3000), path);
rt.setByAngle(180); rt.setCycleCount(4); rt.setAutoReverse(true); rt.play();
// Create group, add nodes, set scene root, show stage
Group group = new Group(rect, path);
aStage.setScene(new Scene(group));
aStage.show();
}
}
Re: Elliptical gradient
I could have sworn there was a bug for this, but I can't find it. You should submit one so that we can track the request. In the meantime, you could apply your trick to any shape by setting that shape as the clip on the proportionally distorted rectangle... ...jim On 8/13/14 4:38 PM, Edu García wrote: Hi, Is there a way of create an elliptical gradient? The only way I've found is creating a RadialGradient with proportional set as true, and then apply that to a rectangle of the proportions I want. But obviously, that's not very useful if I want to apply it to any shape. If there is no way and this was just an oversight, will it be possible to have a RadialGradient constructor with two points and two radii to cover all the possible cases, like PDF has? We can always adapt the other constructor using the focus angle and length to map to this two points internally, and I'm assuming we do something similar when converting inside Prism (or any of the related subsystems, sorry, I don't know any of the JFX internals yet :D)
hg: openjfx/8u-dev/rt: [Accessibility] JavaDoc for AccessibleAction updated
Changeset: 7ade5c95d0fc Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-08-14 13:34 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7ade5c95d0fc [Accessibility] JavaDoc for AccessibleAction updated ! modules/graphics/src/main/java/javafx/scene/AccessibleAction.java
hg: openjfx/8u-dev/rt: [Accessibility] Removed AccessibleAttribute#getName(), it was not used
Changeset: e83331cf4ed4 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-08-14 13:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/e83331cf4ed4 [Accessibility] Removed AccessibleAttribute#getName(), it was not used ! modules/graphics/src/main/java/javafx/scene/AccessibleAttribute.java
hg: openjfx/8u-dev/rt: RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store bundles
Changeset: 7e5faca81800 Author:shemnon Date: 2014-08-14 15:27 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/7e5faca81800 RT-38312: Modify Packager to remove QT Kit platform when creating Mac App Store bundles Summary: The runtime check caused problems when run on windows and linux, make sure that doesn't happen. ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppBundler.java
hg: openjfx/8u-dev/rt: RT-38313: [CSS] Serious rendering artifacts running Ensemble8
Changeset: afbc7b22b7ab Author:kcr Date: 2014-08-14 14:48 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/afbc7b22b7ab RT-38313: [CSS] Serious rendering artifacts running Ensemble8 Backed out changeset e59c3dfc28e0 ! modules/graphics/src/main/java/com/sun/javafx/css/parser/CSSParser.java
Re: Overhead for table columns.
Actually this is slightly wrong. I was holding off replying until I had a bit more time to be thorough, but I'll respond now to prevent this misunderstanding from being discussed :-) It _is_ possible to virtualise the TableView in both directions. This doesn't necessarily help with the overhead entirely, but it should help substantially. I might be forgetting some important element as I have not referred back to the code, but I believe that the only thing that is necessary is for the developer to set a fixed cell size on the TableView (via TableView#setFixedCellSize). When this happens, the TableView can 1) reduce enormously the amount of computations it has to do for layout and 2) virtualise the columns. I suspect 2 is your primary goal, but 1 shouldn't be underestimated given the enormity of your table. Sean, it would be interesting if you could send me a sample application that demonstrates your problem. I am always trying to optimise these virtualised controls and would appreciate adding your specific use case to my suite of tests. Thanks, -- Jonathan On 15/08/2014 10:35 a.m., Tomas Mikula wrote: On Thu, Aug 14, 2014 at 9:01 PM, Sean True sean.t...@gmail.com wrote: We've been looking at very large tables for use in data grid display. Row count scales very nicely indeed, but column count is much more problematic. To explain your observation: TableView is based on VirtualFlow, which optimizes the number of cells simultaneously attached to the scene graph in one direction (horizontal or vertical). For TableView, vertical VirtualFlow is used, which means rows are optimized (invisible rows are not in the scene graph), while all columns for each visible row are in the scene graph. To be able to scroll smoothly through the table, you would want a two-dimensional virtual flow. You can look at VirtualFlow.java from OpenJFX or from my alternative virtual flow implementation Flowless [1] to get an idea about the complexity of the one-dimensional case. If you don't require smooth scrolling and are fine with scroll by one row/column at a time, you could display a small table with fixed cell count, say 30x20 (maybe calculated dynamically based on the available area), and display your own scrollbars that will update the data model behind this small table. Not the best solution, but much less work. Regards, Tomas [1] https://github.com/TomasMikula/Flowless In the March time frame, our tests showed that each column had approximately 100KB overhead (using VisualVM), which is negligible at 100 columns, but at 10,000 columns becomes an issue. We have real world use cases of more columns than that . Is there planned effort to reduce the overhead, or are we looking at likely having to build our own table component to serve these large needs? -- Sean
Re: Overhead for table columns.
I like this kind of being wrong :-) Tomas On Fri, Aug 15, 2014 at 12:42 AM, Jonathan Giles jonathan.gi...@oracle.com wrote: Actually this is slightly wrong. I was holding off replying until I had a bit more time to be thorough, but I'll respond now to prevent this misunderstanding from being discussed :-) It _is_ possible to virtualise the TableView in both directions. This doesn't necessarily help with the overhead entirely, but it should help substantially. I might be forgetting some important element as I have not referred back to the code, but I believe that the only thing that is necessary is for the developer to set a fixed cell size on the TableView (via TableView#setFixedCellSize). When this happens, the TableView can 1) reduce enormously the amount of computations it has to do for layout and 2) virtualise the columns. I suspect 2 is your primary goal, but 1 shouldn't be underestimated given the enormity of your table. Sean, it would be interesting if you could send me a sample application that demonstrates your problem. I am always trying to optimise these virtualised controls and would appreciate adding your specific use case to my suite of tests. Thanks, -- Jonathan On 15/08/2014 10:35 a.m., Tomas Mikula wrote: On Thu, Aug 14, 2014 at 9:01 PM, Sean True sean.t...@gmail.com wrote: We've been looking at very large tables for use in data grid display. Row count scales very nicely indeed, but column count is much more problematic. To explain your observation: TableView is based on VirtualFlow, which optimizes the number of cells simultaneously attached to the scene graph in one direction (horizontal or vertical). For TableView, vertical VirtualFlow is used, which means rows are optimized (invisible rows are not in the scene graph), while all columns for each visible row are in the scene graph. To be able to scroll smoothly through the table, you would want a two-dimensional virtual flow. You can look at VirtualFlow.java from OpenJFX or from my alternative virtual flow implementation Flowless [1] to get an idea about the complexity of the one-dimensional case. If you don't require smooth scrolling and are fine with scroll by one row/column at a time, you could display a small table with fixed cell count, say 30x20 (maybe calculated dynamically based on the available area), and display your own scrollbars that will update the data model behind this small table. Not the best solution, but much less work. Regards, Tomas [1] https://github.com/TomasMikula/Flowless In the March time frame, our tests showed that each column had approximately 100KB overhead (using VisualVM), which is negligible at 100 columns, but at 10,000 columns becomes an issue. We have real world use cases of more columns than that . Is there planned effort to reduce the overhead, or are we looking at likely having to build our own table component to serve these large needs? -- Sean
Re: Elliptical gradient
Created https://javafx-jira.kenai.com/browse/RT-38316. Thanks for your response and workaround. It's a bit complex doing that instead of applying the gradient, at least for now due to my architecture, but nice to know that I have options. On Fri, Aug 15, 2014 at 6:19 AM, Jim Graham james.gra...@oracle.com wrote: I could have sworn there was a bug for this, but I can't find it. You should submit one so that we can track the request. In the meantime, you could apply your trick to any shape by setting that shape as the clip on the proportionally distorted rectangle... ...jim On 8/13/14 4:38 PM, Edu García wrote: Hi, Is there a way of create an elliptical gradient? The only way I've found is creating a RadialGradient with proportional set as true, and then apply that to a rectangle of the proportions I want. But obviously, that's not very useful if I want to apply it to any shape. If there is no way and this was just an oversight, will it be possible to have a RadialGradient constructor with two points and two radii to cover all the possible cases, like PDF has? We can always adapt the other constructor using the focus angle and length to map to this two points internally, and I'm assuming we do something similar when converting inside Prism (or any of the related subsystems, sorry, I don't know any of the JFX internals yet :D)
Re: Some questions
Created https://javafx-jira.kenai.com/browse/RT-38319 for the pixelated snapshot. In case nobody understood my requirements on my last point of my previous message, what I want is to have the behaviour of that bug I found, but on the screen and by choice :D On Tue, Aug 12, 2014 at 7:21 AM, Edu García arcn...@gmail.com wrote: On Aug 12, 2014 6:59 AM, Jim Graham james.gra...@oracle.com wrote: On 8/9/14 3:19 PM, Edu García wrote: Hi, I have a few questions about JavaFX usage, I hope this is the right place to ask them: 1. I'm creating a Pane with a lot of shapes and resizing it to 128x128. I'm saving it as an image with snapshot() and SwingFXUtils.fromFXImage() (is there any other way?). Why is my saved image 129x129, instead of 128x128? That's the only way currently. When does it become 129x129? Is the output of snapshot that size? If it was positioned not on a pixel boundary, then it might go from 10.5 to 138.5 and we'd capture all pixels from 10 to 139 and get a size of 129. Is something like that happening? I'll need to check again, but my pane is not positioned anywhere, it might be at 0,0 (is the only JFX object I'm creating) 2. With the same Pane and image, when working on a Retina system, the output is clearly pixelated, like the real resolution of the image should be 64x64. Is this a bug? That would be a bug. Is the resulting image 64x64, or 128x128? We may be mis-applying the screen scale when we aren't talking to the screen. The output image is 129x129, but it's pixelated, like it was rendered at 64x64 and then scaled at 2x. 3. Non related to the previous, I want to have pixelated rendering (on the screen, not to a file) when I modify the scale of my pane or shapes. Is there a way of forcing JavaFX to do something like that? Or do I have to render to an image at 1:1 resolution, scale that and replace my pane with it? I'm assuming that will be a bit slow. What do you mean by pixelated rendering? I don't think we provide that, but I'm not 100% sure what you want there... I want to simulate what will happen when saving my shapes to an image and then zooming in, like the pixelated output of Illustrator, or the look of an old videogame. So what I want is JFX to always render at the same resolution internally, and then scale that when showing it to the screen ...jim Thank you!
[Review request] RT-12643: JavaFX Dialogs API
Hi all, After much discussion a 'final' JavaFX Dialogs API has been created and is awaiting final review. The plan is to integrate this into the 8udev repo before it is promoted early next week. The Jira discussion for the dialogs API is long, but very informative. You can find it here: https://javafx-jira.kenai.com/browse/RT-12643 The webrev can be found here: http://cr.openjdk.java.net/~kcr/RT-12643/webrev.00/ Any comments should be directed into the jira issue, rather than discussed on this list (so that we can keep everything in one place). Thanks, Jonathan
Re: Overhead for table columns.
Folks, that was extremely helpful. I'll see what I can pry loose as an example. On Thursday, August 14, 2014, Tomas Mikula tomas.mik...@gmail.com wrote: I like this kind of being wrong :-) Tomas On Fri, Aug 15, 2014 at 12:42 AM, Jonathan Giles jonathan.gi...@oracle.com javascript:; wrote: Actually this is slightly wrong. I was holding off replying until I had a bit more time to be thorough, but I'll respond now to prevent this misunderstanding from being discussed :-) It _is_ possible to virtualise the TableView in both directions. This doesn't necessarily help with the overhead entirely, but it should help substantially. I might be forgetting some important element as I have not referred back to the code, but I believe that the only thing that is necessary is for the developer to set a fixed cell size on the TableView (via TableView#setFixedCellSize). When this happens, the TableView can 1) reduce enormously the amount of computations it has to do for layout and 2) virtualise the columns. I suspect 2 is your primary goal, but 1 shouldn't be underestimated given the enormity of your table. Sean, it would be interesting if you could send me a sample application that demonstrates your problem. I am always trying to optimise these virtualised controls and would appreciate adding your specific use case to my suite of tests. Thanks, -- Jonathan On 15/08/2014 10:35 a.m., Tomas Mikula wrote: On Thu, Aug 14, 2014 at 9:01 PM, Sean True sean.t...@gmail.com javascript:; wrote: We've been looking at very large tables for use in data grid display. Row count scales very nicely indeed, but column count is much more problematic. To explain your observation: TableView is based on VirtualFlow, which optimizes the number of cells simultaneously attached to the scene graph in one direction (horizontal or vertical). For TableView, vertical VirtualFlow is used, which means rows are optimized (invisible rows are not in the scene graph), while all columns for each visible row are in the scene graph. To be able to scroll smoothly through the table, you would want a two-dimensional virtual flow. You can look at VirtualFlow.java from OpenJFX or from my alternative virtual flow implementation Flowless [1] to get an idea about the complexity of the one-dimensional case. If you don't require smooth scrolling and are fine with scroll by one row/column at a time, you could display a small table with fixed cell count, say 30x20 (maybe calculated dynamically based on the available area), and display your own scrollbars that will update the data model behind this small table. Not the best solution, but much less work. Regards, Tomas [1] https://github.com/TomasMikula/Flowless In the March time frame, our tests showed that each column had approximately 100KB overhead (using VisualVM), which is negligible at 100 columns, but at 10,000 columns becomes an issue. We have real world use cases of more columns than that . Is there planned effort to reduce the overhead, or are we looking at likely having to build our own table component to serve these large needs? -- Sean
hg: openjfx/8u-dev/rt: [Accessibility] JavaDoc for AccessibleAttribute updated
Changeset: 2056b7f57799 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-08-14 19:58 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/2056b7f57799 [Accessibility] JavaDoc for AccessibleAttribute updated ! modules/graphics/src/main/java/javafx/scene/AccessibleAction.java ! modules/graphics/src/main/java/javafx/scene/AccessibleAttribute.java
hg: openjfx/8u-dev/rt: RT-14000 Add Formatted TextField control
Changeset: 290274db83f7 Author:Martin Sladecek martin.slade...@oracle.com Date: 2014-08-15 07:57 +0200 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/290274db83f7 RT-14000 Add Formatted TextField control Reviewed by: kcr, snorthov ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextAreaBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextFieldBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBehavior.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/behavior/TextInputControlBindings.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/TextInputControlSkin.java ! modules/controls/src/main/java/javafx/scene/control/TextInputControl.java ! modules/controls/src/test/java/javafx/scene/control/TextInputControlTest.java
