Re: Can JavaFX do CAD?
I believe JavaFx could do cad, first step would be to provide a simple data set and boil it down to the best render paths in JavaFX. As far as I know it shouldn't be any worse than swing with the slowest render paths. -Joe On Jul 23, 2013, at 8:47 AM, Chris Gay chris.gay5...@gmail.com wrote: Hello all. Please could someone advise if it is even feasible for me to consider re-factoring the following Swing application, so that it becomes a JavaFX one. From trying to read about JavaFX, I get the feeling that Oracle never intended Java FX for the purpose I need. I have a large Java Swing desktop CAD application which makes heavy use of the Java 2D API, and concurrency. It is a Menu Bar driven application, with a Toolbar for Tools, and a few buttons, but 99% of the user activity concerns selecting and manipulating vector graphical objects in a traditional manner using one Tool at a time (think Inkscape or LibreOffice Drawing apps). The application has multiple drawings open at the same time (but only one is visible), and each Drawing contains it's own Drawing and Processing threads (in addition to sharing the Main and Event Threads), which keeps the Event Thread lively. Each Drawing contains an ArrayList, acting as a Display List of all graphical objects, and each graphical object can be a tree structure. In many cases I use simple iteration instead of Iterators, simply for speed, and to avoid garbage. The graphical objects are lightweight, in that they do not carry references to events and handlers. All they carry is their basic geometric data and properties, a bounding box which they can lend as Read Only, and a boolean flag to indicate selection, which means there can be millions of the objects, with a minimum memory footprint. To support them, there are many hundreds of methods, which the tools interact with. There can be multiple Drawing Windows active on a single drawing, where each Window is backed up by an offscreen image, which handles the zoom and sliding buffer behaviour for fast scrolling, to allow rapid bit-blt's to the actual window. Lastly, the user manipulates the Drawing (Display List), using one of many Tools, where the active Tool receives events from the event queue, and then manipulates selected and/or unselected graphical objects, by using XOR Mode graphics onto the offscreen buffer, generally using callbacks. The system is fast and very responsive on large data sets, but what I do not know is whether JavaFX will help me make a better implementation, or whether it will fight me all the way. With JavaFX claiming hardware acceleration, I do not understand whether it depends on transferring the very large data sets into graphics hardware to render, and what happens if the hardware cannot cope. So far, I have found little in the way of discussions that help me get a mental picture of how JavaFX is intended to work. Should I stick with Swing? Regards, Chris
Re: Fwd: API Change Proposal - Re: MSAA and Scene anti aliasing
Hi Scott,
This isn't in the plan for JavaFX 8. I'm not sure how feasible it
is to access this information from different GPU vendors and across
platforms (desktop and embedded).
- Chien
On 7/23/2013 6:33 PM, Scott Palmer wrote:
copying the list...
-- Forwarded message --
From: Scott Palmer swpal...@gmail.com
Date: Tue, Jul 23, 2013 at 9:33 PM
Subject: Re: API Change Proposal - Re: MSAA and Scene anti aliasing
To: Chien Yang chien.y...@oracle.com
Is DEFAULT intended to defer to the settings in the system graphics drivers
(e.g. nVidia control panel) such that the precise settings used are defined
outside the scope of JavaFX and could vary between otherwise identical
systems based on the settings the user has selected somewhere else?
If so perhaps something like SYSTEM, USER, or UNSPECIFIED ,make sense.
On Tue, Jul 23, 2013 at 9:14 PM, Chien Yang chien.y...@oracle.com wrote:
Well, I personally think that might be over stretching. :-) FAST and
NICEST will behave no difference on a platform that can't support AA. For
such platform we will have to cover in the API specification.
- Chien
On 7/23/2013 2:37 PM, Richard Bair wrote:
Actually that is exactly what I was hoping DEFAULT would mean -- some
kind of typical option for the particular platform (maybe even disabled on
some!).
Richard
On Jul 23, 2013, at 1:41 PM, Felix Bembrick felix.bembr...@gmail.com
wrote:
I am not sure I like the name of the value DEFAULT. To me default
implies some kind of typical option for the particular platform which
could conceivably be very different on each platform. For example, on my
Windows super-computer with ultra fast GPU the default would logically
be
something like 16x whereas on my iPhone I would expect the default to be
using only 2x. The comment for DEFAULT implies that it's really more of
a
BALANCED or MODERATE setting that would have the same characteristics on
each platform.
On 24 July 2013 06:29, Chien Yang chien.y...@oracle.com wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic.
After listening to the feedback and an internal discussion, we would
like
to propose a minor change to the API for supporting scene
anti-aliasing. We
intentionally choose not to expose the number of samples and techniques
used in this release, but this doesn't preclude future addition when the
time is right for more options. This change will be tracked by RT-31878
(
https://javafx-jira.kenai.com/browse/RT-31878https://**
javafx-jira.kenai.com/browse/**RT-31878https://javafx-jira.kenai.com/browse/RT-31878
):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics
driver has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the
moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting
available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available
that results in best visual quality
}
Thanks,
- Chien
Re: Can JavaFX do CAD?
I think the below comment makes it sound more straight forward than it is. In building a diagramming tool there is much more to it than just the rendering frame rate. This topic about CAD-like apps and 'performant' highly visual jfx apps in general has been raised here and in the forums before, without any clear resolution. Chris, the closest we've come to an answer is that it certainly isn't straight forward to do and there are many areas where the intuitive solution (especially for us ex-swing devs) gives results that are horribly unusable. There *might* be a way to get jfx to do this but there's no clear guidelines on how to achieve a 'performant' result. This is why I +1'd your question and added areas I feel need clarification from the jfx team. Unfortunately I'm not entirely sure they know the answers themselves and it generally comes back as a 'you try it and let us know how it goes'. The last time we raised a similar topic it led to an attempt to build a Tower Defender game (led by Richard) in order to 'see how it goes', which revealed some pretty significant problems and the game quickly stalled as a result. Having built a prototype floor plan tool in JFX2 before I can say it did not go smoothly. The things I've listed as wanting best practices for are all areas where I struggled to make jfx achieve decent results in terms of responsiveness, animation speed/smoothness, rendering quality and simplicity and cleanliness of code. The one area where I'd say it did hold up well (as far as I could tell) was frame rate but that didn't help me at all and I doubt would be much consolation for you after you make the massive effort needed to convert your app. On 24/07/2013, at 4:29 PM, Joseph Andresen joseph.andre...@oracle.com wrote: I believe JavaFx could do cad, first step would be to provide a simple data set and boil it down to the best render paths in JavaFX. As far as I know it shouldn't be any worse than swing with the slowest render paths. -Joe On Jul 23, 2013, at 8:47 AM, Chris Gay chris.gay5...@gmail.com wrote: Hello all. Please could someone advise if it is even feasible for me to consider re-factoring the following Swing application, so that it becomes a JavaFX one. From trying to read about JavaFX, I get the feeling that Oracle never intended Java FX for the purpose I need. I have a large Java Swing desktop CAD application which makes heavy use of the Java 2D API, and concurrency. It is a Menu Bar driven application, with a Toolbar for Tools, and a few buttons, but 99% of the user activity concerns selecting and manipulating vector graphical objects in a traditional manner using one Tool at a time (think Inkscape or LibreOffice Drawing apps). The application has multiple drawings open at the same time (but only one is visible), and each Drawing contains it's own Drawing and Processing threads (in addition to sharing the Main and Event Threads), which keeps the Event Thread lively. Each Drawing contains an ArrayList, acting as a Display List of all graphical objects, and each graphical object can be a tree structure. In many cases I use simple iteration instead of Iterators, simply for speed, and to avoid garbage. The graphical objects are lightweight, in that they do not carry references to events and handlers. All they carry is their basic geometric data and properties, a bounding box which they can lend as Read Only, and a boolean flag to indicate selection, which means there can be millions of the objects, with a minimum memory footprint. To support them, there are many hundreds of methods, which the tools interact with. There can be multiple Drawing Windows active on a single drawing, where each Window is backed up by an offscreen image, which handles the zoom and sliding buffer behaviour for fast scrolling, to allow rapid bit-blt's to the actual window. Lastly, the user manipulates the Drawing (Display List), using one of many Tools, where the active Tool receives events from the event queue, and then manipulates selected and/or unselected graphical objects, by using XOR Mode graphics onto the offscreen buffer, generally using callbacks. The system is fast and very responsive on large data sets, but what I do not know is whether JavaFX will help me make a better implementation, or whether it will fight me all the way. With JavaFX claiming hardware acceleration, I do not understand whether it depends on transferring the very large data sets into graphics hardware to render, and what happens if the hardware cannot cope. So far, I have found little in the way of discussions that help me get a mental picture of how JavaFX is intended to work. Should I stick with Swing? Regards, Chris
hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
Changeset: dd30604ab7d0 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-07-24 11:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd30604ab7d0 RT-26702 Poor DisplacementMap effect performance on Mac Reviewed-by: anthony, art, snorthov ! modules/graphics/src/main/native-glass/mac/GlassEmbeddedWindow+Overrides.m ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.h ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.m ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.h ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.h ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m
FBX Importer for OpenJFX
Hi all, We would like to be able to load FBX files into the 3DViewer app. Are there any plans to develop an FBX importer, or is this something we should implement ourselves? Thanks in advance. Rob
hg: openjfx/8/graphics/rt: Merged AnimationPathHelper and Position2D into PathTransition
Changeset: a22a79de9b10 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-07-24 09:35 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a22a79de9b10 Merged AnimationPathHelper and Position2D into PathTransition ! modules/graphics/src/main/java/com/sun/javafx/TempState.java - modules/graphics/src/main/java/com/sun/javafx/animation/transition/AnimationPathHelper.java - modules/graphics/src/main/java/com/sun/javafx/animation/transition/Position2D.java ! modules/graphics/src/main/java/javafx/animation/PathTransition.java ! modules/graphics/src/main/java/javafx/scene/Node.java
Re: Disabling JavaFX minimise/maximise/etc buttons
On 7/24/2013 12:34 AM, Anthony Petrov wrote: Hi Werner, On 07/23/2013 03:19 PM, Werner Lehmann wrote: On 23.07.2013 12:39, Artem Ananiev wrote: To me, making a window non-resizable is a good way to make the window unmaximizable. Do you see any cases, when a window should be resizable, but not maximizable? I create resizable modal dialogs on a frequent basis. To me, sizability is a convenience for the user. At the same time, modal dialogs should not be maximized. My opinion. I don't agree. IMO, it's annoying when I'm able to resize a window freely but unable to maximize it. This just doesn't look logical or convenient. +1 Unminimizable windows are annoying. If we disable that, we'll likely get some weirdness, e.g. Win+M or Win+D on Windows will leave the window on the desktop, which is not what users expect. Minimizing a modal dialog does not achieve much because the owning window is still blocked. Unless that window is minimized along. At least Windows usually disables the window decoration buttons of the owning window though. Indeed. I was thinking about implementing the behavior that OS X provides for native windows: if you iconify an owned modal dialog, its owner gets iconified as well. This looks very convenient. We might try to implement this in Glass for other platforms as well. Or alternatively, we could provide an API to disable window iconification. Modal dialogs are (or should be) used to get some input from user. Window closing confirmation is a good example. Application cannot proceed further, until it have the input, so it doesn't make sense to minimize the modal dialog and leave application in the suspended state. Thanks, Artem -- best regards, Anthony
Re: Disabling JavaFX minimise/maximise/etc buttons
On 7/24/2013 12:45 AM, Fabrizio Giudici wrote: On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov anthony.pet...@oracle.com wrote: I don't agree. IMO, it's annoying when I'm able to resize a window freely but unable to maximize it. This just doesn't look logical or convenient. I'm with Werner here. Maximixing a dialog is usually ugly from the aesthetic point of view, but sometimes I'm annoyed by dialogs that are just a bit too narrow for entering a text, or something else (incidentally, e.g. the Java control panel seems to be filled with non-resizable windows designed just to annoy people :-). I'd just like to stretch them a bit. Could you identify the boundary between just making a window larger and maximizing it? I can't. What about Windows 7 snap feature, is it resizing or maximizing? In other words, my understanding is that if a window is resizable, it should be maximizable as well. However, as I wrote in my previous emails, sometimes it's out of Java control: we can say if a window should be resizable or not, and the platform decides if it is minimizable/maximizable or not. Thanks, Artem But I don't know how this stands with the various operating system design guidelines.
Re: Disabling JavaFX minimise/maximise/etc buttons
On Wed, 24 Jul 2013 09:59:07 +0200, Artem Ananiev artem.anan...@oracle.com wrote: On 7/24/2013 12:45 AM, Fabrizio Giudici wrote: On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov anthony.pet...@oracle.com wrote: I don't agree. IMO, it's annoying when I'm able to resize a window freely but unable to maximize it. This just doesn't look logical or convenient. I'm with Werner here. Maximixing a dialog is usually ugly from the aesthetic point of view, but sometimes I'm annoyed by dialogs that are just a bit too narrow for entering a text, or something else (incidentally, e.g. the Java control panel seems to be filled with non-resizable windows designed just to annoy people :-). I'd just like to stretch them a bit. Could you identify the boundary between just making a window larger and maximizing it? I can't. What about Windows 7 snap feature, is it resizing or maximizing? In other words, my understanding is that if a window is resizable, it should be maximizable as well. However, as I wrote in my previous emails, sometimes it's out of Java control: we can say if a window should be resizable or not, and the platform decides if it is minimizable/maximizable or not. Thanks, The boundary is when you feel the look is ugly, thus it's related to the % of size increase. That's why snap is not a problem. Of course I can't tell you a precise threshold, it depends. But it's ok when I just enlarge a window because it lacks the room for say 5-10 characters of input, while I don't like to see a maximized window where there's just a small content and large amounts of empty space. Also: sometimes you want a modal, that is the main window is blocked, but perhaps you need to read something in the main window, that would help to answer to the question of the modal. If the modal is just resizable (and draggable) there's no problem. If the modal has been maximized, you can't. Of course, it's up to the user to avoid maximizing it if it's a problem - there are no showstoppers here. But UI design is all about driving the user in the right direction and minimizing the number of interaction items needed to accomplish a task. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Disabling JavaFX minimise/maximise/etc buttons
On 07/24/13 12:29, Fabrizio Giudici wrote: On Wed, 24 Jul 2013 09:59:07 +0200, Artem Ananiev artem.anan...@oracle.com wrote: On 7/24/2013 12:45 AM, Fabrizio Giudici wrote: On Tue, 23 Jul 2013 22:34:48 +0200, Anthony Petrov anthony.pet...@oracle.com wrote: I don't agree. IMO, it's annoying when I'm able to resize a window freely but unable to maximize it. This just doesn't look logical or convenient. I'm with Werner here. Maximixing a dialog is usually ugly from the aesthetic point of view, but sometimes I'm annoyed by dialogs that are just a bit too narrow for entering a text, or something else (incidentally, e.g. the Java control panel seems to be filled with non-resizable windows designed just to annoy people :-). I'd just like to stretch them a bit. Could you identify the boundary between just making a window larger and maximizing it? I can't. What about Windows 7 snap feature, is it resizing or maximizing? In other words, my understanding is that if a window is resizable, it should be maximizable as well. However, as I wrote in my previous emails, sometimes it's out of Java control: we can say if a window should be resizable or not, and the platform decides if it is minimizable/maximizable or not. Thanks, The boundary is when you feel the look is ugly, thus it's related to the % of size increase. That's why snap is not a problem. Of course I can't tell you a precise threshold, it depends. But it's ok when I just enlarge a window because it lacks the room for say 5-10 characters of input, while I don't like to see a maximized window where there's just a small content and large amounts of empty space. Then just don't push the Maximize button! :) I mean, you can easily achieve the state of ugliness by resizing the window as well, but you still want it to be resizable. So what's the big deal with the Maximize button then? Let it be there for people who want/need it. Also: sometimes you want a modal, that is the main window is blocked, but perhaps you need to read something in the main window, that would help to answer to the question of the modal. If the modal is just resizable (and draggable) there's no problem. If the modal has been maximized, you can't. Of course, it's up to the user to avoid maximizing it if it's a problem - there are no showstoppers here. But UI design is all about driving the user in the right direction and minimizing the number of interaction items needed to accomplish a task. I doubt an app would maximize a dialog initially (and if it does, it's a problem in the app itself). Otherwise, it's up to the user to maximize/unmaximize the dialog, or only resize it whenever and however it is needed/convenient at the moment. -- best regards, Anthony
Re: Can JavaFX do CAD?
We switched a vector editor which used swing to JavaFX (using a standard called ARINC 661), and we have no problems of performance in the Editor even for thousands of nodes. But I agree that you should not use the obvious Swing-converted way to do the same thing in JavaFX. Hervé Sent from my iPhone On 24 juil. 2013, at 09:19, Daniel Zwolenski zon...@gmail.com wrote: I think the below comment makes it sound more straight forward than it is. In building a diagramming tool there is much more to it than just the rendering frame rate. This topic about CAD-like apps and 'performant' highly visual jfx apps in general has been raised here and in the forums before, without any clear resolution. Chris, the closest we've come to an answer is that it certainly isn't straight forward to do and there are many areas where the intuitive solution (especially for us ex-swing devs) gives results that are horribly unusable. There *might* be a way to get jfx to do this but there's no clear guidelines on how to achieve a 'performant' result. This is why I +1'd your question and added areas I feel need clarification from the jfx team. Unfortunately I'm not entirely sure they know the answers themselves and it generally comes back as a 'you try it and let us know how it goes'. The last time we raised a similar topic it led to an attempt to build a Tower Defender game (led by Richard) in order to 'see how it goes', which revealed some pretty significant problems and the game quickly stalled as a result. Having built a prototype floor plan tool in JFX2 before I can say it did not go smoothly. The things I've listed as wanting best practices for are all areas where I struggled to make jfx achieve decent results in terms of responsiveness, animation speed/smoothness, rendering quality and simplicity and cleanliness of code. The one area where I'd say it did hold up well (as far as I could tell) was frame rate but that didn't help me at all and I doubt would be much consolation for you after you make the massive effort needed to convert your app. On 24/07/2013, at 4:29 PM, Joseph Andresen joseph.andre...@oracle.com wrote: I believe JavaFx could do cad, first step would be to provide a simple data set and boil it down to the best render paths in JavaFX. As far as I know it shouldn't be any worse than swing with the slowest render paths. -Joe On Jul 23, 2013, at 8:47 AM, Chris Gay chris.gay5...@gmail.com wrote: Hello all. Please could someone advise if it is even feasible for me to consider re-factoring the following Swing application, so that it becomes a JavaFX one. From trying to read about JavaFX, I get the feeling that Oracle never intended Java FX for the purpose I need. I have a large Java Swing desktop CAD application which makes heavy use of the Java 2D API, and concurrency. It is a Menu Bar driven application, with a Toolbar for Tools, and a few buttons, but 99% of the user activity concerns selecting and manipulating vector graphical objects in a traditional manner using one Tool at a time (think Inkscape or LibreOffice Drawing apps). The application has multiple drawings open at the same time (but only one is visible), and each Drawing contains it's own Drawing and Processing threads (in addition to sharing the Main and Event Threads), which keeps the Event Thread lively. Each Drawing contains an ArrayList, acting as a Display List of all graphical objects, and each graphical object can be a tree structure. In many cases I use simple iteration instead of Iterators, simply for speed, and to avoid garbage. The graphical objects are lightweight, in that they do not carry references to events and handlers. All they carry is their basic geometric data and properties, a bounding box which they can lend as Read Only, and a boolean flag to indicate selection, which means there can be millions of the objects, with a minimum memory footprint. To support them, there are many hundreds of methods, which the tools interact with. There can be multiple Drawing Windows active on a single drawing, where each Window is backed up by an offscreen image, which handles the zoom and sliding buffer behaviour for fast scrolling, to allow rapid bit-blt's to the actual window. Lastly, the user manipulates the Drawing (Display List), using one of many Tools, where the active Tool receives events from the event queue, and then manipulates selected and/or unselected graphical objects, by using XOR Mode graphics onto the offscreen buffer, generally using callbacks. The system is fast and very responsive on large data sets, but what I do not know is whether JavaFX will help me make a better implementation, or whether it will fight me all the way. With JavaFX claiming hardware acceleration, I do not understand whether it depends on transferring the very large data sets into graphics hardware
Re: Disabling JavaFX minimise/maximise/etc buttons
Hi Jonathan, setResizable(false) only disables the Maximize button (for obvious reasons.) And this should already be implemented. As to the setIconifiable(boolean) functionality, I agree it would be fine to have it. Please file a JIRA issue and we'll implement it. To address Tom's suggestion on adding fine-grained control for trim buttons: I don't support this idea for the following reason: you can access, say, the Iconify action via the trim button. But you can also right-click the window's titlebar and choose it from the menu. Moreover, you can right-click the taskbar button associated with the window and open the same menu from there. In those menus the Iconify is not a button but a menu item. However, both the trim button and the menu item represent the Iconify action. Therefore, from API perspective I'd prefer to be able to disable the Iconify action itself (i.e. the higher level concept) rather than disable individual native GUI items responsible for firing the event. I understand that most likely you're referring to a case when you want to maximize a window pogramatically and disallow a user to get the window back to the normal state. I believe you can achieve this using an UNDECORATED window more easily. -- best regards, Anthony On 07/24/13 00:36, Jonathan Giles wrote: To be clear, are you proposing that setResizable(false) on a Stage (where its owner is non-null) will be used to specify both that the stage can not be resized and that it can not be minimised? I don't have a big opinion on the best approach, except of course the discoverability of the functionality might be somewhat questionable. If it were me (and without all the insights your team has), my alternative suggestion would be to introduce a setIconifiable(boolean) method (along with isIconifiable() and iconifiableProperty()). I only recommend this to have some degree of symmetry with the iconfied property that is used to represent (I believe) whether the stage is currently minimised. In my use case for dialogs, specifying the owner is an optional property, but in general it is one of those properties that people should not leave as null. In other words, I'm comfortable enforcing a non-null owner requirement for people who do not want the minimize button, for example. Thanks, -- Jonathan On 24/07/2013 8:27 a.m., Anthony Petrov wrote: Hi Artem, Jonathan, I agree with what you say, except for using the initOwner() to imply some particular (and implicit) style that is going to be applied to the window. We should evaluate first whether the current implementation is sufficient. And no, I don't see a reason to disable maximization for a resizable window. Jonathan: what is your opinion on using the setResizable(false) for the use cases that you outlined? -- best regards, Anthony On 07/23/2013 02:39 PM, Artem Ananiev wrote: On 7/22/2013 9:17 PM, Anthony Petrov wrote: Hi Artem, Do you propose to add another StageStyle - namely, a DIALOG? Note that styles cannot be combined in a mask, meaning that developers won't be able to create e.g. transparent dialogs, or utility dialogs. There is no need in yet another StageStyle, because we already have this: Window.initOwner(). If we pass the owner to the platform, and set appropriate hints for owned/ownerless windows, we should look and behave similar to native apps. Generally, I like the idea of defining the purpose of a window and letting the OS/GUI toolkit decide what works best for it, but I'm not sure if we can apply it for this particular use case. Also, I think that ability to disable maximization/minimization of a window might be useful for purposes other than just displaying dialogs. To me, making a window non-resizable is a good way to make the window unmaximizable. Do you see any cases, when a window should be resizable, but not maximizable? BTW, isn't the setResizable(false) a good approximation for our requirements? You can still minimize such a window, but I think this is reasonable. E.g. OS X will minimize both the dialog and its owner window, allowing a user to perform other tasks unrelated to the dialog and windows it blocks. Why do we want to disable minimization? Unminimizable windows are annoying. If we disable that, we'll likely get some weirdness, e.g. Win+M or Win+D on Windows will leave the window on the desktop, which is not what users expect. Thanks, Artem -- best regards, Anthony On 07/22/2013 07:20 PM, Artem Ananiev wrote: On 7/22/2013 11:14 AM, Pavel Safrata wrote: Hi Jonathan, I believe this has been neither requested nor discussed so far. I don't see why this couldn't be added, it just might have to be a conditional feature, we'll have to check. Feel free to file a feature request. Some native platforms (mostly, X window managers) don't provide direct APIs to enable/disable certain window decoration buttons. A library or an application may provides some hints, which may or may not be respected by WM. I like what
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 5eab61f82635 Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-07-24 13:30 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5eab61f82635 Forgot to trigger pulse on requestLayout after RT-31644. ! modules/graphics/src/main/java/javafx/scene/Parent.java ! modules/graphics/src/stub/java/javafx/scene/ParentTest.java Changeset: da8e6e3cc25c Author:Martin Sladecek martin.slade...@oracle.com Date: 2013-07-24 13:31 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/da8e6e3cc25c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/graphics/jfxrt
Re: Disabling JavaFX minimise/maximise/etc buttons
On Wed, 24 Jul 2013 12:52:27 +0200, Anthony Petrov anthony.pet...@oracle.com wrote: Otherwise, it's up to the user to maximize/unmaximize the dialog, or only resize it whenever and however it is needed/convenient at the moment. As I said, to me UI design is also constraining the user in the set of meaningful actions. The more useless freedom you give him, the more damage he will do :-) -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. We make Java work. Everywhere. http://tidalwave.it/fabrizio/blog - fabrizio.giud...@tidalwave.it
Re: Can JavaFX do CAD?
Hi Daniel, I totally agree with your wishes, and even wonder if it is feasible in JavaFX. With my Swing App, although I support mouse-over sensitivity on things like JButtons, I do not support it on graphical objects, simply because the effort would kill the system, given millions of objects. Only when the mouse is clicked, dragged, or active-up do I provide dynamic visual feedback. I have yet to find anything written about Rubber-banding using a XOR mode graphics context in JavaFX. The way 3D games work has tended to be significantly different to how 2D CAD has worked in the past. I did not want limitations on how far I could zoom-in, so caching bitmaps to represent handles (XOR Mode) at a given scale was ruled-out, since they could be vast. Instead everything is done using Float data (mostly 64 bit Double Float in fact), with some key data, such as handle sizes having to dynamically scale for every new scale, so that they appear as a constant number of pixels. None of this data is parked in the graphical objects, but is held by the Viewport/Drawing Board, and supplied to the active Tool on request. Then everything is a vector draw using a Graphics2D context on the off-screen buffer, whether Bezier Curves, Fonts or whatever, and uses its own Drawing Thread. All the Event Thread does on paint, is a scaled bit-blt. With the concept of a Graphics Context being almost universal across systems, my hope was that it would get good hardware acceleration. I just can't get my head around how I even go about this in JavaFX. A good demo application is badly needed. Surely someone within the JavaFX developers at Oracle has an idea, or maybe they never considered it? I'm only considering JavaFX because Oracle seem to be deprecating Swing AWT, and clearly have no intention of supporting touch interfaces tablets in Swing. Kind regards, Chris On 24 Jul 2013, at 00:21, Daniel Zwolenski wrote: +1 More specifically I would like to know the official recommended best practices for implementing a CAD style app in JFX. - How best to represent large numbers of complex shapes efficiently, and when to add shapes to the scene (add all and let jfx clip, or manually work out what should be showing, etc) - How best to handle font scaling and image scaling when rendered in a zoomed in/out viewport - How best to do panning and zooming with dynamic level of detail - How best to do the top level display in terms of panes vs regions vs canvas, vs whatever, how to manage overlays and layers (sharing same coordinate space, etc) - How best to do picking, mouse overs, dragging across the 'display' - How best to do infinite or dynamic bounds so you can add and move shapes and the scrolling adjusts accordingly. A JFX diagramming app would make a very powerful demo app in my mind. On 24/07/2013, at 1:47 AM, Chris Gay chris.gay5...@gmail.com wrote: Hello all. Please could someone advise if it is even feasible for me to consider re-factoring the following Swing application, so that it becomes a JavaFX one. From trying to read about JavaFX, I get the feeling that Oracle never intended Java FX for the purpose I need. I have a large Java Swing desktop CAD application which makes heavy use of the Java 2D API, and concurrency. It is a Menu Bar driven application, with a Toolbar for Tools, and a few buttons, but 99% of the user activity concerns selecting and manipulating vector graphical objects in a traditional manner using one Tool at a time (think Inkscape or LibreOffice Drawing apps). The application has multiple drawings open at the same time (but only one is visible), and each Drawing contains it's own Drawing and Processing threads (in addition to sharing the Main and Event Threads), which keeps the Event Thread lively. Each Drawing contains an ArrayList, acting as a Display List of all graphical objects, and each graphical object can be a tree structure. In many cases I use simple iteration instead of Iterators, simply for speed, and to avoid garbage. The graphical objects are lightweight, in that they do not carry references to events and handlers. All they carry is their basic geometric data and properties, a bounding box which they can lend as Read Only, and a boolean flag to indicate selection, which means there can be millions of the objects, with a minimum memory footprint. To support them, there are many hundreds of methods, which the tools interact with. There can be multiple Drawing Windows active on a single drawing, where each Window is backed up by an offscreen image, which handles the zoom and sliding buffer behaviour for fast scrolling, to allow rapid bit-blt's to the actual window. Lastly, the user manipulates the Drawing (Display List), using one of many Tools, where the active Tool receives events from the event queue, and then manipulates selected and/or unselected graphical objects, by using XOR
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: eb0a6b4fece3 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2013-07-24 17:31 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/eb0a6b4fece3 RT-31830 GTK port of Glass not built for embedded Linux targets ! buildSrc/armv6hf.gradle ! buildSrc/armv6sf.gradle ! buildSrc/x86egl.gradle Changeset: 7b249ef11bf7 Author:Daniel Blaukopf daniel.blauk...@oracle.com Date: 2013-07-24 17:39 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/7b249ef11bf7 RT-27616 Set correct system font size on Embedded ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java
Re: Can JavaFX do CAD?
You mention zoom level and bezier curves... I found JavaFX Path drawing combined with zooming and a ScrollPane was pathologically slow (approximately 100 times slower than normal). I filed an issue with a test case: RT-25166 I managed to speed it up a bit by avoiding the use of one of the Group nodes in favour of an AnchorPane, but I still find it slower than I want it to be. I would start with using WriteableImage for your offscreen buffer exactly like you do for Swing. It seems you have too many objects to just throw them all in the scene graph and duplicate your entire model with JavaFX nodes... It will not render fast enough ... My documents are simpler than yours and JavaFX is too slow when my documents get large. Scott On 2013-07-24, at 8:01 AM, Chris Gay chris.gay5...@gmail.com wrote: Hi Daniel, I totally agree with your wishes, and even wonder if it is feasible in JavaFX. With my Swing App, although I support mouse-over sensitivity on things like JButtons, I do not support it on graphical objects, simply because the effort would kill the system, given millions of objects. Only when the mouse is clicked, dragged, or active-up do I provide dynamic visual feedback. I have yet to find anything written about Rubber-banding using a XOR mode graphics context in JavaFX. The way 3D games work has tended to be significantly different to how 2D CAD has worked in the past. I did not want limitations on how far I could zoom-in, so caching bitmaps to represent handles (XOR Mode) at a given scale was ruled-out, since they could be vast. Instead everything is done using Float data (mostly 64 bit Double Float in fact), with some key data, such as handle sizes having to dynamically scale for every new scale, so that they appear as a constant number of pixels. None of this data is parked in the graphical objects, but is held by the Viewport/Drawing Board, and supplied to the active Tool on request. Then everything is a vector draw using a Graphics2D context on the off-screen buffer, whether Bezier Curves, Fonts or whatever, and uses its own Drawing Thread. All the Event Thread does on paint, is a scaled bit-blt. With the concept of a Graphics Context being almost universal across systems, my hope was that it would get good hardware acceleration. I just can't get my head around how I even go about this in JavaFX. A good demo application is badly needed. Surely someone within the JavaFX developers at Oracle has an idea, or maybe they never considered it? I'm only considering JavaFX because Oracle seem to be deprecating Swing AWT, and clearly have no intention of supporting touch interfaces tablets in Swing. Kind regards, Chris On 24 Jul 2013, at 00:21, Daniel Zwolenski wrote: +1 More specifically I would like to know the official recommended best practices for implementing a CAD style app in JFX. - How best to represent large numbers of complex shapes efficiently, and when to add shapes to the scene (add all and let jfx clip, or manually work out what should be showing, etc) - How best to handle font scaling and image scaling when rendered in a zoomed in/out viewport - How best to do panning and zooming with dynamic level of detail - How best to do the top level display in terms of panes vs regions vs canvas, vs whatever, how to manage overlays and layers (sharing same coordinate space, etc) - How best to do picking, mouse overs, dragging across the 'display' - How best to do infinite or dynamic bounds so you can add and move shapes and the scrolling adjusts accordingly. A JFX diagramming app would make a very powerful demo app in my mind. On 24/07/2013, at 1:47 AM, Chris Gay chris.gay5...@gmail.com wrote: Hello all. Please could someone advise if it is even feasible for me to consider re-factoring the following Swing application, so that it becomes a JavaFX one. From trying to read about JavaFX, I get the feeling that Oracle never intended Java FX for the purpose I need. I have a large Java Swing desktop CAD application which makes heavy use of the Java 2D API, and concurrency. It is a Menu Bar driven application, with a Toolbar for Tools, and a few buttons, but 99% of the user activity concerns selecting and manipulating vector graphical objects in a traditional manner using one Tool at a time (think Inkscape or LibreOffice Drawing apps). The application has multiple drawings open at the same time (but only one is visible), and each Drawing contains it's own Drawing and Processing threads (in addition to sharing the Main and Event Threads), which keeps the Event Thread lively. Each Drawing contains an ArrayList, acting as a Display List of all graphical objects, and each graphical object can be a tree structure. In many cases I use simple iteration instead of Iterators, simply for speed, and to avoid garbage. The graphical objects are lightweight, in
Mixing 2D and 3D
Hi Richard, thanks a lot for your detailed reply and the insights into your intentions and ideas. The mailing list members will appreciate being preferentially informed. I think we already do multiple active cameras? More precisely: simultaneous viewing from different points of view into a single 3D scene graph was meant, i.e. several cameras are attached to one scene graph. A SubScene has exactly one camera attached which renders the associated scene graph into the corresponding SubScene's rectangle. Implementing simultaneous viewing requires a cloned 3D scene graph for the second, third, and so on SubScene/Camera. Material, Mesh, and Image objects can be re-used because they are shareable. Animations of Nodes' Transforms seem to be shareable as well. But Transitions (Rotate, Scale, Translate) have to be cloned because they operate on a Node's methods directly. So, simultaneous viewing seems practicable. Key/ mouse / touch / etc should be there already? Scene navigation and model interaction are often the first stumbling blocks for developers with less 3D experience. A ready to go rotate, zoom, and drag support including setting of arbitrary pivot points and adjustment of the camera's clipping planes would overcome one's inhibitions. Node's properties and methods Before I agree with all of your appraisals I would like to gain more experiences with their 3D related implementations. For instance I wasn't successful so far assigning a cursor to a Shape3D or receiving response from any 'setOnMouseXXX' method. August
Fwd: Lambda Expressions Backported to Java 7, 6 and 5
Interesting. If we end up using more Lambda's in FX, there might still be an easy way to maintain the back port to 7. Richard Begin forwarded message: From: Esko Luontola esko.luont...@gmail.com Subject: Lambda Expressions Backported to Java 7, 6 and 5 Date: July 24, 2013 1:40:33 AM PDT To: lambda-...@openjdk.java.net Hi all, Thought you might want to know about this: http://blog.orfjackal.net/2013/07/lambda-expressions-backported-to-java-7.html https://github.com/orfjackal/retrolambda And thanks for developing the lambdas. :) I would just like to know that what is the probability for the implementation of LambdaMetafactory or InnerClassLambdaMetafactory being changed before the GA release of JDK 8? Currently Retrolambda relies on the fact that LambdaMetafactory dynamically generates exactly one class per each invocation of LambdaMetafactory's methods. Also it relies on the naming pattern of the generated lambda class and the synthetic methods in the class containing the lambda. If any of those implementation details change, I'll have to update Retrolambda. -- Esko Luontola www.orfjackal.net
Re: very poor performance on iOS :(
Unfortunately, I'm one of those stuck waiting for the apple developer portal to come back online in order to renew my apple developer subscription, so I can't actually try this out myself. Have you tried running with the perfLogger (I included instructions and how to understand the output in another thread yesterday). If you can show the output from the perf logger that would at least give some guidance as to where the time is being spent. Richard On Jul 24, 2013, at 5:16 AM, Tobias Bley t...@ultramixer.com wrote: Hi, i would like to start a discussion about the performance of JavaFX8 on iOS (via RoboVM). If you make a little app with just one toggle button and run it on iPhone4 (not simulator), the JavaFX rendering is very slow. So the button press is painted with a really noticeable delay. I don’t understand this behavior because I thought JavaFX rendering is very good and optimized using hardware accelerated OpenGL code??? Best regards, Tobi
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
Hello, Richard. These changes fix the problem with dropping frames on Mac because of locking between the render thread and UI thread. I have made some measurements with Controls benchmark and GUIMark2. The numbers without braces is the FPS rendered by Prism and the braced numbers represent how many frames we are actually rendering on the screen. Test Fix No Fix bitmap-1000 76.1 (76.0) 75.3 (44.1) bitmap-3000 38.3 (38.1) 36.9 (31.2) bitmap-5000 23.4 (23.2) 22.6 (18.4) vector 31.6 (31.3) 31.8 (29.0) CheckBox 79(79)67(47) As you could see, with the fix we almost never drop frames, all of them are actually delivered to the screen. Prism performance is improved in some cases too. These are not all the results, just examples to feel the difference. With best regards. Petr. On Jul 24, 2013, at 8:23 PM, Richard Bair richard.b...@oracle.com wrote: The name of the issue is pretty ho-hum, but actually this was a huge amount of work to get finished. Petr, Artem, or Steve, can you give us a run-down of the performance impact of this change on Mac? Thanks Richard On Jul 24, 2013, at 12:32 AM, hang...@oracle.com wrote: Changeset: dd30604ab7d0 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-07-24 11:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd30604ab7d0 RT-26702 Poor DisplacementMap effect performance on Mac Reviewed-by: anthony, art, snorthov ! modules/graphics/src/main/native-glass/mac/GlassEmbeddedWindow+Overrides.m ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.h ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.m ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.h ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.h ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 051ec7d12a9f Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-07-24 11:04 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/051ec7d12a9f RT-31458: Font fallback returned by DirectWrite might not be available to JFX ! modules/graphics/src/main/java/com/sun/javafx/font/PrismFontFactory.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/IDWriteFont.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/OS.java ! modules/graphics/src/main/native-font/directwrite.cpp Changeset: f1be89b0bf87 Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2013-07-24 11:06 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/f1be89b0bf87 RT-31476: Exception when font size is set to 0 ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyph.java ! modules/graphics/src/main/java/com/sun/javafx/font/coretext/CTGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/directwrite/DWGlyphLayout.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/FTFontFile.java ! modules/graphics/src/main/java/com/sun/javafx/font/pango/PangoGlyphLayout.java
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
So this should impact the jitter you would see on mac. What about on Windows, is there any impact there from this change or is it truly just for Mac? Has anybody tried to measure for dropped frames on Windows? Richard On Jul 24, 2013, at 11:31 AM, Petr Pchelko petr.pche...@oracle.com wrote: Hello, Richard. These changes fix the problem with dropping frames on Mac because of locking between the render thread and UI thread. I have made some measurements with Controls benchmark and GUIMark2. The numbers without braces is the FPS rendered by Prism and the braced numbers represent how many frames we are actually rendering on the screen. Test Fix No Fix bitmap-1000 76.1 (76.0) 75.3 (44.1) bitmap-3000 38.3 (38.1) 36.9 (31.2) bitmap-5000 23.4 (23.2) 22.6 (18.4) vector 31.6 (31.3) 31.8 (29.0) CheckBox 79(79)67(47) As you could see, with the fix we almost never drop frames, all of them are actually delivered to the screen. Prism performance is improved in some cases too. These are not all the results, just examples to feel the difference. With best regards. Petr. On Jul 24, 2013, at 8:23 PM, Richard Bair richard.b...@oracle.com wrote: The name of the issue is pretty ho-hum, but actually this was a huge amount of work to get finished. Petr, Artem, or Steve, can you give us a run-down of the performance impact of this change on Mac? Thanks Richard On Jul 24, 2013, at 12:32 AM, hang...@oracle.com wrote: Changeset: dd30604ab7d0 Author:Petr Pchelko petr.pche...@oracle.com Date: 2013-07-24 11:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/dd30604ab7d0 RT-26702 Poor DisplacementMap effect performance on Mac Reviewed-by: anthony, art, snorthov ! modules/graphics/src/main/native-glass/mac/GlassEmbeddedWindow+Overrides.m ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.h ! modules/graphics/src/main/native-glass/mac/GlassFrameBufferObject.m ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.h ! modules/graphics/src/main/native-glass/mac/GlassLayer3D.m ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.h ! modules/graphics/src/main/native-glass/mac/GlassOffscreen.m ! modules/graphics/src/main/native-glass/mac/GlassView3D.m
very poor performance on iOS :(
Please try running with perfLogger and also Instruments. As I've pointed
out before RoboVM is in early stages of development. It doesn't do release
builds yet. Virtually nothing has been done yet to optimize things for
speed. So my guess is that you will find that a lot of time is spent in
RoboVM code. Also, AFAIU the Oracle guys have run this on iOS internally
and have seen decent performance (can someone confirm?). That would also
suggest that RoboVM is the problem at the moment.
/Niklas
On Wed, Jul 24, 2013 at 5:13 PM, Richard Bair
richard.b...@oracle.comjavascript:_e({}, 'cvml',
'richard.b...@oracle.com');
wrote:
Unfortunately, I'm one of those stuck waiting for the apple developer
portal to come back online in order to renew my apple developer
subscription, so I can't actually try this out myself.
Have you tried running with the perfLogger (I included instructions and
how to understand the output in another thread yesterday). If you can show
the output from the perf logger that would at least give some guidance as
to where the time is being spent.
Richard
On Jul 24, 2013, at 5:16 AM, Tobias Bley
t...@ultramixer.comjavascript:_e({}, 'cvml', 't...@ultramixer.com');
wrote:
Hi,
i would like to start a discussion about the performance of JavaFX8 on
iOS (via RoboVM). If you make a little app with just one toggle button and
run it on iPhone4 (not simulator), the JavaFX rendering is very slow. So
the button press is painted with a really noticeable delay. I don’t
understand this behavior because I thought JavaFX rendering is very good
and optimized using hardware accelerated OpenGL code???
Best regards,
Tobi
Re: Drag and drop tabs in TabPane
At present there are no plans to implement this, but that is simply due to the fact that at present our focus is on bug fixing rather than features / tweaks. In other words, if this is a high priority for the community (via votes on the relevant jira issue - which looks like your one at [1]), then we will prioritise it the next time we start up on feature work. Personally I would love to see this too - so I just cast my vote :-) [1] https://javafx-jira.kenai.com/browse/RT-31574 -- Jonathan On 24/07/2013 11:48 p.m., Peter Penzov wrote: Hi, I would like to ask you for which JavaFX version do you plan to implement draggable tabs into TabPane? It will be very useful for users to change the order of the tabs using mouse drag and drop. Best wishes, Peter
hg: openjfx/8/controls/rt: RT-31643: Um-al-qura calendar is not initialized properly when opened for the first time
Changeset: 6d0b751603ce Author:leifs Date: 2013-07-24 13:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6d0b751603ce RT-31643: Um-al-qura calendar is not initialized properly when opened for the first time ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DateCellSkin.java
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
Thank you for the feedback! We decided to drop DEFAULT in favor of
BALANCED. So here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system setting
available that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available that results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic.
After listening to the feedback and an internal discussion, we would
like to propose a minor change to the API for supporting scene
anti-aliasing. We intentionally choose not to expose the number of
samples and techniques used in this release, but this doesn't preclude
future addition when the time is right for more options. This change
will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean
depthBuffer, SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics
driver has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the
moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting
available that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting
available that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting
available that results in best visual quality
}
Thanks,
- Chien
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
Thanks for the help! I was of 2 minds about it; alphabetical or logical.
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
BALANCED, // enables anti-aliasing using optimal system setting available
that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
- Chien
On 7/24/2013 2:49 PM, Richard Bair wrote:
Just to be picky, I would put DISABLED first in the list. It seems more consistent
to have the only OFF mode to be first and then all the rest of the options (which
happen to then have ordinals 0) will be some form of ON mode.
Richard
On Jul 24, 2013, at 2:37 PM, Chien Yang chien.y...@oracle.com wrote:
Thank you for the feedback! We decided to drop DEFAULT in favor of BALANCED. So
here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system setting available
that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic. After
listening to the feedback and an internal discussion, we would like to propose
a minor change to the API for supporting scene anti-aliasing. We intentionally
choose not to expose the number of samples and techniques used in this release,
but this doesn't preclude future addition when the time is right for more
options. This change will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics driver
has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting available
that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
Thanks,
- Chien
hg: openjfx/8/graphics/rt: 2 new changesets
Changeset: 517ebe5062a9 Author:rbair Date: 2013-07-24 15:37 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/517ebe5062a9 RT-31748: Collapse NGNode related classes with only one implementation - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseCacheFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseEffectFilter.java - modules/graphics/src/main/java/com/sun/javafx/sg/prism/BaseNodeEffectInput.java + modules/graphics/src/main/java/com/sun/javafx/sg/prism/CacheFilter.java + modules/graphics/src/main/java/com/sun/javafx/sg/prism/EffectFilter.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGNode.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NGRegion.java ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/NodeEffectInput.java Changeset: aedde4d42307 Author:rbair Date: 2013-07-24 15:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/aedde4d42307 RT-31911: Fix minor issues in CacheFilter discovered via static code analysis ! modules/graphics/src/main/java/com/sun/javafx/sg/prism/CacheFilter.java
hg: openjfx/8/controls/rt: RT-30903: DatePicker: one column separator is a bit thicker when setting showWeekNumbers.
Changeset: d3d8305d165c Author:leifs Date: 2013-07-24 17:23 -0700 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/d3d8305d165c RT-30903: DatePicker: one column separator is a bit thicker when setting showWeekNumbers. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/DatePickerContent.java
jfxrt.jar - is it platform specific?
Obviously there are native libs (dlls, etc) that JFX uses that are outside of the jfxrt.jar. But is the actual jfxrt.jar produced by the build generic and able to be used on any platform (so long as the natives are also present) or is it platform specific itself? We are getting close to the ios/backport stuff working (as well as it can at this stage) and are aiming to start putting stuff in Maven soon. Just want to make sure I get the separations as clean as possible because once it's in Central it doesn't ever leave. Cheers.
Re: API Change Proposal - Re: MSAA and Scene anti aliasing
+1 on having DISABLED be first.
-- Kevin
Richard Bair wrote:
Just to be picky, I would put DISABLED first in the list. It seems more consistent
to have the only OFF mode to be first and then all the rest of the options (which
happen to then have ordinals 0) will be some form of ON mode.
Richard
On Jul 24, 2013, at 2:37 PM, Chien Yang chien.y...@oracle.com wrote:
Thank you for the feedback! We decided to drop DEFAULT in favor of BALANCED. So
here is the revised SceneAntiAliasing enum entries:
public enum SceneAntiAliasing {
BALANCED, // enables anti-aliasing using optimal system setting available
that balances speed and quality
DISABLED, // disables anti-aliasing
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
Thanks,
- Chien
On 7/23/2013 1:29 PM, Chien Yang wrote:
Hi all,
We appreciate all the feedback you have contributed to this topic. After
listening to the feedback and an internal discussion, we would like to propose
a minor change to the API for supporting scene anti-aliasing. We intentionally
choose not to expose the number of samples and techniques used in this release,
but this doesn't preclude future addition when the time is right for more
options. This change will be tracked by RT-31878
(https://javafx-jira.kenai.com/browse/RT-31878):
Anti-aliasing API Change Proposal:
Constructors remove:
public Scene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
boolean antiAliasing)
Constructor add:
public Scene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
public SubScene(Parent root, double width, double height, boolean depthBuffer,
SceneAntiAliasing antiAliasing)
Note:The antiAliasing argument will be used if the underlying graphics driver
has anti-aliasing support.
Where SceneAntiAliasing is an enum with the following entries at the moment:
public enum SceneAntiAliasing {
DISABLED, // disables anti-aliasing
DEFAULT, // enables anti-aliasing using a default system setting available
that balances speed and quality
FASTEST, // enables anti-aliasing using minimum system setting available
that results in better frame rate
NICEST // enables anti-aliasing using maximum system setting available that
results in best visual quality
}
Thanks,
- Chien
Re: jfxrt.jar - is it platform specific?
Yes, jfxrt.jar is platform-specific. On the desktop there are platform-specific glass and Prism classes (not sure about the WebKit classes). On embedded platforms (Linux-arm, IOS, Android) there are many differences. -- Kevin Daniel Zwolenski wrote: Obviously there are native libs (dlls, etc) that JFX uses that are outside of the jfxrt.jar. But is the actual jfxrt.jar produced by the build generic and able to be used on any platform (so long as the natives are also present) or is it platform specific itself? We are getting close to the ios/backport stuff working (as well as it can at this stage) and are aiming to start putting stuff in Maven soon. Just want to make sure I get the separations as clean as possible because once it's in Central it doesn't ever leave. Cheers.
