Re: How to raise JavaFX iOS bugs?
Wtf? Oracle guys, what JVM is this session going to use? https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=5517 On 09/08/2013, at 3:51 PM, Tobias Bley t...@ultramixer.com wrote: Daniel, the question is: Which surprise will Oracle show on JavaOne 2013 in september? Maybe there is something official concerning JavaFX and iOS and Android…? Please take a look a the planned tracks: http://blog.software4java.com/?p=97 One track talks about „JavaSE in AOT mode“…so maybe we do not need such a backport in the future? Because Oracle does not say anything about the future, we don’t know it at the moment ;) Best regards, Tobi Am 09.08.2013 um 00:08 schrieb Daniel Zwolenski zon...@gmail.com: No, I didn't get a chance. Probably easier for you to just raise it now? It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote: Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
Re: How to raise JavaFX iOS bugs?
I have a very good feeling about JavaOne this year. It's now or never for Java/JavaFX on mobiles and tablets and judging by the session titles, I think Oracle is going to make a lot of people very happy :-) On 9 August 2013 16:26, Daniel Zwolenski zon...@gmail.com wrote: Wtf? Oracle guys, what JVM is this session going to use? https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=5517 On 09/08/2013, at 3:51 PM, Tobias Bley t...@ultramixer.com wrote: Daniel, the question is: Which surprise will Oracle show on JavaOne 2013 in september? Maybe there is something official concerning JavaFX and iOS and Android…? Please take a look a the planned tracks: http://blog.software4java.com/?p=97 One track talks about „JavaSE in AOT mode“…so maybe we do not need such a backport in the future? Because Oracle does not say anything about the future, we don’t know it at the moment ;) Best regards, Tobi Am 09.08.2013 um 00:08 schrieb Daniel Zwolenski zon...@gmail.com: No, I didn't get a chance. Probably easier for you to just raise it now? It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote: Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
Re: How to raise JavaFX iOS bugs?
I absolutely agree! Am 09.08.2013 um 09:17 schrieb Felix Bembrick felix.bembr...@gmail.com: I have a very good feeling about JavaOne this year. It's now or never for Java/JavaFX on mobiles and tablets and judging by the session titles, I think Oracle is going to make a lot of people very happy :-) On 9 August 2013 16:26, Daniel Zwolenski zon...@gmail.com wrote: Wtf? Oracle guys, what JVM is this session going to use? https://oracleus.activeevents.com/2013/connect/sessionDetail.ww?SESSION_ID=5517 On 09/08/2013, at 3:51 PM, Tobias Bley t...@ultramixer.com wrote: Daniel, the question is: Which surprise will Oracle show on JavaOne 2013 in september? Maybe there is something official concerning JavaFX and iOS and Android…? Please take a look a the planned tracks: http://blog.software4java.com/?p=97 One track talks about „JavaSE in AOT mode“…so maybe we do not need such a backport in the future? Because Oracle does not say anything about the future, we don’t know it at the moment ;) Best regards, Tobi Am 09.08.2013 um 00:08 schrieb Daniel Zwolenski zon...@gmail.com: No, I didn't get a chance. Probably easier for you to just raise it now? It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote: Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
Re: JavaFX Media issues
On 9/08/2013 03:48, Scott Palmer wrote: I have heard rumors of people being able to play HD video via Canvas. I have tried everything and can't come close. (Yes, I have been careful about the pixel format.) I mean, it looks like it is working for a few seconds, but then as the memory fills with the Canvas backlog it can lead to the GC using a lot more CPU, thus reducing the ability for Canvas to process its command queue even further, well it just collapses in on itself and dies. Is your app able to do *anything* else while the video is playing? The slightest delay to the rendering and that Canvas buffering bug kills the app. Not that it would matter if it could keep up, because the off-screen thing is also a deal breaker. My app is basically just a video watching system -- while video is playing (in the bottom most layer of a StackPane), it shows overlays with time / position, possibly a menu (where you can download a matching subtitle for the video and adjust settings like playback speed and brightness). These overlays are smoothly faded in / faded out just with the opacity property of another Pane that is at a higher level in the main StackPane. None of this is really CPU intensive, nor is there a huge SceneGraph to deal with (I'm guessing its smaller than 100 nodes while video playback is running). See picture here for an idea of what's going on while playback is occuring: https://github.com/hjohn/MediaSystem/blob/master/screenshot-1.jpg The Stage used is a non-transparent one -- I mention this because a transparent change performs a lot worse than a non-transparent one. Before I used the Canvas solution, I'd actually just playback video in a java.awt.Frame with a transparent JavaFX Stage on top. I'd have 2 windows, with the transparent JavaFX Stage on top that would show overlays for the video, while the other window would show the video using java.awt.Canvas, accessed directly by VLC. I do run into this issue every now and then though: https://javafx-jira.kenai.com/browse/RT-23312 It really needs to be fixed or Canvas is simply not safely usable in its current form (and IMHO never has been since its release then). Of course 25fps is well below the 60fps required for full-speed video. I suspect it is the frame rate more than the frame size that matters here. Plain old, standard definition, interlaced, 60 fields per second will probably kill most apps with the current Canvas implementation. I don't think I have aany 60fps video, if you can point me to something I can download that VLC can handle that is of the size you're using I could test with the setup I have here. With 1920x1080 HD Video, the CPU uses 8% according to Task Manager (low-end quad core xeon, about 1 year old). I'm running a standard Java VM (b99), no other tweaking, with default memory settings, 256 MB heap, Task Manager claims a working set of +/- 600 MB, but some native memory might be involved -- when playback stops, working set drops to 340 MB, so there's definitely a lot going on. It's solid though once playback starts (usually it only locks up at the start of playback, if it locks up) and can run for hours. No frame stuttering (I'd notice this immediately on a horizontal pan of one of the test videos I use). Even with a lot of other things going on on the same machine (although not by my Java process) playback stays solid -- I often have this machine running at 50-75% CPU for extended periods while enjoying a Video on the 3rd screen. I'd agree though that more than doubling the frame rate is gonna be a huge impact. I'm not certain if interlaced is going to cause any additional problems, I'm assuming that's handled by VLC and that I'd still be copying a full buffer for each frame (or do you mean 60 FPS interlaced = 120 FPS?). We need something better. I proposed having at least a JNI method so we could get native window handles from Stages but didn't get any traction either. Security was brought up as a concern, which I totally do NOT understand as the use of JNI means you are out of the Java sandbox already. If we had native window handles we might be able get our own window for rendering to at least interact nicely with the Stage. (We already did this successfully in Swing via JAWT and a heavyweight component that we paint to from native code) Getting a WindowHandle for a Stage would be great -- however, I think I actually hacked this in at one point, and then tried playing back video on a JavaFX Stage -- the video however always ended up in the foreground, obliterating any JavaFX rendering. That would need to be solved as well if it is still an issue. I've actually tried almost every video player solution that I could find (all on Windows), including DirectShow (using DSJ), GStreamer-java, MPlayer (in seperate window), VLCJ, MediaPlayer Classic Home Cinema and Xuggler. All of them except VLCJ had severe issues, ranging
hg: openjfx/8/graphics/rt: Android: RT-32218 Add TextField and TextArea skins for Android.
Changeset: 5963868d92d9 Author:tb115823 tomas.branda...@oracle.com Date: 2013-08-09 11:21 +0200 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/5963868d92d9 Android: RT-32218 Add TextField and TextArea skins for Android. ! build.gradle ! buildSrc/android.gradle + modules/controls/src/android/java/com/sun/javafx/scene/control/skin/TextAreaSkinAndroid.java + modules/controls/src/android/java/com/sun/javafx/scene/control/skin/TextFieldSkinAndroid.java + modules/controls/src/android/resources/com/sun/javafx/scene/control/skin/caspian/android.css + modules/controls/src/android/resources/com/sun/javafx/scene/control/skin/modena/android.css ! modules/graphics/src/main/java/com/sun/javafx/application/PlatformImpl.java + netbeans/android/controls/build.xml + netbeans/android/controls/manifest.mf + netbeans/android/controls/nbproject/build-impl.xml + netbeans/android/controls/nbproject/genfiles.properties + netbeans/android/controls/nbproject/project.properties + netbeans/android/controls/nbproject/project.xml
use custom behavior class for TableView
Hi, I would like to use a custom Behavior class for a TableView and so I started as usual with a 'MyTableViewSkin' class which I can activate via the css file. In order to reuse functionality of 'TableViewSkin' and 'TableViewBehavior' I started to let ' MyTableViewSkin' inherit from 'TableViewSkin and planned to let it's constructor simply call the super constructor like this: super(tableView, new MyTableViewBehavior(tableView)); Unfortunately 'TableViewSkin' only defines the constructor 'TableViewSkin(final TableView tableView) ' and thus hides the one from ' TableViewSkinBase ' : TableViewSkinBase(final C control, final B behavior) which makes it impossible to call it. Was this done on purpose and if yes how am I supposed to attach a custom behavior class ? Thanks! Regards, Sven
hg: openjfx/8/controls/rt: 2 new changesets
Changeset: 53570eadb90b Author:David Grievedavid.gri...@oracle.com Date: 2013-08-09 09:20 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/53570eadb90b RT-31691: if css is being reapplied but we're using cached values, force a lookup on properties not in the cache ! modules/controls/src/main/java/javafx/scene/control/Control.java ! modules/graphics/src/main/java/javafx/scene/CssStyleHelper.java ! modules/graphics/src/main/java/javafx/scene/Node.java Changeset: ef2ca9c96bc5 Author:David Grievedavid.gri...@oracle.com Date: 2013-08-09 09:21 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/ef2ca9c96bc5 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt
Re: Mailing list woes
I only noticed because a couple of my posts didn't come back from the list. I've noticed this, too. Perhaps the list is losing things to a junk filter. jeff On Aug 9, 2013, at 7:45 AM, Felix Bembrick felix.bembr...@gmail.com wrote: I am not sure who this is directed at but there seem to be some glitches in the mailing list software that manages this list. I notice that sometimes when I post to this list I do not always get that message being sent to me via the list so I was wondering if I am actually receiving every message that is posted to the list. I compared notes with a friend of mine who also subscribes to this list and we analysed the posts that we had both received over the past week. To both of our surprise we discovered that I received some posts that he never received and vice versa. There does not appear to be any pattern as to which posts make it into our inboxes and which don't. I'd say we are both receiving about 19 out of every 20 messages or slightly less than that. We definitely established that neither of us has received *every* message sent to the list. We have also all but ruled out spam filter issues as this is my Gmail account and all spam goes into the Spam folder and they certainly haven't been ending up in there. Similarly he has a POP3 account and actually has opted to receive *all* spam sent to him which he then uses an Outlook message rule to place it in his Junk folder. Is anyone else experiencing this? If you are, you probably don't realise it. I only noticed because a couple of my posts didn't come back from the list. Felix
Re: How to raise JavaFX iOS bugs?
On 08/08/2013 6:08 PM, Daniel Zwolenski wrote: No, I didn't get a chance. Probably easier for you to just raise it now? See https://javafx-jira.kenai.com/browse/RT-32237 It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote: Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
hg: openjfx/8/graphics/rt: SWT glass: fix defaults to potentially enable live resize on other platforms
Changeset: 4618b11c75f9 Author:snorthov Date: 2013-08-09 10:43 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/4618b11c75f9 SWT glass: fix defaults to potentially enable live resize on other platforms ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
Re: JavaFX Media issues
Forwarded from Kiriil Kirichenko who is getting his mailing list credentials sorted out... *From: *Felix Bembrick felix.bembr...@gmail.com mailto:felix.bembr...@gmail.com *Subject: **JavaFX Media issues* *Date: *August 8, 2013 1:31:37 PM PDT *To: *openjfx-dev@openjdk.java.net mailto:openjfx-dev@openjdk.java.net List openjfx-dev@openjdk.java.net mailto:openjfx-dev@openjdk.java.net I am having a look at JavaFX media support and have a couple of questions: 1. It seems that the only way to load media files is by specifying a source such as a file path etc. This is not going to work well for me as all of my application's content (which includes data, digital assets, media etc.) is stored in a database on the server and is loaded through an IO stream. Why doesn't Media support loading of files through a stream? That would seem like a common use case to me! This is correct. So called arbitrary input stream support is among the features for the future. 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for JDK 8 which I found here: http://download.java.net/jdk8/jfxdocs/index.html Is this just a glitch? A glitch related to javadoc execution. FXMedia is still there. 3. Is buffering of media something planned for the future in JavaFX? What do you mean by buffering ? We have progressive buffer for http links. See MediaPlayer.bufferProgressTimeProperty 4. What about live streaming of media content? We support Http Live Streaming: MpegTS which contains H264 + AAC.
Re: Mailing list woes
Maybe the discuss (http://mail.openjdk.java.net/mailman/listinfo/discuss) mailing list is the right place? Richard On Aug 9, 2013, at 5:45 AM, Felix Bembrick felix.bembr...@gmail.com wrote: I am not sure who this is directed at but there seem to be some glitches in the mailing list software that manages this list. I notice that sometimes when I post to this list I do not always get that message being sent to me via the list so I was wondering if I am actually receiving every message that is posted to the list. I compared notes with a friend of mine who also subscribes to this list and we analysed the posts that we had both received over the past week. To both of our surprise we discovered that I received some posts that he never received and vice versa. There does not appear to be any pattern as to which posts make it into our inboxes and which don't. I'd say we are both receiving about 19 out of every 20 messages or slightly less than that. We definitely established that neither of us has received *every* message sent to the list. We have also all but ruled out spam filter issues as this is my Gmail account and all spam goes into the Spam folder and they certainly haven't been ending up in there. Similarly he has a POP3 account and actually has opted to receive *all* spam sent to him which he then uses an Outlook message rule to place it in his Junk folder. Is anyone else experiencing this? If you are, you probably don't realise it. I only noticed because a couple of my posts didn't come back from the list. Felix
Re: Canvas blowing up (was Re: JavaFX Media issues)
This is a great idea. We should just enter a tweak and do it. If the area that is being cleared is larger than the current size of the canvas, we can throw away all pending draw commands. Steve On 09/08/2013 11:23 AM, Richard Bair wrote: I mean, it looks like it is working for a few seconds, but then as the memory fills with the Canvas backlog it can lead to the GC using a lot more CPU, thus reducing the ability for Canvas to process its command queue even further, well it just collapses in on itself and dies. Forking the thread. The problem with Canvas is that if you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. BUT, if you issue a command to the canvas which will cause it to clear all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area. This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a clear method which is clearRect(0, 0, w, h) to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame. If you're making use of manually operated dirty rects so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come. So we still need a mechanism exposed in the scene graph of liveness and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for your specific media use case this isn't as important. Richard
Re: Canvas blowing up (was Re: JavaFX Media issues)
That's okay for a quick hack. In the case of a video preview surface, I will be explicitly setting the value for every pixel from a ByteBuffer. You could save the extra step of doing a rectFill or clearRect if you knew that every pixel was about to be overwritten. It's a reasonable optimization.. but as a fix for this issue it's still only a half-fix hack. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. No. If pulses are not happening you need to block or force a pulse somehow. Otherwise I don't see how having the unbounded queue is ever going to be 100% reliable. Since we are talking about painting to the Canvas surface as opposed to directly modifying the scene graph, why does the painting have to happen later when a pulse occurs? It's not like you have any other thread writing to the Canvas. Why can't the Platform thread actually *do* the scribbles,and the pulse just refreshes the portion of the Canvas that is visible on the screen? Is it some D3D/OpenGL multi-threading complication? Regards, Scott On Fri, Aug 9, 2013 at 11:43 AM, steve.x.northo...@oracle.com wrote: This is a great idea. We should just enter a tweak and do it. If the area that is being cleared is larger than the current size of the canvas, we can throw away all pending draw commands. Steve On 09/08/2013 11:23 AM, Richard Bair wrote: I mean, it looks like it is working for a few seconds, but then as the memory fills with the Canvas backlog it can lead to the GC using a lot more CPU, thus reducing the ability for Canvas to process its command queue even further, well it just collapses in on itself and dies. Forking the thread. The problem with Canvas is that if you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. BUT, if you issue a command to the canvas which will cause it to clear all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area. This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a clear method which is clearRect(0, 0, w, h) to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame. If you're making use of manually operated dirty rects so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come. So we still need a mechanism exposed in the scene graph of liveness and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for your specific media use case this isn't as important. Richard
Re: Canvas blowing up (was Re: JavaFX Media issues)
We would still do the fill but we could throw away any buffered commands that happened before the fill. Steve On 09/08/2013 12:16 PM, Dr. Michael Paus wrote: What would be the performance penalty for using this quick-fix? The clear/fill commands do not just clear the command buffer. They also fill the canvas area with a certain color. So in normal operation the canvas is always filled twice for each frame, isn't it? Am 09.08.13 17:23, schrieb Richard Bair: I mean, it looks like it is working for a few seconds, but then as the memory fills with the Canvas backlog it can lead to the GC using a lot more CPU, thus reducing the ability for Canvas to process its command queue even further, well it just collapses in on itself and dies. Forking the thread. The problem with Canvas is that if you have a canvas and you scribble on it, and then scribble on it some more, and then scribble on it some more, then in order for us to get the right result in the end, we need to replay all those scribbles in order. If pulses are not happening, we still need to remember these scribbles so we can draw the right result. BUT, if you issue a command to the canvas which will cause it to clear all its contents, then we could throw away any previously buffered data. Right now the only way to do that would be a fillRect with a solid fill where the fillRect encompasses the entire canvas area, or a clearRect where the clearRect encompasses the entire canvas area. This seems like a very simple fix. GraphicsContext.clearRect and GraphicsContext.fillRect should both (under the right conditions) throw away the previously buffered commands. Then all you have to do is be sure to make one of these calls (likely just a clearRect) before each frame, and we'll never buffer more than a single frame's worth of data. We could also add a clear method which is clearRect(0, 0, w, h) to make this more foolproof, and then document it as a best practice to clear the canvas before each rendering if you intend to redraw the entire thing on each frame. If you're making use of manually operated dirty rects so that you only clear the damaged area to repaint, then we couldn't employ this technique and we'd have to buffer 'till kingdom come. So we still need a mechanism exposed in the scene graph of liveness and associated events so that when the scene is no longer live (for example, when minimized) you could stop your animation timer, but for your specific media use case this isn't as important. Richard
hg: openjfx/8/controls/rt: RT-30182 : Indeterminate ProgressIndicators appear to spin anti-clockwise.
Changeset: 2cad03be8d6b Author:mickf Date: 2013-08-09 18:42 +0100 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/2cad03be8d6b RT-30182 : Indeterminate ProgressIndicators appear to spin anti-clockwise. ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/ProgressIndicatorSkin.java ! modules/controls/src/main/resources/com/sun/javafx/scene/control/skin/modena/modena.css
Re: How to raise JavaFX iOS bugs?
Is there going to be an answer on what JVM is going to be used for the JavaOne iOS demo? I'd also like to know what JVM you are testing on for these fixes? On 10/08/2013, at 12:46 AM, steve.x.northo...@oracle.com wrote: On 08/08/2013 6:08 PM, Daniel Zwolenski wrote: No, I didn't get a chance. Probably easier for you to just raise it now? See https://javafx-jira.kenai.com/browse/RT-32237 It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote: Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
Re: How to raise JavaFX iOS bugs?
Please keep filing any bugs you see and add me to the watch list. I do run RoboVM and am able to test there. Thanks, Steve On 09/08/2013 1:54 PM, Daniel Zwolenski wrote: Is there going to be an answer on what JVM is going to be used for the JavaOne iOS demo? I'd also like to know what JVM you are testing on for these fixes? On 10/08/2013, at 12:46 AM, steve.x.northo...@oracle.com wrote: On 08/08/2013 6:08 PM, Daniel Zwolenski wrote: No, I didn't get a chance. Probably easier for you to just raise it now? See https://javafx-jira.kenai.com/browse/RT-32237 It's going to be a pretty big round loop to get ios fixes in. It first needs to go into jfx then needs to be merged into the backport, then that needs to be deployed to maven, then the maven plugin needs to be updated to refer to the new version, then the maven plugin needs to be deployed to maven. I could simplify the last step by allowing the version of jfx backport to be configurable. As I've raised in previous emails, help would be good. I don't suppose any oracle people could be allocated to merging changed into the backport on a regular basis (eg weekly) - even on an unofficial, non-publicly-commited arrangement? On 09/08/2013, at 7:38 AM, steve.x.northo...@oracle.com wrote: Hi Daniel, Did you log a bug for the TextField problem? If you have not done so, please do. If you use iOS: as a prefix for the title of the bug and use iOS as a label, that should help people find iOS related bugs. I have a fix for the problem you are seeing. The text skin thinks that because iOS has touch, it needs to show resize handles in the text field. Steve On 01/08/2013 6:08 PM, Daniel Zwolenski wrote: So now the Maven stuff is working ( http://www.zenjava.com/2013/08/01/javafx-on-ios-using-robovm-and-maven/), I'm gradually starting to muck around with the iOS stuff. There are problems - how do I raise them? Should I log JIRAs? Should I bring them up here, etc? Will you guys start running jfx on iOS now that it's possible and are bug fixes within your allowance to work on given iOS is not a supported platform? For example, in the hello world example, I've included a TextField. When I start typing in it on my iPad the field starts changing size to accommodate the auto-correction popup, which looks very weird. Should I log that as a bug against Controls?
RE: Canvas blowing up (was Re: JavaFX Media issues)
This question was recently asked on StackOverflow as well: http://stackoverflow.com/questions/18097404/how-can-i-free-canvas-memory How can I free Canvas memory? So others have been running into these kind of issues. Also the proposed clear() or empty() option only applies to Canvas correct? i.e. WritableImages don't suffer from these kind of issues and don't require such methods? Regards, John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Richard Bair Sent: Friday, August 09, 2013 9:43 AM To: Dr. Michael Paus Cc: openjfx-dev@openjdk.java.net Subject: Re: Canvas blowing up (was Re: JavaFX Media issues) What would be the performance penalty for using this quick-fix? The clear/fill commands do not just clear the command buffer. They also fill the canvas area with a certain color. So in normal operation the canvas is always filled twice for each frame, isn't it? That would be correct. Another option is to add, instead of clear() an explicit empty() method or something that would just blow away the buffer. Richard
Re: Canvas blowing up (was Re: JavaFX Media issues)
Also the proposed clear() or empty() option only applies to Canvas correct? i.e. WritableImages don't suffer from these kind of issues and don't require such methods? That is correct (WritableImage we don't provide a 2D API to use to fill the buffer, you just bash the pixels yourself however you like, so we don't have to buffer anything up). Richard
RE: JavaFX Media issues
So called arbitrary input stream support is among the features for the future. Could somebody post back a reference to the jira, I've seen the feature referred to from other jiras, but I've never been able to find the actual jira reference for this. Thanks! -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Richard Bair Sent: Friday, August 09, 2013 8:35 AM To: Felix Bembrick Cc: openjfx-dev@openjdk.java.net List Subject: Re: JavaFX Media issues Forwarded from Kiriil Kirichenko who is getting his mailing list credentials sorted out... *From: *Felix Bembrick felix.bembr...@gmail.com mailto:felix.bembr...@gmail.com *Subject: **JavaFX Media issues* *Date: *August 8, 2013 1:31:37 PM PDT *To: *openjfx-dev@openjdk.java.net mailto:openjfx-dev@openjdk.java.net List openjfx-dev@openjdk.java.net mailto:openjfx-dev@openjdk.java.net I am having a look at JavaFX media support and have a couple of questions: 1. It seems that the only way to load media files is by specifying a source such as a file path etc. This is not going to work well for me as all of my application's content (which includes data, digital assets, media etc.) is stored in a database on the server and is loaded through an IO stream. Why doesn't Media support loading of files through a stream? That would seem like a common use case to me! This is correct. So called arbitrary input stream support is among the features for the future. 2. I am unable to locate any reference to JavaFX Media in the JavaDocs for JDK 8 which I found here: http://download.java.net/jdk8/jfxdocs/index.html Is this just a glitch? A glitch related to javadoc execution. FXMedia is still there. 3. Is buffering of media something planned for the future in JavaFX? What do you mean by buffering ? We have progressive buffer for http links. See MediaPlayer.bufferProgressTimeProperty 4. What about live streaming of media content? We support Http Live Streaming: MpegTS which contains H264 + AAC.
Re: JavaFX Media issues
So called arbitrary input stream support is among the features for the future. Could somebody post back a reference to the jira, I've seen the feature referred to from other jiras, but I've never been able to find the actual jira reference for this. Thanks! Here's an umbrella issue that would cover this: https://javafx-jira.kenai.com/browse/RT-14938 Unfortunately the media team is rather starved for resources these days (even more so than in the past). -DrD-
hg: openjfx/8/controls/rt: 2 new changesets
Changeset: b2a8e6dff797 Author:David Grievedavid.gri...@oracle.com Date: 2013-08-09 16:07 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/b2a8e6dff797 RT-32248: if no cascading styles, return empty list ! modules/graphics/src/main/java/com/sun/javafx/css/StyleMap.java Changeset: 6fa61e99aaa4 Author:David Grievedavid.gri...@oracle.com Date: 2013-08-09 16:08 -0400 URL: http://hg.openjdk.java.net/openjfx/8/controls/rt/rev/6fa61e99aaa4 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8.0/scrum/controls/jfx/rt
hg: openjfx/8/graphics/rt: RT-15314 Allow trusted apps to disable the fullscreen overlay warning
Changeset: a05473e09c47 Author:ddhill Date: 2013-08-09 18:08 -0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/a05473e09c47 RT-15314 Allow trusted apps to disable the fullscreen overlay warning ! modules/graphics/src/main/java/com/sun/javafx/tk/DummyToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKSceneListener.java ! modules/graphics/src/main/java/com/sun/javafx/tk/TKStage.java ! modules/graphics/src/main/java/com/sun/javafx/tk/Toolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/GlassViewEventHandler.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/OverlayWarning.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java ! modules/graphics/src/main/java/javafx/scene/Scene.java ! modules/graphics/src/main/java/javafx/scene/input/KeyCombination.java ! modules/graphics/src/main/java/javafx/stage/PopupWindow.java ! modules/graphics/src/main/java/javafx/stage/Stage.java ! modules/graphics/src/stub/java/com/sun/javafx/pgstub/StubToolkit.java
Re: Canvas blowing up (was Re: JavaFX Media issues)
On 9/08/2013 20:15, Richard Bair wrote: Also the proposed clear() or empty() option only applies to Canvas correct? i.e. WritableImages don't suffer from these kind of issues and don't require such methods? That is correct (WritableImage we don't provide a 2D API to use to fill the buffer, you just bash the pixels yourself however you like, so we don't have to buffer anything up). Hm, I didn't realize WritableImage had the same kind PixelWriter interface. For my usecase, where I just render full frames to a PixelWriter so JavaFX can display them in some fashion, why should I not use a WriteableImage instead? Looking at the docs, I see that one limitation is that the WritableImage cannot be resized after construction (something that I do use with Canvas), but I think I could work around that by just recreating the Image when its size changes... I could just wrap a class around it that does this transparently. Going to take a look if I can rip out the Canvas code and replace it with a resizable WritableImage and see what the results are for full screen video playback... --John
