Re: Thread checks in Glass
Seems as if the ticket isn't public... Sorry for that. Fixed. With best regards. Petr. On Jul 22, 2013, at 1:22 PM, Werner Lehmann wrote: Seems as if the ticket isn't public... On 22.07.2013 11:06, Petr Pchelko wrote: You can follow progress inhttps://javafx-jira.kenai.com/browse/RT-26891
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
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
Hello, Richard. Where did you instrument to measure which frames were actually rendered? Actually, I've made a bit of hacking to get this and my solution is not cross-platform. On Mac each time the [CALayer drawInGLContext] is called we are rendering a frame to the screen. And this is reliable - if we've exited this method the frame must be on the screen. So I've added a counter into this method which calculates the average number of method calls per second and logs it. In production this counter was removed. Of course external tools could be used, like OpenGL profiler, but I suppose that's not what you want. Also, on Mac we have a flag in native which represents if the frame was delivered or not. So, using that flag, it is quite easy to add a logger which would warn you that a frame was dropped. Nothing could be done in Java for this, because we have a complex processing in native code and frame drops happen there. I have no idea how it could be done on other platforms, because I am familiar with this area only on the Mac. With best regards. Petr. On Jul 25, 2013, at 9:24 PM, Richard Bair richard.b...@oracle.com wrote: Hi Petr, We are in a separate thread discussing jitter where being able to measure dropped frames is crucial. We have the PulseLogger class which keeps track of this kind of information (at least, it measures the amount of time spent in a particular pulse). There is a message that sometimes displays about dropping a frame, but I don't know if it captures the same cases as what you have captured here. Where did you instrument to measure which frames were actually rendered? I need a reliable mechanism for measuring jitter. We're not running full speed, so if I'm handling frames at less than 16ms per frame, then I should never see any jitter, unless we have a loss of synchronization between our pulse timer and the display. How can I measure this reliably? Right now we have to just stare at our monitors and see if something looks suspicious. I'd rather have a fool-proof method of determining whether we're hitting each frame right on target. Any ideas? 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
Re: hg: openjfx/8/graphics/rt: RT-26702 Poor DisplacementMap effect performance on Mac
Sorry, I have misspelled the method name. It's drawInCGLContext. It's in native Glass: GlassLayer3D.m line 153. With best regards. Petr. On Jul 25, 2013, at 11:02 PM, Richard Bair richard.b...@oracle.com wrote: Can you point me at the code? I'm in graphics, and I've done a search in the whole of rt and I don't see CALayer drawInGLContext anywhere in the code. (I did both an IDEA case insensitive recursive search and also a grep -r on the command line) Thanks Richard On Jul 25, 2013, at 11:26 AM, Petr Pchelko petr.pche...@oracle.com wrote: Hello, Richard. Where did you instrument to measure which frames were actually rendered? Actually, I've made a bit of hacking to get this and my solution is not cross-platform. On Mac each time the [CALayer drawInGLContext] is called we are rendering a frame to the screen. And this is reliable - if we've exited this method the frame must be on the screen. So I've added a counter into this method which calculates the average number of method calls per second and logs it. In production this counter was removed. Of course external tools could be used, like OpenGL profiler, but I suppose that's not what you want. Also, on Mac we have a flag in native which represents if the frame was delivered or not. So, using that flag, it is quite easy to add a logger which would warn you that a frame was dropped. Nothing could be done in Java for this, because we have a complex processing in native code and frame drops happen there. I have no idea how it could be done on other platforms, because I am familiar with this area only on the Mac. With best regards. Petr. On Jul 25, 2013, at 9:24 PM, Richard Bair richard.b...@oracle.com wrote: Hi Petr, We are in a separate thread discussing jitter where being able to measure dropped frames is crucial. We have the PulseLogger class which keeps track of this kind of information (at least, it measures the amount of time spent in a particular pulse). There is a message that sometimes displays about dropping a frame, but I don't know if it captures the same cases as what you have captured here. Where did you instrument to measure which frames were actually rendered? I need a reliable mechanism for measuring jitter. We're not running full speed, so if I'm handling frames at less than 16ms per frame, then I should never see any jitter, unless we have a loss of synchronization between our pulse timer and the display. How can I measure this reliably? Right now we have to just stare at our monitors and see if something looks suspicious. I'd rather have a fool-proof method of determining whether we're hitting each frame right on target. Any ideas? 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
Re: Swing and JavaFX thread merge
Hello. I've just pushed the fix to the repo, so it should be available in a couple of builds. However, it is an experimental feature, so we lack the documentation or examples on it. If you experience any issues with it - please contact me. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true) It's -Djavafx.embed.singleThread=true With best regards. Petr. On Aug 8, 2013, at 3:50 PM, Artem Ananiev wrote: On 8/8/2013 1:45 AM, Jeff Martin wrote: I thought I was getting this automatically - when I run on my desktop, I can bring up a JOptionPane from a Swing thread and JFXPanels (correctly) block. But when I run from Java Web Start, they don't, and I end up with sporadic SwingUtilities.computeIntersection NullPointerException. Once these two JDK/JavaFX bugs are resolved, scenario with JOptionPane you described will work. As I wrote, it won't work by default in JDK8, you'll need to run your app with certain system property (something like -Djavafx.swing.singlethreaded=true). Is there a secret setting that has a different default with JAWS? NPEs look like a bug, either in AWT/FX, or in your application. I really doubt it's related to Java Web Start. Could you provide a test to reproduce the exceptions, please? Thanks, Artem jeff On Aug 7, 2013, at 5:06 AM, Artem Ananiev artem.anan...@oracle.com wrote: Hi, Pedro Duque Vieira, this is in progress. JDK part is tracked in 8015477: http://bugs.sun.com/view_bug.do?bug_id=8015477 JavaFX part is described in RT-30694: https://javafx-jira.kenai.com/browse/RT-30694 Note that in JDK8/JavaFX8 single-threaded mode will not be a part of public API, it will be an experimental feature. Thanks, Artem On 8/7/2013 2:43 AM, Pedro Duque Vieira wrote: Hi, Some time ago there was a patch submitted which for all purposes merged the swing and javafx thread, making it easier for developers working on a swing/javafx app - http://wiki.apidesign.org/wiki/JavaFX Is this available now (I was under the impression it is)? How do I use it? Thanks in advance,
Re: Glass thread checks
Hello, OpenJFX Team. As you know, the previous attempt to switch on the thread checks have failed. The problems were fixed, so I'm going to enable them again tomorrow morning if nobody objects. With best regards. Petr.
Re: CFV: New OpenJFX Committer: Alexander Zvegintsev
Vote: YES With best regards. Petr. On Aug 15, 2013, at 4:40 PM, Artem Ananiev wrote: I hereby nominate Alexander Zvegintsev (OpenJDK user name: alexz) to OpenJFX Committer. Alexander is a primary maintainer of Gtk port of Glass (windowing toolkit for JavaFX), and also an active contributor to other Glass platforms. Here is the list of Alexander's changes so far: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=zvegintsev Votes are due by Aug 29, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Thanks, Artem [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus
Re: CFV: New OpenJFX Committer: Yao Wang
Vote: YES. With best regards. Petr. On Sep 25, 2013, at 8:01 PM, Artem Ananiev artem.anan...@oracle.com wrote: I hereby nominate Yao Wang to OpenJFX Committer. Yao is a member of JavaFX Graphics team at Oracle. Most of recent Yao's changes are in 3D support code, but not only there: hg log -u Yao Wang Incomplete list of Yao's commits and reviews is also available by the following link: http://hg.openjdk.java.net/openjfx/8/master/rt/log?rev=wang Votes are due by Oct 09, 2013. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Artem
Re: Default methods in JFX-8
Hello, Richard.
Thank you.
What code needs to call these new methods?
These are used in the JFXPanel to provide the needed information to the
AWT/Swing, so that it could properly position the text composition window and
track what is going on with the text.
I don't know enough about the domain to know what other options you have,
besides adding InputMethodRequests2 or whatever and having to do an
instanceof test and cast. But that might actually be the better way to handle
this situation
We could add some internal extension of the interface and use instanceof
checks. It would be done in a single place and would not make a lot of harm.
The only problem with this approach is that third-party text-input component
would not be able to support IM inside the JFXPanel.
So, if you think JFXPanel does not worth adding new public API which is not
required by FX itself I could try to reimplement the feature using some
internal extension.
With best regards. Petr.
On Oct 4, 2013, at 12:00 AM, Richard Bair richard.b...@oracle.com wrote:
I don't think returning 0 from getInsertPositionOffset() or
getCommittedTextLength() is correct, because 0 is a legitimate value to
return from those methods when they're working correctly. How do you
distinguish between a legitimate value of 0, and an illegitimate one? It
seems rather that the defaults could be -1 and null, and that code calling
these methods would understand these values to mean not implemented and
deal accordingly.
I'm thinking here of 3rd party code that calls methods on InputMethodRequest.
Initially of course they won't be calling these new methods, so no change in
behavior for them. However once they start calling these methods, they may
need to be able to distinguish between an implementor that fully implements
InputMethodRequests, and one that doesn't.
It seems like the successful uses of default methods have been when adding
some method that could be implemented in terms of the existing API on the
interface, such that it fits seamlessly into the existing interface as though
it were always there, and where an implementor could create a more efficient
implementation of the method, but doesn't really have to. In this case it
seems like these methods really won't fit well into the existing interface. I
don't know enough about the domain to know what other options you have,
besides adding InputMethodRequests2 or whatever and having to do an
instanceof test and cast. But that might actually be the better way to handle
this situation. What code needs to call these new methods?
Richard
On Oct 3, 2013, at 11:24 AM, Petr Pchelko petr.pche...@oracle.com wrote:
Hello, OpenJFX Community.
There's a question about using Java 8 features in FX.
I've been working on the support for InputMethods in JFXPanel which is an
important feature for many users who speak hieroglyphic languages.
The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248
In order to have a high-quality support we need to change
javafx.scene.input.InputMethodRequests interface and introduce 3 new
methods. This is not needed for pure FX applications right now, but
absolutely required for InputMethods in the JFXPanel. However, the interface
is public and it was present since FX2.0, so changing it would become a
breaking change. So the only way to avoid the problem is using the default
methods. Those would return some stub values, the JDK is OK with that, as it
would not crash or throw exceptions, but text composition would not work
correctly.
I know that we want to avoid using the Java 8 features in the JFX-8, so I
wanted to ask - is it OK to use the default methods here?
Here's the questioned API:
/**
* Returns the offset of the return position in the committed text contained
in the text editing node
*/
default int getInsertPositionOffset() { return 0;}
/**
* Gets the entire text contained in the text editing node except the
uncommitted text.
*/
default String getCommitedText(int begin, int end) {return ;}
/**
* Gets the length of the entire text contained in the text editing node
*/
default int getCommitedTextLength() {return 0;}
Thank you.
With best regards. Petr.
Enabling Glass thread checks
Hello, OpenJFX. FX is a single threaded UI toolkit. Glass (the underlying native window toolkit portability layer for FX) is being changed to ensure it is accessed from the UI thread. You can follow progress in https://javafx-jira.kenai.com/browse/RT-26891 We are reenabling the Glass thread checks ones again. Previous attempts failed, because we've been finding some threading issues, however now all the threading issues have been fixed and we are in a good state to switch on the checks again. The following exception would mean that you've hit a thread check: IllegalStateException(This operation is permitted on the event thread only). In that case please check your threading and if everything seems correct - please contact the Glass team. Thank you. With best regards. Petr.
Re: JFXPanel with WebView in JDK8
Hello, Artem.
This exception is expected, when an old JDK8 build is used.
Actually I suppose it’s a bug, here’s a JIRA for it:
https://javafx-jira.kenai.com/browse/RT-34077
I’ll fix it in a couple of days probably.
With best regards. Petr.
On Nov 6, 2013, at 11:53 AM, Artem Ananiev artem.anan...@oracle.com wrote:
Hi, Lidierth,
what JDK8 version do you run your app? This exception is expected, when an
old JDK8 build is used.
Thanks,
Artem
On 11/5/2013 11:37 PM, Lidierth Malcolm wrote:
NOTE: THIS EXCEPTION OCCURS WITH JDK8, BUT NOT WITH JDK7
public class NewFXMain1 {
public static void main(String[] args) throws InterruptedException,
InvocationTargetException {
EventQueue.invokeAndWait(new Runnable() {
// Create the Swing components on the EDT
@Override
public void run() {
JFrame f = new JFrame();
f.getContentPane().setPreferredSize(new Dimension(500,
500));
f.pack();
f.setVisible(true);
final JFXPanel jfx = new JFXPanel();
f.getContentPane().add(jfx);
// FX Thread
Platform.runLater(new Runnable() {
@Override
public void run() {
WebView browser = new WebView();
WebEngine webEngine = browser.getEngine();
// This is a reference to a web page on the
Waterloo web site
webEngine.load(http://waterloo.sourceforge.net/devwebpage/MathJax/mathjax.html;);
Scene s = new Scene(browser);
jfx.setScene(s);
}
});
}
});
}
}
This gives (Note: using JDK8 and Running from NetBeans 7.4):
Executing
C:\Users\malcolm\Documents\waterloo\Sources\Java\kcl-waterloo-jfx\dist\run1852659813\kcl-waterloo-jfx.jar
using platform C:\Program Files\Java\jdk1.8.0/bin/java
Exception in thread AWT-EventQueue-0 java.lang.NullPointerException
at
javafx.embed.swing.JFXPanel.getInputMethodRequests(JFXPanel.java:744)
at
sun.awt.im.InputMethodAdapter.haveActiveClient(InputMethodAdapter.java:61)
at sun.awt.windows.WInputMethod.activate(WInputMethod.java:285)
at sun.awt.im.InputContext.activateInputMethod(InputContext.java:396)
at sun.awt.im.InputContext.focusGained(InputContext.java:338)
at sun.awt.im.InputContext.dispatchEvent(InputContext.java:245)
at
sun.awt.im.InputMethodContext.dispatchEvent(InputMethodContext.java:196)
at java.awt.Component.dispatchEventImpl(Component.java:4817)
at java.awt.Container.dispatchEventImpl(Container.java:2293)
at java.awt.Component.dispatchEvent(Component.java:4707)
at
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954)
at
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:986)
at
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:610)
at java.awt.Component.dispatchEventImpl(Component.java:4756)
at java.awt.Container.dispatchEventImpl(Container.java:2293)
at java.awt.Component.dispatchEvent(Component.java:4707)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:746)
at java.awt.EventQueue.access$400(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:697)
at java.awt.EventQueue$3.run(EventQueue.java:691)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.awt.EventQueue$4.run(EventQueue.java:719)
at java.awt.EventQueue$4.run(EventQueue.java:717)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:716)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:220)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:135)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:123)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:119)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:111)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)
Review Request: RT-34077 [Graphics, Swing] JFXPanel with WebView in JDK
Hello, OpenJFX community. Please review the fix for the issue: https://javafx-jira.kenai.com/browse/RT-34077 The webrev is available at: http://cr.openjdk.java.net/~pchelko/fx/34077/webrev/ Thank you. With best regards. Petr.
Review Request: RT-34107 [Mac] Cannot set app name for menu items in app menu of system menubar
Hello, OpenJFX Community. Please review the fix for the issue: https://javafx-jira.kenai.com/browse/RT-34107 The details are available in the bug comments. Thank you. With best regards. Petr.
Review Request: RT-34162 [macosx] Regression in Input Method panel positioning
Hello, OpenJFX Community. Please review the fix for the issue: https://javafx-jira.kenai.com/browse/RT-34162 The details about the fix are in bug comments. Thank you. With best regards. Petr.
Review Request: RT-34576 stage.getX()/getY() returns wrong result in applet mode
Hello, OpenJFX. Please review the fix for the issue: https://javafx-jira.kenai.com/browse/RT-34576 The details are available in the bug comments. With best regards. Petr.
Review Request: RT-34770 [TextArea MacOS] selected text is removed on focus leaving then returning
Hello, OpenJFX. Please review the fix for the issue: https://javafx-jira.kenai.com/browse/RT-34770 The details are in the bug comments. With best regards. Petr.
Re: NSView-based embedding on Mac OS X
Hello, Eli. The NSView-based embedding was implemented and is already available in JDK8 EA builds and JDK7u40. Here's the bug which was used to track the changes: https://bugs.openjdk.java.net/browse/JDK-7154778 However, this implementation was designed specifically to support the SWT_AWT bridge and was not intended for other use as it was not tested without SWT. If you still want to use it for some other purposes - please see how it's done in the SWT implementation of the SWT_AWT bridge. It could be found in SWT sources higher than version 4.3 in the class named SWT_AWT. But if you want to use it directly please be aware that it is not a part of the public API and is a subject to change in the future releases. The NSView-base embedding have nothing in common with JavaFX and is not used for JFXPanel or SwingNode. Please contact me if you have any problems. With best regards. Petr. On 20.12.2013, at 7:34, E KN egk...@gmail.com wrote: Back in January 2013, it reported on this list that NSView-based embedded windows on Mac OS X would be supported in JDK8 and maybe even in a future update to JDK7: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-January/005783.html I was wondering if this is still the current plan, as I have not been able to get NSView-based embedding to work on recent versions of JDK7 or early access releases of JDK8. If it still is, is providing NSView-based embedding intended for only JavaFX based applications or even pure Swing applications? Thank you so much in advance, Eli
Re: SceneBuilder Integration in NetBeans
Hello, Sven. Looks like you are not specifying the representation class for the DataFlavor and it defaults to the InputStream. So, scene builder puts a ByteBuffer while the DataTransferer is trying to treat it as an InputStream. Could you please try to explicitly specify the representation class in the DataFlavor you are trying to put? Like this: new DataFlavor(scene.builder/internal; class=java.nio.HeapByteBuffer, SceneBuilder internal DF) With best regards. Petr. On 17.03.2014, at 0:13, Sven Reimers sven.reim...@gmail.com wrote: Ok... figured it out. It seems scene.builder.internal crashes the Swing parsing mechanism for mime types in the data transfer. Changing it to scene.builder/internal fixes this problem. Shall I open an issue in Jira for it? Having fixed this I get another problem :-( (see stacktrace below) Not sure how to fix this... investigating now. -Sven java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to java.io.InputStream at sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1372) at sun.lwawt.macosx.CDataTransferer.translateTransferable(CDataTransferer.java:131) at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86) at java.awt.EventQueue$4.run(EventQueue.java:719) at java.awt.EventQueue$4.run(EventQueue.java:717) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers sven.reim...@gmail.comwrote: Hi guys, hope someone can help me with the exception pasted below. Any idea how to go on from here? The code is available at https://bitbucket.org/sreimers/nbscenebuilder/ Thanks -Sven java.lang.IllegalArgumentException: failed to parse:scene.builder.internal at java.awt.datatransfer.DataFlavor.init(DataFlavor.java:488) at javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors(SwingDnD.java:398) at sun.awt.datatransfer.DataTransferer.getFormatsForTransferable(DataTransferer.java:655) at sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:131) at sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) at java.awt.dnd.DragSource.startDrag(DragSource.java:321) at java.awt.dnd.DragSource.startDrag(DragSource.java:426) at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) [catch] at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- Sven Reimers * Senior Expert Software Architect * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader
Re: SceneBuilder Integration in NetBeans
Ok, I see. This is the problem in FX interop. In javafx.embed.swing.SwingDnD.DnDTransferable class. It's wrapper that wraps the FX dragboard into the Swing Trasferable. It is a simple class and many features are simply not implemented. The implementation is very basic - it just creates the DataFlavor with the mime-type corresponding to the DataFormat mime-type. However it does not take into account the representation class. This works fine for basic types like text or may be image, but it completely does not work for custom types with custom representation classes. You could file a bug for this. With best regards. Petr. On 17.03.2014, at 13:39, Sven Reimers sven.reim...@gmail.com wrote: The problem seems to be in AbstractDragSource in SceneBuilder. It defines a javafx.scene.input.DataFormat. This seems to cause problems if running embedded in Swing. I do not define my own DataFlavors.. Any further help appreciated.. -Sven Am 17.03.2014 09:54 schrieb Petr Pchelko petr.pche...@oracle.com: Hello, Sven. Looks like you are not specifying the representation class for the DataFlavor and it defaults to the InputStream. So, scene builder puts a ByteBuffer while the DataTransferer is trying to treat it as an InputStream. Could you please try to explicitly specify the representation class in the DataFlavor you are trying to put? Like this: new DataFlavor(scene.builder/internal; class=java.nio.HeapByteBuffer, SceneBuilder internal DF) With best regards. Petr. On 17.03.2014, at 0:13, Sven Reimers sven.reim...@gmail.com wrote: Ok... figured it out. It seems scene.builder.internal crashes the Swing parsing mechanism for mime types in the data transfer. Changing it to scene.builder/internal fixes this problem. Shall I open an issue in Jira for it? Having fixed this I get another problem :-( (see stacktrace below) Not sure how to fix this... investigating now. -Sven java.lang.ClassCastException: java.nio.HeapByteBuffer cannot be cast to java.io.InputStream at sun.awt.datatransfer.DataTransferer.translateTransferable(DataTransferer.java:1372) at sun.lwawt.macosx.CDataTransferer.translateTransferable(CDataTransferer.java:131) at sun.awt.datatransfer.DataTransferer$6.run(DataTransferer.java:2380) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86) at java.awt.EventQueue$4.run(EventQueue.java:719) at java.awt.EventQueue$4.run(EventQueue.java:717) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:716) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:159) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) On Sun, Mar 16, 2014 at 8:30 PM, Sven Reimers sven.reim...@gmail.comwrote: Hi guys, hope someone can help me with the exception pasted below. Any idea how to go on from here? The code is available at https://bitbucket.org/sreimers/nbscenebuilder/ Thanks -Sven java.lang.IllegalArgumentException: failed to parse:scene.builder.internal at java.awt.datatransfer.DataFlavor.init(DataFlavor.java:488) at javafx.embed.swing.SwingDnD$DnDTransferable.getTransferDataFlavors(SwingDnD.java:398) at sun.awt.datatransfer.DataTransferer.getFormatsForTransferable(DataTransferer.java:655) at sun.awt.dnd.SunDragSourceContextPeer.startDrag(SunDragSourceContextPeer.java:131) at sun.lwawt.macosx.CDragSourceContextPeer.startDrag(CDragSourceContextPeer.java:88) at java.awt.dnd.DragSource.startDrag(DragSource.java:321) at java.awt.dnd.DragSource.startDrag(DragSource.java:426) at java.awt.dnd.DragGestureEvent.startDrag(DragGestureEvent.java:237) at javafx.embed.swing.SwingDnD.startDrag(SwingDnD.java:284) at javafx.embed.swing.SwingDnD.access$1000(SwingDnD.java:73) at javafx.embed.swing.SwingDnD$4$1.run(SwingDnD.java:249) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311
[8u20] Review Request: RT-36293 [TouchEvent, PopupControl] Using a ListView in PopupControl generates a lot of TouchEvent NPE
Hello, Please review the fix for the issue: https://javafx-jira.kenai.com/browse/RT-36293 Webrev: http://cr.openjdk.java.net/~pchelko/fx/36293/webrev/ With best regards. Petr.
Re: Building OpenJFX on Mac OS X 10.9.2 / XCode 5.1 / XCode 4.3.3
Hello, Philipp. As a quick workaround you can run: sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk FX does-not use any new API’s specific to 10.8, so it would build. At least it works for me. With best regards. Petr. 05 апр. 2014 г., в 1:31 до полудня, Philipp Dörfler phdoerf...@gmail.com написал(а): Hi, just out of curiousity I wanted to build OpenJFX, but although I followed the instructions at https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX I can’t get it to work. gradle 1.8 fails when building :fxpackage:compileLauncher as follows: :fxpackager:compileLauncher clang: warning: no such sysroot directory: '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk' /Users/phi/Documents/workspace/OpenJFX8-rt/modules/fxpackager/src/main/native/launcher/mac/main.m:26:9: fatal error: 'Cocoa/Cocoa.h' file not found #import Cocoa/Cocoa.h ^ 1 error generated. :fxpackager:compileLauncher FAILED I do not have a 10.7 SDK on my 10.9 Mac, but I do have a 10.8 and 10.9: $ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/ MacOSX10.8.sdk MacOSX10.9.sdk According to „the internet™“ I would have to find an old version of Xcode (apparently 4.3.3) because that’s the only way to find an old SDK. As I’m sure that you guys have valid reasons to stick to 10.7 I think it would not hurt to mention this on the wiki page mentioned above stating that one needs XCode not newer than 4.3.3 and that old XCode versions can be downloaded on the Apple Developer website. I would add it myself but as I’m not a contributor I don’t have the required permissions, so all I can do is to ask here for inclusion of that. Thanks! May that be the only obstacle in building JFX8.
Re: Review Request: RT-37788
Hello, Danno.
I’ve noticed that you are leaking userDefaults and expandedOptions objects.
Adding autorelease to them would save you some memory.
With best regards. Petr.
On Jul 3, 2014, at 1:43 AM, Danno Ferrin danno.fer...@oracle.com wrote:
Yes, this has to be fixed in native code. 8u40 it is then.
I can make it cause a crash, but that starts with shooting myself in the
foot, and not much can be done to fix it (by passing in bogus VM arguments).
On Jul 2, 2014, at 3:40 PM, Stephen F Northover
steve.x.northo...@oracle.com wrote:
Personally, I wouldn't change any native code at this point unless it was
fixing a crash. The review is for 8u40, correct?
Steve
On 2014-07-02, 5:38 PM, Chris Bensen wrote:
I’m not sure about for 8u20. Seems fairly straight forward, and your Obj-C
seems as good as any Obj-C. My only complaint at the moment is the
following:
358 if ([pathParts count] 2) {
359 // for 3 or more steps, the domain is first.second.third and
the keys are /first/second/third/, fourth/, fifth/... etc
360 persistentDomain = [NSString stringWithFormat: @%@.%@.%@,
[pathParts objectAtIndex: 0],
361 [pathParts objectAtIndex: 1], [pathParts
objectAtIndex: 2]];
362
363 [dictPath replaceObjectAtIndex: 0 withObject: [NSString
stringWithFormat:@/%@/%@/%@, [pathParts objectAtIndex: 0],
364[pathParts
objectAtIndex: 1], [pathParts objectAtIndex: 2]]];
365 [dictPath removeObjectAtIndex: 2];
366 [dictPath removeObjectAtIndex: 1];
367 } else {
368 // for 1 or two steps, the domain is first.second.third and the
keys are /, first/, second/
369 persistentDomain = @DEFAULT_JAVA_PREFS_DOMAIN;
370 [dictPath insertObject: @ atIndex:0];
371 }
what if [pathParts count] is 0? I’d probably do a switch:
switch ([pathParts count]) {
case 0:
//error
return/break;
case 1:
case 2:
368 // for 1 or two steps, the domain is first.second.third and the
keys are /, first/, second/
369 persistentDomain = @DEFAULT_JAVA_PREFS_DOMAIN;
370 [dictPath insertObject: @ atIndex:0];
default:
359 // for 3 or more steps, the domain is first.second.third and
the keys are /first/second/third/, fourth/, fifth/... etc
360 persistentDomain = [NSString stringWithFormat: @%@.%@.%@,
[pathParts objectAtIndex: 0],
361 [pathParts objectAtIndex: 1], [pathParts
objectAtIndex: 2]];
362
363 [dictPath replaceObjectAtIndex: 0 withObject: [NSString
stringWithFormat:@/%@/%@/%@, [pathParts objectAtIndex: 0],
364[pathParts
objectAtIndex: 1], [pathParts objectAtIndex: 2]]];
365 [dictPath removeObjectAtIndex: 2];
366 [dictPath removeObjectAtIndex: 1];
}
Make sense? Clear as mud?
Chris
On Jul 2, 2014, at 2:15 PM, Danno Ferrin danno.fer...@oracle.com wrote:
Chris, Kevin, Steve,
Please review this fix for RT-37788. Since I am not an objective C any
comments are welcome. Also, please consider if this is too much for an
8u20 fix (the diff is against the current 8u40 codebase).
Webrev: http://cr.openjdk.java.net/~shemnon/RT-37788/webrev.00/
JIRA: https://javafx-jira.kenai.com/browse/RT-37788
—Danno
Re: AWT Dev [9/8u40] Review request for RT-37149 and JDK-8049065 : Implement DnD for SwingNode
Hello, Anthony. The AWT part looks good to me. With best regards. Petr. On Aug 6, 2014, at 9:12 PM, Anthony Petrov anthony.pet...@oracle.com wrote: Anton: thank you for reviewing the fix. All: I need at least one more reviewer for the JDK part of the fix because we're going to back-port the change to 8u40. Could anyone please review it? Artem, Sergey, anyone? For your convenience: https://javafx-jira.kenai.com/browse/RT-37149 http://cr.openjdk.java.net/~anthony/9-5.2/ https://bugs.openjdk.java.net/browse/JDK-8049065 -- best regards, Anthony On 8/5/2014 5:08 PM, Anthony Petrov wrote: Anton, Artem, Steve, Could you please review this fix? -- best regards, Anthony On 7/18/2014 6:44 PM, Anthony Petrov wrote: Hi Petr, Anton, Artem, Steve, Please review the fix at https://javafx-jira.kenai.com/browse/RT-37149 Webrevs: JDK: http://cr.openjdk.java.net/~anthony/9-5.2/ FX: http://cr.openjdk.java.net/~anthony/g-522-swingNodeDnD-RT-37149.3/ JavaFX implements the DragSourceContextPeer and DragGestureRecognizer so that SwingNode content could pose as a drag source. In order to support a drop target, the DropTargetContextPeer is implemented in SwingNode and the add/removeDropTarget() methods register/unregister the drop target listeners. The changes in JDK are mostly technical. We simply delegate the Toolkit.createDragSourceContextPeer() and Toolkit.createDragGestureRecognizer() factory methods to SwingNode. Similarly, we delegate the DropTargetPeer.add/removeDropTarget() operations to SwingNode as well. In FX I've factored out the CachingTransferable class from the SwingDragSource class so as to share the implementation with the SwingNode DnD support. Also I've added a few utility methods to DataFlavorUtils and SwingFXUtils. The main fix is the new code in FXDnD.java which actually implements the AWT interfaces, installs appropriate event handlers on the SwingNode node in FX, and handles all the DnD events. Note that the JDK - FX interface is loose because I use default methods in the LightweightContent interface, so that you can run new FX with the old JDK, or old FX with the new JDK, and nothing should break. Obviously, the DnD in SwingNode will only work if both JDK and FX are patched. I've tested these changes on Windows and Mac with the sample code from this JIRA as well as a JFXPanel DnD test application from RT-34283. The DnD works fine for me in both intra- and inter-process modes. Please post your review comments in JIRA. -- best regards, Anthony
