RE: New alias for hg commit notifications?
+1 absolutely -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Philipp Dörfler Sent: Friday, June 27, 2014 3:38 AM To: Ralf Spathelf Cc: openjfx-dev@openjdk.java.net Subject: Re: New alias for hg commit notifications? +1 I'm also filtering them out right now. Cheers, Philipp Am 27.06.2014 um 09:30 schrieb Ralf Spathelf ralf.spath...@aicas.de: +1 I'm currently basically interested in the discussions. Regards, Ralf On 06/24/2014 03:34 PM, Kevin Rushforth wrote: It has been suggested that we create a new alias for Mercurial (hg) commit notifications -- perhaps openjfx-chan...@openjdk.java.net -- rather than sending all of them to the discussion alias. This will facilitate e-mail filtering as well as allow people to opt in or out of getting these notifications separately from being on the discussion alias. What do others think? -- Kevin
RE: Exposing native surface or opengl handle
Here's a link to Steve and Felipe's JavaOne presentation: http://www.parleys.com/play/524ee4dbe4b0ab14e307d7b1/about Integrating JavaFX with Native Technologies This session examines ways that applications can extend JavaFX to use native technologies, with a focus on OpenGL. It's such a great presentation. Some people do such good work. -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Matthias Hänel Sent: Wednesday, June 25, 2014 12:43 AM To: Robert Krüger Cc: openjfx-dev@openjdk.java.net Subject: Re: Exposing native surface or opengl handle Hey all, it's great to have a new thread like this. Robert exactly pointed out what we actually need. I have seen an approach to integrate JFX in JOGL and vice versa. This approach is always been a copying of the pixel buffers between those two frameworks. From my perspective this is not a real good approach because of obvious performance issues. Yesterday, I had a better idea. my idea: I know it is very hard to have JFX exposing a real GLCanvas/Context. I used JOGL for quite some time and I know the JFX rendering pipeline a bit. Please correct me if I am wrong. The most applications need some point to draw. The best pointer would be an exposed FBO from Prism that can be used by Jogl/LWJGL. Additionally we would need a possibility to share the JFX OGL-Context with another one, so we could reuse this FBO in a second window. Okay, this wouldn't needed if I could share textures over scenes. I know there is one major limitation. In windows Prism is using DirectX by default, so there won't be a possible interaction with Jogl. I am sure some DirectX guys really like to have there hands on the surface-layer as well ;) Well, to used the Jogl way above we would also need a stable OGL implementation of Prism for Windows. Last time I tried it it was not even comparable. I am not sure why, but OGL on Mac and Linux works pretty good. Matthias -- Matthias Hänel Geschäftsführer/ Managing Director UltraMixer Digital Audio Solutions Am Waldschlößchen 2 01099 Dresden - i...@ultramixer.com http://www.ultramixer.com Am 23.06.2014 um 17:43 schrieb Robert Krüger krue...@lesspain.de: Thanks a lot for the valuable and very encouraging info! I will track that issue and use that for further communication. Robert On Mon, Jun 23, 2014 at 5:15 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: I'm sorry this thread scrolled away into the bitbucket in the sky. Last JavaOne, we wrote a prototype that showed native integration on OS X. We parented a native sheet dialog in an FX stage and providing an OpenGL node. The code was a prototype that worked only on OS X. The Open GL node allowed drawing JOGL and LWJGL to draw on a texture that was created by FX. This mean that the OpenGL node could take part in FX animations and effects. I will attach the prototype code to https://javafx-jira.kenai.com/browse/RT-36215. I need to find it and make sure that it still compiles and works. This week is M5 RDP2 and today is likely to be a write off for a number of reasons. https://wiki.openjdk.java.net/display/OpenJFX/8u20 Please ping me in the JIRA if the code doesn't show up sometime this week. The prototype is the basis of one possible implementation and needs some work. There are other possible implementations and this is not the final word on the issue. Steve On 2014-06-23, 10:03 AM, Robert Krüger wrote: Sorry, my last reply did not go to the list. That was unintended. Oracle-Team, please someone comment on this, at least on what should be done regarding a Jira Issue (or several ones?) to track any progress on this and collect ideas requirements. Best regards, Robert On Fri, Jun 13, 2014 at 10:41 PM, Robert Krüger krue...@lesspain.de wrote: Thanks for the hint. I think this is similar to what a colleague of mine did a while ago as a proof of concept using other com.sun.api that then went away. As long as we're bundling the JRE with our product and we're desperate enough to get it working, we might do something like this but it's of course just a last resort. Lets hope someone from Oracle says something. On Fri, Jun 13, 2014 at 8:05 PM, Scott Palmer swpal...@gmail.com wrote: That's basically it. It isn't perfect, but its so simple I don't see why it can't be done quickly. We are already talking about using native code to render. That said, com.sun.glass.ui.Window contains the field we want: // Native object handle (HWND, or NSWindow*, etc.) long ptr; You could be evil and hack it now with reflection, but it relies on internal implementation details. In my application I already create a native window for video preview. though not
RE: JavaFX at JavaOne 2014
Yes, apologies for that link, please ignore it, I only read the first part of that article and should have vetted it more closely before relaying. I am academically curious about the concept of ART though, whether JavaFX works with it and if it is better to use a VM style runtime or AOT style variant when targeting deployment of JavaFX to mobile devices. I guessing the current JavaFX Android port would just work out of the box with ART because it is targeting the Dalvik runtime and as far as I understand ART will just take the Dalvik bytecode and compile it to the native device code when an app is installed on the device. -Original Message- From: Scott Palmer [mailto:swpal...@gmail.com] Sent: Monday, June 23, 2014 5:46 PM To: John Smith Cc: Herve Girod; Pedro Duque Vieira; OpenJFX Mailing List Subject: Re: JavaFX at JavaOne 2014 That first article was so wrong about nearly everything mentioned in it that it made me want to vomit. On Jun 23, 2014, at 2:31 PM, John Smith john_sm...@symantec.com wrote: I don't know much about Android, but does it have to be a VM, or could you use ART or an ART equivalent: http://www.extremetech.com/computing/170677-android-art-google-finally-moves-to-replace-dalvik-to-boost-performance-and-battery-life https://source.android.com/devices/tech/dalvik/art.html John
RE: JavaFX at JavaOne 2014
I don't know much about Android, but does it have to be a VM, or could you use ART or an ART equivalent: http://www.extremetech.com/computing/170677-android-art-google-finally-moves-to-replace-dalvik-to-boost-performance-and-battery-life https://source.android.com/devices/tech/dalvik/art.html John -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Herve Girod Sent: Monday, June 23, 2014 8:20 AM To: Pedro Duque Vieira Cc: OpenJFX Mailing List Subject: Re: JavaFX at JavaOne 2014 There are no reasons that JavaFX could not work well on mobile platforms, providing there is a JVM. I was convinced that mobile UI toolkits were very specific, but it's really not the case. Android UI Toolkit has really very few mobile specificities for example. 2014-06-23 16:46 GMT+02:00 Pedro Duque Vieira pedro.duquevie...@gmail.com: People have tried HTML5 as a way to create apps for mobile platforms. Most of the big names who tried this e.g. Facebook have abandoned it. They've abandoned it but not because of the reasons you imply but rather due to HTML5 limitations of providing a good native experience in regards to performance, fluid animations, etc. And also there's a reason why all of them started using HTML5 in the first place: faster delivery time. You only need a code base and with few small adjustments can deliver an app for all mobile platforms. Later you can start concentrating on delivering the best experience on each platform. BTW I don't think JavaFX can fade away given that it's starting from obscurity already ;) Truth is the world lacks a convincing cross platform UI toolkit at the moment: there's Qt, which is fine for C++ but is not so pleasant from other languages, there's Swing, there's HTML5. JavaFX is already undoubtedly one of the best cross platform (desktop cross platform) UI toolkits out there. But that isn't enough as desktop is becoming less and less important. Thanks, On Mon, Jun 23, 2014 at 12:17 PM, Mike Hearn m...@plan99.net wrote: If it is correct that JavaFX won't be supporting iOS or Android (officially), IMO JavaFX will start fading away as soon as there is a reliable technology that can create apps for all platforms. People have tried HTML5 as a way to create apps for mobile platforms. Most of the big names who tried this e.g. Facebook have abandoned it. Personally, I don't care much about JavaFX on Android or iOS because mobile has such different UI requirements and conventions to desktop platforms. I can write a JFX GUI that looks and feels good across Mac/Win/Linux with very little platform specific code because those platforms are all quite similar and anyway, the respective developers of those platforms trained users to expect apps to not fit in perfectly. On mobile, things are different: you can't just use a desktop UI, you need a totally new UI and maybe even feature set built from scratch. On Android the UI toolkit is closely linked with the lifecycle rules. And UI's tend to be a lot more consistent, with the worst offenders being apps that weren't updated to the latest UI conventions yet rather than apps which simply reinvent the look and feel from scratch. I'd actually prefer that Oracle focuses on making a great desktop solution. Hype aside there are still many apps not appropriate for mobiles or tablets. Then with a Java or JVM-language backend I can have just two UI codebases, one for desktop, one for Android and that gets most mobiles. Then RoboVM's Cocoa bindings can be used if need be for iOS. BTW I don't think JavaFX can fade away given that it's starting from obscurity already ;) Truth is the world lacks a convincing cross platform UI toolkit at the moment: there's Qt, which is fine for C++ but is not so pleasant from other languages, there's Swing, there's HTML5. Both Swing and Qt have a reputation for making ugly GUI's. That may or may not be deserved these days, but people remember the history. Plus deployment is horrible. That leaves HTML5, which despite its manifest limitations at least can be made to easily look good via CSS, follow modern fashions, work on everyone's computers and people don't have to download an extra app runtime. So for many apps it's appropriate especially when the bulk of the app logic runs on a server. JavaFX 8, at least based on my experience so far, can be used to make attractive and web-style UIs, thus matching the first of HTML5's capabilities, plus it has the benefit of actually being designed, unlike HTML which just evolved. This leaves deployment as the primary problem. For this reason Danno is my current fav member of the JavaFX team :) Nothing personal guys, I just see cross-platform deployment of *reasonable sized* apps to be the biggest competitive weakness right now.
RE: Blurry strokes and zooming via scale transforms
A couple of related stackoverflow questions won't solve your problem, but will provide some background info: http://stackoverflow.com/questions/16089304/javafx-imageview-without-any-smoothing http://stackoverflow.com/questions/11886230/how-to-draw-a-crisp-opaque-hairline-in-javafx-2-2 http://stackoverflow.com/questions/11881834/what-are-a-lines-exact-dimensions-in-javafx-2 -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Robert Fisher Sent: Thursday, June 12, 2014 3:10 AM To: openjfx-dev@openjdk.java.net Subject: AW: Blurry strokes and zooming via scale transforms Well suppose I have a Rectangle with a size of 100x100 and stroke-width of 1, and I apply a scale transform to zoom in to 150%. Then I would like to see a size of 150x150 pixels and still see a sharp border stroke, let's say with a width of 2 pixels. I'm not sure how I could apply a snapping transformation to just correct stroke widths and not disturb the size of the shapes themselves. Cheers, Rob -Ursprüngliche Nachricht- Von: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] Im Auftrag von Tom Eugelink Gesendet: Donnerstag, 12. Juni 2014 11:42 An: openjfx-dev@openjdk.java.net Betreff: Re: Blurry strokes and zooming via scale transforms I recently had a similar situation, but then because certain properties were calculated-via-binding and the resulting value was not snapped to good values either. This resulted in my suggestion to allow custom calculations in bindings, which would then snap the value. https://javafx-jira.kenai.com/browse/RT-37255 And transformations on such values have the same effect of course. I was wondering, similar to the binding suggestion, would it be possible to apply a snapping transformation as the last transformation? Tom On 2014-6-12 10:56, Robert Fisher wrote: Hi all, I'm trying to avoid the blurry strokes you can get in JavaFX in some cases, e.g. for a non-integer stroke width, or a stroke width of 1 and StrokeType.CENTERED. So far my 'solution' to this problem has been to round layout values to integers, or to round and add 0.5 in the StrokeType.CENTERED case. However this approach is pretty useless if I apply a scale transform afterwards, which is the simplest way I know to create a zooming mechanism. So my question is: is there any way I can round things to integer values *after* transforms have been applied? Or tell the renderer to not try to approximate strokes drawn 'off-pixel' but instead to round move them to the nearest pixel so that lines look sharp and clean? Any tips would be appreciated. Cheers, Rob
RE: Extending a Region to create a JUNG Layout
Much of the internal JavaFX implementation is performed subclassing Region (or Control which is just a Region subclass itself) and overriding layoutChildren, but I'm not aware of any official documentation on the subject other than the sparse stuff in the Javadoc - so no real tutorials. Maybe try studying some of the JavaFX source which extends Region. For example, take a look at Axis: https://bitbucket.org/openjfxmirrors/openjfx-8-master-rt/src/tip/modules/controls/src/main/java/javafx/scene/chart/Axis.java https://bitbucket.org/openjfxmirrors/openjfx-8-master-rt/src/tip/modules/controls/src/main/java/javafx/scene/chart/CategoryAxis.java It would be nice if Oracle or somebody else produced some documentation on this. You could create a feature request in Jira (https://javafx-jira.kenai.com) for such documentation or email the documentation team (javasedocs...@oracle.com), or write a blog or a openjfx wiki article (https://wiki.openjdk.java.net/display/OpenJFX/Main) if you work out some good techniques. John -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Jeffrey Guenther Sent: Thursday, May 29, 2014 11:45 PM To: openjfx-dev@openjdk.java.net Subject: Extending a Region to create a JUNG Layout Hi, I'm in the midst of exploring how I might port JUNG( http://jung.sourceforge.net/index.html) to JavaFX. JUNG is a graph/layout tool my lab uses for some of their data visualizations. With the release of JavaFX 2, we've started building our prototypes in JavaFX. Rather than use the JFXSwingPanel, I want to try modifying the JUNG to work natively in JavaFX. In the long term, I'd like to see JUNG ported completely to JavaFX using properties, CSS and the like. I've built a quick demo ( https://gist.github.com/jrguenther/9d0c37329f9928a2b56e) and need help going forward. I've been reading the docs and hitting google, but I think I need more info. Can someone point me to a detailed explanation of how to extend Region to create my own layout? In particular, how can I get a region to relayout it's children when it's being resized? When does a the region's parent call layoutChildren()? If the height and width of the region are set to Double.MAX_VALUE indicating the area can grow infinitely, how does the region know what size to set itself to? Thanks, Jeff
RE: JavaFX 2 + with LWJGL ( OpenGL )
Hi Exo, For general JavaFX usage questions, stackoverflow or the Oracle JavaFX forums are probably a better place to ask than the openjfx-dev mailing list. See for example: http://stackoverflow.com/questions/18792822/dragging-an-undecorated-stage-in-javafx https://community.oracle.com/community/developer/english/java/javafx/javafx_2.0_and_later Regards, John -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Exo Verse Sent: Monday, April 07, 2014 9:53 AM To: openjfx-dev@openjdk.java.net Subject: Re: JavaFX 2 + with LWJGL ( OpenGL ) Ahh yes, the lwjglfx solution. Yes it is ingenious what they guy did. I would have to draw to an image anyhow with other GUI designs, so this is no different. And with a buffer, you would only need to update it IF the GUI has changed. If no change, then you just use the buffer in OpenGL to paste the GUI image back to the screen in a 3D space instead of worrying about 2D. No need to worry about FPS dropping either. His approach needs work, but the point of his exercise is to prove its doable. I am at another loss though. I am trying to make my window in JavaFX CLICKHOLD and DRAGGABLE.. not a control within it.. The actual window itself. Ideas ? My whole source code in a previous post is there if you want to see what I have so far. Although you will need to make a 800x600 image to get it to work. ( NOTE : Any image for testing purposes would work. ) Torak On Mon, Apr 7, 2014 at 12:47 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: The lwjglfx solution. Steve On 2014-04-07 12:45 PM, Exo Verse wrote: @ Steve Which approach are you referring too ? The lwjglfx solution or this transparency background solution ? The lwjglfx I am assuming here since its drawing out to an image and back in again. But if your speaking about my transparency issue I solved, I didn't realize it was sending out to an image and back again. Could you please elaborate as to which solution your speaking about ? Torak On Mon, Apr 7, 2014 at 12:33 PM, Stephen F Northover steve.x.northo...@oracle.com wrote: This solution is cool, but it draws to an image, sucks out the bits and then converts that to an FX image. This is a good approach because it uses API and does not rely on any internals of FX. Hopefully it is fast enough for you. Steve On 2014-04-06 12:41 PM, Exo Verse wrote: Yea the OpenGL comes with your graphics drivers for your video card. So your correct that it doesn't ship with JavaFX. What I have been going on about is trying to find a way to use JavaFX with LWJGL. In case you are unaware, LWJGL just means Light Weight Java OpenGL and its a wrapper for the OpenGL API. It's an alternative to JOGL. On another note, as I did a search, Thanks to Tom showing me that link I examined that code and I found something of interest in the JOGL code interface.. well it lead me to a google search, and viola.. LWJGL with JavaFX. :) LINK : https://github.com/Spasi/LWJGL-FX So just wanted to post the link here and say thanks for all of your help. :) Cheers, Torak On Sun, Apr 6, 2014 at 12:35 PM, Tom Schindl tom.schi...@bestsolution.at wrote: JavaFX does not ship OpenGL binaries on windows you have to build it your own. Please note: a) if there are people who manage to write a prism pipeline on jogl why should you not be able to do the same with lwjgl? b) the talk i mentionned from felipe and steve show how to get access to the native OpenGL context and there from you can use any API you like can't remember which one they used Tom Von meinem iPhone gesendet Am 06.04.2014 um 18:18 schrieb Exo Verse tora...@gmail.com: Thanks, but as I mentioned in my original post, I don't like JOGL. It doesn't work with my setup. I use LWJGL because its only about the OpenGL and not other libraries, and its an easy API wrapper to use. There are many many reason I hate JOGL.. but this thread is not about hating on JOGL, its about finding a way to use LWJGL with JavaFX2+. Also, Win32 API calls can use both DirectX and OpenGL APIs. And it doesn't matter what Windows OS you're using. I have tested this out from Windows XP all the way to Windows 7 - 32/64 Bit with no problem. Cheers Torak On Sun, Apr 6, 2014 at 11:52 AM, Tom Schindl tom.schi...@bestsolution.atwrote: There is a talk from Felipe and Steve at J1 last year how to embed OpenGL into FX using *internal* API! Search for it on parleys - this does not help you on Win32 which uses directx instead of javafx. BTW there are people doing a JOGL pipeline https://bitbucket.org/dejayberlin/joglfxpipeline/src! Tom Von meinem iPhone gesendet Am 06.04.2014 um 17:25 schrieb Exo Verse tora...@gmail.com: Yea its a shame that using JavaFX as an option along with OpenGL wasn't even thought of to begin with. I don't understand why
RE: JavaFX 2 + with LWJGL ( OpenGL )
Sorry, I should have worded my email better, my intent was only to advise that for high level API usage questions, IMO you will probably get the best answers on StackOverflow (and many things are answered there already). Agreed that the low level discussion things affecting implementation are good here (especially anything specific to the direct LWJGL/OpenGL/JavaFX integration). From: Mario Torre [mailto:neugens.limasoftw...@gmail.com] Sent: Monday, April 07, 2014 1:33 PM To: John Smith Cc: openjfx-dev@openjdk.java.net; Exo Verse Subject: RE: JavaFX 2 + with LWJGL ( OpenGL ) I don't know, most of this thread is about things that seems low level enough to warrant a discussion on this list, we can forgive one or two usage related questions, no? Cheers, Mario Il 07/apr/2014 22:11 John Smith john_sm...@symantec.commailto:john_sm...@symantec.com ha scritto: Hi Exo, For general JavaFX usage questions, stackoverflow or the Oracle JavaFX forums are probably a better place to ask than the openjfx-dev mailing list. See for example: http://stackoverflow.com/questions/18792822/dragging-an-undecorated-stage-in-javafx https://community.oracle.com/community/developer/english/java/javafx/javafx_2.0_and_later Regards, John -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.netmailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Exo Verse Sent: Monday, April 07, 2014 9:53 AM To: openjfx-dev@openjdk.java.netmailto:openjfx-dev@openjdk.java.net Subject: Re: JavaFX 2 + with LWJGL ( OpenGL ) Ahh yes, the lwjglfx solution. Yes it is ingenious what they guy did. I would have to draw to an image anyhow with other GUI designs, so this is no different. And with a buffer, you would only need to update it IF the GUI has changed. If no change, then you just use the buffer in OpenGL to paste the GUI image back to the screen in a 3D space instead of worrying about 2D. No need to worry about FPS dropping either. His approach needs work, but the point of his exercise is to prove its doable. I am at another loss though. I am trying to make my window in JavaFX CLICKHOLD and DRAGGABLE.. not a control within it.. The actual window itself. Ideas ? My whole source code in a previous post is there if you want to see what I have so far. Although you will need to make a 800x600 image to get it to work. ( NOTE : Any image for testing purposes would work. ) Torak On Mon, Apr 7, 2014 at 12:47 PM, Stephen F Northover steve.x.northo...@oracle.commailto:steve.x.northo...@oracle.com wrote: The lwjglfx solution. Steve On 2014-04-07 12:45 PM, Exo Verse wrote: @ Steve Which approach are you referring too ? The lwjglfx solution or this transparency background solution ? The lwjglfx I am assuming here since its drawing out to an image and back in again. But if your speaking about my transparency issue I solved, I didn't realize it was sending out to an image and back again. Could you please elaborate as to which solution your speaking about ? Torak On Mon, Apr 7, 2014 at 12:33 PM, Stephen F Northover steve.x.northo...@oracle.commailto:steve.x.northo...@oracle.com wrote: This solution is cool, but it draws to an image, sucks out the bits and then converts that to an FX image. This is a good approach because it uses API and does not rely on any internals of FX. Hopefully it is fast enough for you. Steve On 2014-04-06 12:41 PM, Exo Verse wrote: Yea the OpenGL comes with your graphics drivers for your video card. So your correct that it doesn't ship with JavaFX. What I have been going on about is trying to find a way to use JavaFX with LWJGL. In case you are unaware, LWJGL just means Light Weight Java OpenGL and its a wrapper for the OpenGL API. It's an alternative to JOGL. On another note, as I did a search, Thanks to Tom showing me that link I examined that code and I found something of interest in the JOGL code interface.. well it lead me to a google search, and viola.. LWJGL with JavaFX. :) LINK : https://github.com/Spasi/LWJGL-FX So just wanted to post the link here and say thanks for all of your help. :) Cheers, Torak On Sun, Apr 6, 2014 at 12:35 PM, Tom Schindl tom.schi...@bestsolution.atmailto:tom.schi...@bestsolution.at wrote: JavaFX does not ship OpenGL binaries on windows you have to build it your own. Please note: a) if there are people who manage to write a prism pipeline on jogl why should you not be able to do the same with lwjgl? b) the talk i mentionned from felipe and steve show how to get access to the native OpenGL context and there from you can use any API you like can't remember which one they used Tom Von meinem iPhone gesendet Am 06.04.2014tel:06.04.2014 um 18:18 schrieb Exo Verse tora...@gmail.commailto:tora...@gmail.com: Thanks, but as I mentioned in my original post, I don't like JOGL. It doesn't work with my setup. I use LWJGL because its only about the OpenGL
RE: Expected frame rates for a full-screen blur
Sounds like your issue isn't in fact the blur, but, if it were, some things suggestions are: 1. BoxBlurs are more efficient than GaussianBlurs: http://en.wikipedia.org/wiki/Box_blur 2. Apply some of the suggestions from the openjfx Performance Tips and Tricks page: https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks Anecdotally, applying the Performance Tips and Tricks allowed smooth animations on a 2012 MacBook Air with a full-screen blur. -Original Message- From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Jeff Martin Sent: Tuesday, April 01, 2014 11:17 AM To: Mike Hearn Cc: openjfx-dev@openjdk.java.net Subject: Re: Expected frame rates for a full-screen blur I assume retina optimization was added for JFX 8 (or is on the short list). I think there is a Jira for it. You can choose a non-retina resolution by going to display preferences and clicking the Scaled radio button and selecting something to the right of Best Resolution (Retina). It used to be that you could option-click the Scaled radio button to get a real list of choices, but now you can only get that with a 3rd party resolution tool (I think). jeff On Apr 1, 2014, at 12:49 PM, Mike Hearn m...@plan99.net wrote: How do I do that? And won't that make everything blurry? Retina support is one reason why I chose JFX. Swing on Retina Macs is pretty much unusable, it's like looking through thick plastic. On Tue, Apr 1, 2014 at 7:26 PM, Jeff Martin j...@reportmill.com wrote: If it's a MacBook Pro Retina, you might try it with and without retina level resolution. I haven't tested JavaFX 8 with retina, but JFX 7 had serious problems that would go away when I changed the display to non-retina. jeff On Apr 1, 2014, at 11:41 AM, Mike Hearn m...@plan99.net wrote: Actually, playing some more, it seems like the poor frame rates I'm seeing are not blur related, but rather affect any animation (i.e. all rendering) when my main window is maximized. Shrinking the window so it's smaller results in smooth animations of any kind. This seems to be true no matter how I try and simplify my scene (e.g. turning off a tiled background image). I grabbed Ensemble and tried the circle blur demo. It actually made my entire laptop unusable. The entire OS crawled to a halt and fps was maybe 0.3 for everything, not just the Java app. Going back to the main menu made things snappy again. This is a bit disconcerting. Does anyone else see such appalling performance impact from the blurred circles demo on their Mac? Is this a driver issue, perhaps? Are there any platforms where this demo hits a good fps? On Tue, Apr 1, 2014 at 6:10 PM, Mike Hearn m...@plan99.net wrote: Hi there, On a MacBook Pro with OS X 10.9.2, does anyone have any estimates for anticipated frame rates of a full-screen animated blur? I noticed that when my window is not maximized, the blur is smooth and high frame-rate. When maximized the blur is somewhat choppy. Unfortunately I have no clue how much work is really involved in GPU blurring and whether I'm being unreasonable to expect that many pixels to be blurred per second (this is on a retina display). Can anyone let me know if it's worth me trying to optimise this or whether hardware limitations will mean that realistically I am expecting too much. thanks!
RE: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end]
Monocle is a very interesting and exciting development for the JavaFX team. I think that it is an avenue of approach which may help enable the development of various innovative solutions, both in providing access to JavaFX applications through traditional web UIs or providing remote GUI access to myriad small devices which make up the Internet of Things. Ø Since WebSockets are part of Java EE I don't think this is something that could be part of the standard JavaFX build Yes, I agree. There are some excellent existing WebSocket solutions for Java, such as Tyrus https://tyrus.java.net/ and Kaazing. Though the WebSocket protocol is simple to users, there are many tricky pitfalls in creating a robust WebSocket server, so using those complete and well-tested solutions is the best route. As the client app would actually be installed on the server much like a normal JEE app, using a standard JEE lib is perfectly appropriate I think. The tricky part (at least for me) would be to take the VNC (or OpenGL) commands and tunnel them through a WebSocket system. Anyway, something to think about in my spare time. Thanks a lot for the replies and posting to the list Daniel. John From: Daniel Blaukopf [mailto:daniel.blauk...@oracle.com] Sent: Tuesday, January 21, 2014 2:45 PM To: John Smith; openjfx-dev@openjdk.java.net Subject: Re: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end] Hi John, On 01/22/2014 12:24 AM, John Smith wrote: Would it be possible to develop a web based VNC client rendering to HTML canvas that connects to the Monocle VNC server over WebSockets such as that discussed in Kanaka’s answer here: http://stackoverflow.com/a/3902817/1155209? I’m just interested in the feasibility of the approach as a basis for future development of a potential 3rd party JavaFX app deployment solution outside of JavaFX core. I understand that this is probably not the primary reason the Monocle VNC work was implemented, but I’m curious if it could be repurposed for this mechanism. Essentially, my goal here is to enable AppStreaming JavaFX http://aws.amazon.com/appstream/ without requiring a proprietary amazon solution. In your opinion, would such a solution be a feasible basis for developing a distribution mechanism for JavaFX applications which does not require anything on the client outside of an HTML5 compliant browser? It would absolutely be feasible, although the lag would probably be annoying. Since WebSockets are part of Java EE I don't think this is something that could be part of the standard JavaFX build, but Monocle allows for pluggable screen implementations and it shouldn't be much work to modify VNCScreen.java to do this. Alternatively we could put just enough of an implementation of WebSockets in VNCScreen to be able to talk to the browser directly. From http://www.websocket.org/aboutwebsocket.html the protocol doesn't look complicated. Unless you need a secure authenticated connection of course, in which case the answer would have to be Java EE. However, what would be 100x better in terms of perfomance would be to stream the OpenGL commands to a WebGL client. We'd still have the lag though. We did an experiment for a few days last month in the JavaFX team with marshalling up OpenGL calls into a stream and sending them down the wire to a client doing the rendering on another device, and the performance looked promising. A bit like http://sourceforge.net/projects/virtualgl/, but without the video stream. Thanks, Daniel Thanks, John From: Daniel Blaukopf [mailto:daniel.blauk...@oracle.com] Sent: Tuesday, January 21, 2014 12:53 PM To: John Smith; openjfx-dev@openjdk.java.netmailto:openjfx-dev@openjdk.java.net Subject: Monocle with VNC [was: Re: openjfx/8u-dev/rt: RT-35441 [Monocle] Provide a VNC back-end] Hi John, This is a mostly complete implementation of Glass that instead of rendering to the screen, renders to an offscreen buffer and serves the buffer up to clients using the RFB protocol. So you should be able to connect to it with most VNC clients, although I haven't been able to get it to work with desktop sharing on the Mac. You can also provide mouse input to JavaFX using the VNC client. To use (BTW, this is noted in the JIRA https://javafx-jira.kenai.com/browse/RT-35441): Run with: -Dglass.platform=Monocle -Dmonocle.platform=VNC -Dprism.order=sw Connect with a VNC client to port 5901. I used TigerVNC (http://sourceforge.net/projects/tigervnc/files/) since the OS X desktop sharing client didn't like the 15-year old version of the RFB protocol that VNCScreen.java implements. As noted in the JIRA, I think it would make sense to do what Dave Hill previously did in Lens and make the VNC server an option in all embedded back-ends instead of requiring the user to make a choice between having a local display or a remote display. So there would be Linux framebuffer with a VNC server option, EGL
RE: javafxpackager and launcher
Hi Danno, It's really great to see someone paying close attention to the packaging and deployment stuff, this level of effort has been sorely missed since Igor and Daniel left. Thanks for the contributions. John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Danno Ferrin Sent: Friday, January 10, 2014 9:11 AM To: Scott Palmer Cc: openjfx-dev@openjdk.java.net Subject: Re: javafxpackager and launcher I came on board working on the packager stuff last month. Nearly all of the design decisions for this were made before I came on board, but I will do my best to explain it. On Wed, Jan 8, 2014 at 8:20 PM, Scott Palmer swpal...@gmail.com wrote: The Java 8 java.exe launcher is now JavaFX aware in that it will launch JavaFX Applications that don't have a main(String []) method. The javafxpackager uses it's own launcher when creating a native package. Are there plans to unify those launchers? I noticed a comment under future work in WinLauncher.cpp that says Reuse code between windows/linux launchers and borrow more code from java.exe launcher implementation. The bundler also does a bit more to the JRE as well than just play with the launcher, files not required for redistribution are stripped out wholesale. The web plugin is stripped out, platform specific integrations are stripped out (like the activeX bridge), and every single command line binary entry point is also stripped out (such as rmid, corba services, as well as java.exe and javaw.exe) So we are already do some very non-standard (but legal for re-distribution) things to the JRE. I'm wondering why not make java.exe the only launcher we need. (Or the javaw.exe variant) I think would mainly be an issue of adding package.cfg parsing and picking up the embedded runtime. This would require a JEP at the least, and approval from the JSR process since we would be altering a standardized entry point. The cost/benefit goes down quick. An application bundle mode could probably be triggered via the contents of a resource that is injected much like the custom icon is injected into the fx launcher (I'm not sure if something needs to be done for preloader support too. I think the embedded launcher stub handles that on Java 7, but I believe it isn't used on JavaFX 8. One of the advantages of our own launcher (as you point out later in your mail) is we can customize the launcher. Put a custom icon on, and (potentially) load up custom meta-data to the executable, and maybe even sign it (we don't sign it today). Tweaking the existing Java.exe in this manner on windows could be problematic. Pre-loader may be handy, but we haven't seen any requests for it yet for app bundles. Post a bug if you would find it useful. I have been using a standard java.exe launcher from Java 7 for my apps and hacked jfxrt.jar onto the classpath manually. I do this for a couple reasons. One because the same app could launch in a Swing or JavaFX mode while we were transitioning our UI. Two, because we install a private JRE that is shared among multiple apps and services that make up our product and javafxpackager only supports the default system-wide JRE or a JRE embedded into the application bundle. It's a bit too limited... though after looking at the launcher source, I think I can fool it by making a runtime directory symlink inside the app bundle folder that points to our company-private JRE. I see you posted RT-35215 to address this. Are we talking just windows or windows/mac/linux? We do have a mechanism that isn't widly publicized for userJVMArgs, basically where you can store per-execution jvm args in a file in the app directory. We could include a hook to add a custom JVM home and rely on the installer to set it correctly. I just started experimenting with the javafxpackager and I noticed that the .exe that is created could, and probably should, have more things customized in the resources. If you get properties on the file in Windows and look at the Details tab, things like Product name and Version are not filled in. The project has a Title, a Vendor, Description and Implementation Version, etc. I believe those are used for JNLP deployment. It would be nice to have those details injected into the .exe just like the icon is. Should I create an issue for that? We should populate those, please post a JIRA. I'm also curious about the installation location when making a .msi package. Instead of Program Files/AppName or Program Files/Vendor/AppName it goes to the user-specific App-Data folder. This is almost never what a typical Windows user would want or expect. I understand it is probably to avoid permission issues, but the installer really should have had the option to do a per-machine install. This page http://docs.oracle.com/javafx/2/deployment/deploy_quick_start.htm
RE: [announce] InhiBeans: mitigate redundant recalculations
Perhaps reactive programming is different from the problem Tomas is solving,
but I think a research project which combined some of the principles of
functional reactive programming
(http://lampwww.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf) with JavaFX
properties using Java 8 lambdas and streams would be quite interesting and
perhaps very useful.
John
-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tomas Mikula
Sent: Monday, December 16, 2013 9:19 AM
To: Richard Bair
Cc: openjfx-dev@openjdk.java.net
Subject: Re: [announce] InhiBeans: mitigate redundant recalculations
As a matter of fact, I have. Only to the extent of the Principles of Reactive
Programming [1] course that is currently in progress on Coursera. From what I
have seen so far, it's all about asynchronous composition (with emphasis on
both asynchronous and composition).
I didn't see it addressing this specific problem of multiple redundant updates,
but I might be wrong. The truth is, this problem doesn't even exist if you
don't have any eager observers (i.e. when you don't ever attach any
ChangeListeners, and InvalidationListeners only propagate invalidation and
never require the value to be recomputed). The problem is, although you can
design your component without any eager evaluation (JavaFX bindings are already
composed this way), you then bind a Label.textProperty() to the end of a
binding chain and it all becomes eager.
Regards,
Tomas
[1] https://www.coursera.org/course/reactive
On Mon, Dec 16, 2013 at 5:30 PM, Richard Bair richard.b...@oracle.com wrote:
Have you looked at https://github.com/Netflix/RxJava by chance? I've been
dying to see somebody do an RxJava in JavaFX ever since devoxx and it looks
like you may have inadvertently started down that path :-).
Richard
On Dec 16, 2013, at 8:09 AM, Tomas Mikula tomas.mik...@gmail.com wrote:
On Mon, Dec 16, 2013 at 1:47 AM, Tomas Mikula tomas.mik...@gmail.com wrote:
On Mon, Dec 16, 2013 at 1:07 AM, Scott Palmer swpal...@gmail.com wrote:
Interesting, no worse than John's pattern though.
I thought of using a try/finally to make sure release was called
and that naturally lead to thinking of try-with-resources, where
the resource in this case is a binding of some sort (or a wrapper
around a binding) that is invalidated on close() if needed.
That is an interesting idea. I didn't intend blockWhile() to be safe
with respect to exceptions, but merely
void blockWhile(Runnable r) {
block();
r.run();
release();
}
Enhancement you are suggesting could be fleshed out as block()
returning an AutoCloseable and the usage would be
try(AutoCloseable a = relaxedArea.block()) {
obj.setWidth(w);
obj.setHeight(h);
}
OK, done. I implemented both:
1. added the blockWhile() method;
2. made bindings AutoCloseable, and block() returns `this`.
Tomas
RE: Reloading stylesheets
And in general if there were some performance guidelines for JavaFX that would be really helpful. There is an open-jfx wiki page for JavaFX Performance Tips and Tricks, you could check that and see if it is helpful (if it's not maybe you could edit it and add a new section on performance issues you would like to see discussed or documented): https://wiki.openjdk.java.net/display/OpenJFX/Performance+Tips+and+Tricks There are some JavaOne presentations on Performance topic: http://www.youtube.com/watch?feature=player_embeddedv=ddJpDi5SWFc http://parleys.com/play/514892290364bc17fc56c3c5/chapter26/about John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Mark Fortner Sent: Tuesday, December 10, 2013 9:39 AM To: openjfx-dev@openjdk.java.net Subject: Fwd: Reloading stylesheets It would be nice if there were some documentation for how to get around the memory leak in stylesheets in 7x (since most of us won't be upgrading to 8 until it's actually released). And in general if there were some performance guidelines for JavaFX that would be really helpful. There was some mention of when (and when not) to use *Platform.runLater*. Avoiding memory leaks in multi-threaded code, guidelines for threadpool tuning so that apps stay responsive, etc. The Best Practiceshttp://docs.oracle.com/javafx/2/best_practices/jfxpub-best_practices.htm document provides a start but more details would be useful. Cheers, Mark -- Forwarded message -- From: Werner Lehmann lehm...@media-interactive.de Date: Tue, Dec 10, 2013 at 9:03 AM Subject: Re: Reloading stylesheets To: Cc: openjfx-dev@openjdk.java.net openjfx-dev@openjdk.java.net Makes sense. Thanks! On 10.12.2013 17:09, David Grieve wrote: The way it works in 8.0 is that there is a cache of loaded stylesheets. [...]
RE: 8 post-commit review request: RT-19968: Document that Platform.runLater must not be called before FX is initialized
The comments around application runtime initialization seem like they belong
more properly in the application lifecycle javadoc for the Application class
rather than on the Platform.runLater method specifically, though I do see how
the runtime initialization cuts across multiple classes
(Application/JFXPanel/FXCanvas, etc), so perhaps it is OK having the
description where it is (lacking some better place to put it). Useful
information though, thanks for including it.
+ *For standard JavaFX applications that extend
+ * {@see Application}, and use either the Java launcher or one of the
+ * launch methods in the Application class to launch the application,
+ * the FX runtime is initialized by the launcher before the Application
+ * class is loaded.
+ * For Swing applications that use JFXPanel to display FX content, the FX
+ * runtime is initialized when the first JFXPanel instance is constructed.
+ * For SWT application that use FXCanvas to display FX content, the FX
+ * runtime is initialized when the first FXCanvas instance is constructed.
-Original Message-
From: openjfx-dev-boun...@openjdk.java.net
[mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Kevin Rushforth
Sent: Monday, December 09, 2013 3:43 PM
To: Anthony Petrov
Cc: openjfx-dev@openjdk.java.net
Subject: 8 post-commit review request: RT-19968: Document that
Platform.runLater must not be called before FX is initialized
Please review the following javadoc change (post-commit).
https://javafx-jira.kenai.com/browse/RT-19968
-- Kevin
RE: Media is now opensource
That's an absolutely fantastic milestone. Thanks to all involved! -Original Message- From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com] Sent: Friday, October 18, 2013 4:55 PM To: John Smith Cc: Richard Bair (richard.b...@oracle.com); openjfx-dev@openjdk.java.net Subject: Re: Media is now opensource All of the JavaFX runtime is open source except for the third-party code that we cannot ship (e.g., the On2 codec that Kirill mentioned, and the T2K font library, for which we have an open replacement), and the FX deploy code, which depends on the JRE deploy code. Additionally, the JMX code, which is shipped as part of the JDK (not the JRE) as javafx-mx.jar has not been open-sourced, but it is only used for optional tooling (and currently lacks an owner). Most (almost all) Jira issues are publicly visible (after sign-in), but some are not (maybe due to security or other concerns). Will this continue to be the case going forward? Yes. In what ways (just in terms of things relevant to JavaFX) does the open source distribution you could build from the openjfx repository differ from what Oracle might include in the JDK? (e.g. VP6 won't be in open-jfx, Oracle provided browser plugin/webstart support won't be accessible, anything else?) That's pretty much it. VP6, T2K, deploy, FX JMX tooling. -- Kevin John Smith wrote: Is the open sourcing of JavaFX now complete? (I think it might be) If not, what is outstanding? Are there auxiliary things like test frameworks or performance tools that are intended to be open sourced to support JavaFX development? Most (almost all) Jira issues are publicly visible (after sign-in), but some are not (maybe due to security or other concerns). Will this continue to be the case going forward? In what ways (just in terms of things relevant to JavaFX) does the open source distribution you could build from the openjfx repository differ from what Oracle might include in the JDK? (e.g. VP6 won't be in open-jfx, Oracle provided browser plugin/webstart support won't be accessible, anything else?) -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Kirill Kirichenko Sent: Friday, October 18, 2013 9:35 AM To: openjfx-dev@openjdk.java.net Subject: Media is now opensource Hello OpenJFXers ! We're happy to announce that Media part of JavaFX is now open source. Opensourcing touched all Media component except ON2 FLV demuxer and VP6 decoder. The decoder will remain closed. You're all welcome to contribute. Thanks, K
RE: Enabling Glass thread checks
IllegalStateException(This operation is permitted on the event thread only) What is the event thread? Current warnings about thread rule violations appear to be something like below (from: http://stackoverflow.com/questions/12182592/javafx-2-x-swing-not-on-fx-application-thread): Exception in thread AWT-EventQueue-0 java.lang.IllegalStateException: Not on FX application thread; currentThread = AWT-EventQueue-0 It is very confusing if warnings about what thread you should be on might use different names for what is perhaps the same thing. If I do System.out.println(Thread.currentThread().getName()); in a start() method, I get: JavaFX Application Thread The JavaFX Architecture overview (http://docs.oracle.com/javafx/2/architecture/jfxpub-architecture.htm#A1107438) only mentions these threads: JavaFX application thread: This is the primary thread used by JavaFX application developers. Any live scene, which is a scene that is part of a window, must be accessed from this thread. A scene graph can be created and manipulated in a background thread, but when its root node is attached to any live object in the scene, that scene graph must be accessed from the JavaFX application thread. This enables developers to create complex scene graphs on a background thread while keeping animations on 'live' scenes smooth and fast. The JavaFX application thread is a different thread from the Swing and AWT Event Dispatch Thread (EDT), so care must be taken when embedding JavaFX code into Swing applications. Prism render thread: This thread handles the rendering separately from the event dispatcher. It allows frame N to be rendered while frame N +1 is being processed. This ability to perform concurrent processing is a big advantage, especially on modern systems that have multiple processors. The Prism render thread may also have multiple rasterization threads that help off-load work that needs to be done in rendering. Media thread: This thread runs in the background and synchronizes the latest frames through the scene graph by using the JavaFX application thread. -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Petr Pchelko Sent: Friday, October 04, 2013 1:40 AM To: OpenJFX list Subject: 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: How to attach files to Jira?
I suggest posting your SSCCE on gist and linking to it from the bug report: https://gist.github.com/ -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Felix Bembrick Sent: Monday, September 30, 2013 3:28 AM To: Sebastian Rheinnecker Cc: openjfx-dev@openjdk.java.net List Subject: Re: How to attach files to Jira? +1 On 30 September 2013 20:25, Sebastian Rheinnecker sebastian.rheinnec...@yworks.com wrote: Agree, this would make posting SSCCE so much easier, I always have to plain write them into the description of the bug report, which is ugly... Kind regards, Sebastian Rheinnecker Am 30.09.2013 08:26, schrieb Tom Schindl: This was turned off long time ago to avoid spam and upload of viruses. What I don't understand is why people who e.g. filed 10bug reports or made 10 comments, asked for upload permission at this very list, ... don't get the possibility. Another option would be to only allow patches / text files. Tom On 29.09.13 16:53, Pedro Duque Vieira wrote: Hi, How can you attach files to Jira? In the past I was able to do this but not anymore. Have you disabled this feature for non Oracle folks? Thanks, best regards, -- Sebastian Rheinnecker phone: +49 7071 9709050 fax: +49 7071 9709051 yWorks GmbH Vor dem Kreuzberg 28 72070 Tuebingen Germany http://www.yworks.com Managing Directors: Sebastian Müller, Michael Pfahler Commercial Registry: Stuttgart, Germany, HRB 382340
Static FXMLLoader load method deprecation
The static methods on FXMLLoader are very confusing. It is very easy to create errors by writing code that mixes static and instance FXMLLoader methods. Everything that can be done with static load methods, can be done with instance FXMLLoader methods. Other than confusion, the static load methods seem to provide little value to me. Is it possible to have the static FXMLLoader methods deprecated for Java 8?
RE: PrefWidth/Height calculations only works if stage is shown
I hadn't seen the applyCSS conversation, but looks like it was contained deep in a node validation thread: http://mail.openjdk.java.net/pipermail/openjfx-dev/2013-July/008549.html Looks like the request is already covered in RT-21206 as pointed out by David. Looks like the feature will show up some time post-Java8, which is why there is nothing on Node now. For now, I stick with Kevin's node snapshot workaround: // create a dummy scene so layout and CSS will work new Scene(new Group(node)); node.shapshot(...) Thanks for the info! -Original Message- From: Richard Bair [mailto:richard.b...@oracle.com] Sent: Wednesday, August 28, 2013 11:46 AM To: John Smith Cc: Anton Epple; openjfx-dev@openjdk.java.net Subject: Re: PrefWidth/Height calculations only works if stage is shown I could have sworn we have already had this conversation and we had a name picked out and everything (maybe it was applyCSS?). I don't see it in Node yet though. Richard -Original Message- From: David Grieve [mailto:david.gri...@oracle.com] Sent: Wednesday, August 28, 2013 11:52 AM To: John Smith Cc: openjfx-dev@openjdk.java.net List Subject: Re: PrefWidth/Height calculations only works if stage is shown There is https://javafx-jira.kenai.com/browse/RT-21206, which I've just edited to be public. On Aug 28, 2013, at 2:29 PM, John Smith john_sm...@symantec.com wrote: Is there any plan to make impl_processCSS(true) public API? Should I create a Jira for this? If there were a public API, would processCSS be the right name for it? The real issue seems to be that you sometimes want to know the size of something before you show it and there doesn't seem to a good way to get that info using just the public API (that I know of). -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Anton Epple Sent: Wednesday, August 28, 2013 7:02 AM To: Richard Bair Cc: openjfx-dev@openjdk.java.net Subject: Re: PrefWidth/Height calculations only works if stage is shown That is very useful in many contexts. Thanks for sharing! --Toni Am 08.08.2013 um 23:40 schrieb Richard Bair richard.b...@oracle.com: The peers don't impact the preferred sizes at all. Use this one instead of impl_reapplyCSS (wrong one) impl_processCSS(true) On Aug 8, 2013, at 2:35 PM, Tom Schindl tom.schi...@bestsolution.at wrote: No same result! BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); g.impl_reapplyCSS(); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); Could it be that this does not work because if a stage is not yet shown the peers have not been created? Tom On 08.08.13 23:29, Richard Bair wrote: Yes, the problem is that CSS has not been executed yet. If you call reapplyCSS (did we add that API yet? or is it still that impl_?) then you can get a proper size from the control. Richard On Aug 8, 2013, at 2:26 PM, Tom Schindl tom.schi...@bestsolution.at wrote: Hi, I've been trying to open a window in the minimal dimension needed by components but it looks like size calculations prefHeight/prefWidth only works if the stage is shown. I need the dimensions before showing the stage because I want to position it on the lower right of the screen before showing the stage because if doing it afterwards leads to flickering. BorderPane g = new BorderPane(); TableViewString v = new TableViewString(); g.setCenter(v); Scene s = new Scene(g); primaryStage.setScene(s); System.err.println(g.prefWidth(-1)); // 0 primaryStage.show(); System.err.println(g.prefWidth(-1)); // 248 Is this working as designed? Tom
Re: Poor quality font rendering
I'm interested in the answers to John T's questions for Linux as well, as there have been reports that font rendering there could use some improvement (though I don't have a Linux machine to test it and the reports don't back themselves up with screen shots or quantifiable data). http://stackoverflow.com/questions/18382969/can-the-rendering-of-the-javafx-2-8-font-be-improved (sorry to add another John to the thread to confuse it ;-) Regards, John Smith
Re: Summary of new features in JavaFX 8?
Here is a link to the current jira generated release notes for JavaFX 8 (it's a humongous list). https://javafx-jira.kenai.com/secure/ReleaseNote.jspa?projectId=10040version=10380 The majority of stuff in the jira generated release notes is implemented, but some is not and will probably be moved to a future release. In terms of the terminology used, I think a feature is major new functionality usually called out on a product requirements document somewhere and a tweak (of which there are hundreds) is a minor feature (though I don't think it's a hard and fast rule and a little arbitrary - some features are pretty minor and some tweaks are pretty important). Some major features missing from your list Felix: multi-threaded performance improvements right - left language support HiDPI display support (though that might also be in some upcoming Java 2.2 release) swing components in JavaFX increased support for new w3c standards in WebView (e.g. websockets) @font-face support in css (I guess this one might be termed a tweak) ATI/AMD GPU acceleration on Linux I think there is also an intention for an official embedded release for Java 8 that will include JavaFX in the new compact profile setup. From a developer point of view, I think the big news is open sourcing (except for the media and browser plugin components) along with the new repository layout and relatively simple gradle build process - so potentially JavaFX can now be included in OpenJDK and custom JDK builds, not just Oracle JDK builds. My favorite feature of all time is that with Java 8, JavaFX is properly bundled into Oracle Java and on the default class path. So I don't have to keep explaining to people how to get JavaFX to run in their environment. Hopefully, all of the standard OpenJDK 8 builds and distributions will follow Oracle's lead here and correctly bundle JavaFX into their distributions. -- Here is a result of a jira query on fixed features for JavaFX 8. RT-30831 Unsorted mode in the SortedList RT-30236 Open WebView sources RT-29848 Add a static GridPane.setFillWidth(Node, boolean) method RT-29834 Move JSObject into javafx-ui-common RT-28817 Add explicit dispose() method to MediaPlayer RT-28499 WebView doesnot support HTML5 input type=file multiple RT-28089 Write Script to auto-generate the new repository layout RT-27887 introduce a node to embed Swing into JavaFX RT-27633 Add missing FXCollections methods for ObservableSet RT-27582 New modern theme for JavaFX (Modena) RT-27480 Add DatePicker control RT-26377 Implement SubScene RT-25996 PrimitiveProperty to ObjectPropertyPrimitive RT-25759 ObjectExpression does not have asString() method RT-25644 Implement WebSocket traffic tunneling through HTTP(S) proxies that require authentication RT-25606 Port 3D features from demo/experimental repository to FX 8 3D sandbox RT-25559 In FXML, Allow event handlers to come from the namespace RT-24712 Support ATI/AMD GPU on the Linux platform RT-24655 Need to support movable Camera RT-24654 Need to include lighting and material support for 3D primitives rendering RT-24651 Need clean semantic for 2D/3D scenes mixing RT-24648 Define supported Linux configurations RT-24644 Support Mesh and Predefined 3D Shapes RT-24506 Public API for Region backgrounds and borders RT-24041 SQE: Hi-DPI display support RT-24014 FX needs to support a subset of the JRE supported systems RT-24013 Multi-Core scalability RT-24012 Text performance of the hardware pipeline must be equal or better than the software pipeline RT-24009 Support for Hi-DPI displays RT-24008 3D attributes RT-23911 SQE: Allow 3D shapes RT-23909 SQE: 3D attributes RT-23908 SQE: Video capture support RT-23907 SQE: Improve HTML 5 API and tags support RT-23904 SQE: Tree table control RT-23903 SQE: Public API for CSS Structure RT-23901 SQE: Enable component orientation RT-23898 SQE: Printing support RT-23897 SQE: Support bi-directional text RT-23896 SQE:Provide support for complex characters RT-23895 SQE: i10N: Java FX must be localized in all the different languages as supported by the JRE. RT-23894 SQE: Multi-line rich text support RT-23893 SQE: i18N: Java FX must support internationalization RT-23600 ObservableListBase RT-23075 Support complex characters in controls RT-23074 Support bi-directional text in controls RT-22913 Implement and enable accelerated compositing to improve WebView rendering performance RT-22153 Allow setting custom user-agent RT-21709 Consider making available the CSS Styleable* classes as public API RT-21683 Allow to change line-to-line
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: 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
JavaFX 2.2 does http live streaming: http://docs.oracle.com/javafx/2/media/overview.htm HTTP Live Streaming Support With the addition of HTTP live streaming support, you can now download the playlist file and playback video or audio segments using JavaFX Media. Media players are now able to switch to alternate streams, as specified in the playlist file and based on network conditions. For a given stream, there is a playlist file and a set of segments into which the stream is broken. The stream can be either an MP3 raw stream or an MPEG-TS containing multiplexed AAC audio and H.264 video. The stream can be played on demand when the stream is a static file or played live when the stream is actually a live feed. In both cases, the stream can adjust its bit rate and for video, its resolution can be adjusted. More info on HTTP Live Streaming: http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/Introduction/Introduction.html Your other questions, the JavaFX media devs can answer. -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Felix Bembrick Sent: Thursday, August 08, 2013 1:32 PM To: openjfx-dev@openjdk.java.net List Subject: JavaFX Media issues 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! 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? 3. Is buffering of media something planned for the future in JavaFX? 4. What about live streaming of media content? Thanks, Felix
RE: JavaFX Media issues
One thing to suggest is that you can install your own URL content handlers / protocols in Java. That won't help in this case unless you replaced the http, file or jar protocol handlers, which would be weird. Only HTTP, FILE, and JAR URLs are supported. http://docs.oracle.com/javafx/2/api/javafx/scene/media/Media.html#Media%28java.lang.String%29 -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Richard Bair Sent: Thursday, August 08, 2013 1:57 PM To: Felix Bembrick Cc: openjfx-dev@openjdk.java.net List Subject: Re: JavaFX Media issues 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! I will have to let the media guys chime in, I don't know why we don't support a stream. At one time Image had the same limitation but we added stream support for it, so it might just be oversight. One thing to suggest is that you can install your own URL content handlers / protocols in Java. So if your URL said myapp://nameofvideo.mov or whatever, you can install a myapp protocol handler with Java which is responsible for creating the InputStream. This way you can still had us a url and we can get back your input stream, even from a custom source such as a Database. 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? Probably got blown up during the gradle switch. Can you please file a bug (in the build component) 3. Is buffering of media something planned for the future in JavaFX? 4. What about live streaming of media content? Kirill should have more information here. Thanks! Richard
JavaFX CSS significantly differs from W3C CSS (Forked from RE: Proposal to move default style-class from Control to SkinBase)
So if you invent the same node-types you have on the web (lets face it there's only a handful of them most important are most likely div,span) and give them the same properties you know from the web you can copy your Web-CSS stylesheet to your FX-Application. +1 to this idea (in a 3rd party lib). The issue I see is that JavaFX CSS significantly differs from W3C CSS It surprises me that this issue comes up so rarely in JavaFX forums (almost never) - perhaps it is because JavaFX developers tend to be Java developers rather than designers. A related open jira request is http://javafx-jira.kenai.com/browse/RT-9272 need to reconcile JavaFX CSS with W3C CSS3 0 votes (no interest at all?). In terms of conversion of existing html css resources to javafx css, you may be interested in a QA with a developer who converted the Foundation look and feel to JavaFX (https://forums.oracle.com/thread/2490009) - from his point of view the conversion process was quite straight-forward - though perhaps that was partially luck of the draw. Below is a copy and paste from an earlier JavaFX forum post on this topic: You know, sometimes I find JavaFX's lack of certain css features refreshing. It is nice to have all, well, almost all, of the JavaFX CSS documented on one page. I think if you were to do the same thing for w3c css then it would end up with a much larger, more difficult to understand document and even what the contents of that document should be would probably be pretty controversial, in the same kind of way that the HTML5 specification ended up being. Microsoft contributed over 7000 tests to w3c just to cover only a subset of the css rules available in browsers today. The webkit project lists almost a thousand open CSS bugs: https://bugs.webkit.org/buglist.cgi?product=WebKitcomponent=CSSresolution=---. So implementing even partial w3c CSS support is a complex project. When I first started using JavaFX CSS I found the differences to w3c CSS quite jarring, and it was hard to account for them. Now that I am used to JavaFX CSS, I don't have as much of an issue. The difference in names and semantics is going to be an impediment to designers working on JavaFX who are familar with w3c CSS - but the designers will quickly also discover that FXML is not HTML and Java is not JavaScript and JavaFX deployment is not HTML deployment. So, perhaps, in the larger picture, it is not as big a deal as it would seem. Still, one can't help think that any impediment to people easily picking up and adopting JavaFX is doing the technology a disservice. There are other advantages in having the JavaFX CSS in its own namespace to w3c css, in that it can evolve seperately, it is not expected to be exactly the same because it has a different name, it is not expected to fully implement w3c css as browsers do because it's clearly a different thing by name, etc. There is even precedent for it in the use by mozilla of moz- CSS prefixes and webkit css properties http://css-infos.net/properties/webkit - the web as not as standard as a lot of people propose. JavaFX CSS is backing a JavaFX rendering engine and not an HTML rendering engine. It is quite remarkable that Oracle was able to build and make available a CSS model for JavaFX that feels as familiar as it does to w3c css, as w3c css is targeted very strongly toward styling a completely different technology set (HTML markup and document object model). It would be useful to have a tool which translates w3c css to approximations of JavaFX css and vice versa, or the ability for JavaFX to have a mode (perhaps a boolean value when a stylesheet is loaded) to perform an automatic alias or mapping of w3c css to javafx (at least for the subset of w3c css which would make sense to automatically translate to JavaFX css). (David commented on this part previously - Closing the gap between JavaFX CSS and W3C CSS will be an evolutionary process. It would be nice to use a standard's based stylesheet but there is not always a 1-1 mapping to JavaFX. But for those properties that can be mapped, it is something that should be supported. For example, we should be able to handle font or -fx-font.) Comments above relate to the naming and semantic meanings of css tags, and not the syntax and parsing of css (as both w3c css and javaFX css seem to be equivalent in the later regard). The JavaFX css model is really powerful and I have found really useful some of the additions that it adds above the baseline 2.1 css that is found consistently in browsers. With the upcoming Java CSS object model http://javafx-jira.kenai.com/browse/RT-17293 CSS Style Object Model in Java 23 votes, you will also get better programmatic access from Java, which seems to be a highly requested feature. Regards, John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Tom Schindl Sent: Wednesday,
RE: Performant Controls (hijacking Re: Developing controls based on Canvas?)
. . . imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut with x100 nodes, with zooming and panning - could you outline a general strategy? I'd use some like yworks yfiles for this, it seems pretty similar = http://www.yworks.com/en/products_yfiles_practicalinfo_gallery.html (this page is a very nice example of a showcase by the way :-) Sebastian Rheinnecker from yworks created a prototype of their tool in JavaFX. He has posted on this list before, so you can find his email in the archives if you want to ask questions about it. The yworks stuff is a very nice graphing system that scales to very large graphs and is implemented in lots of different technologies, so perhaps a good contact point if they are willing to discuss implementation details. There is also the primarily JavaFX based Dex Data Explorer which also seems pretty similar (albeit using a polyglot programming approach) = http://www.javainc.com/projects/dex/ -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Monday, August 05, 2013 5:39 PM To: Jonathan Giles Cc: openjfx-dev@openjdk.java.net List Subject: Performant Controls (hijacking Re: Developing controls based on Canvas?) Sneaking in here, as you've given an opening with if implemented wisely, there is very little that a scenegraph-based approach can't do. The question I've been asking for a while is what does implemented wisely look like in JFX. This has come up in the performance conversations, the game conversations, the CAD conversations, and many other places. No one seems to have an answer, but you're building extremely complex stuff on a regular basis - what's your tips? When you say you only have 20 visible nodes out of 1000's in general are the other nodes: a) in the scenegraph and set to not visible b) in memory but not in the scenegraph - added/removed when scrolled into view and out of view c) not in memory, created, added and then removed, destroyed when scrolled into view and out of view d) something else? I know Table uses a rubber stamp approach, where it re-uses cell views where possible, but let's say every row in my 100,000 row Table was uniquely rendered using a different cell. What would happen under the covers? How do you work out the scroll range as well? Each cell can be a unique height right? How do you know the extents of the vertical scrolling without instantiating and rendering everything? Is this what you do? What if a cell is changing size (has a collapsable pane in it, etc) - what happens to the vertical scroll range? Do any of the controls have zooming on them? Have you had to deal with this and have you got a strategy for handling this with respect to scroll bounds, working out which nodes are in view, scaling fonts, etc? Could you hazard a guess at what you would do if you had to implement zooming on a Table for example? Maybe the Table is lucky with its restrictive grid like layout but imagine you had to build a visualisation of the same data but in a diagram, maybe something like http://www.novell.com/communities/files/img/groupwise_8_protocol_flow_diagram_v1.3.jpgbut with x100 nodes, with zooming and panning - could you outline a general strategy? On Tue, Aug 6, 2013 at 10:10 AM, Jonathan Giles jonathan.gi...@oracle.comwrote: I think it would pay to take a step back and understand why you think a 'traditional' scenegraph-based (or retained mode) control is not sufficient for your needs? Unfortunately you've not detailed your use case, so it is hard to give any specific advice. Are you able to give any details about what it is you're trying to build and why you think the normal approach to building controls is not sufficient? We've built some fairly complex controls using this approach, and if implemented wisely, there is very little that a scenegraph-based approach can't do. Specifically, do you think your control will render all of the 'thousands of nodes' at once, or will many of these nodes be off screen or otherwise not visible at any one time? For things like the TableView we only render the nodes that are visible. This means that regardless of whether there are 100 or 1,000,000 rows of data, we only have visual nodes for the 20 visible rows, for example. Keeping your scenegraph as minimal as possible is always a very wise idea, if performance is a concern. As you note, the other problem is that you will run into issues if you want to mix canvas rendering with the scenegraph-based controls like Button. The best you're likely to achieve (having not tried it personally) is to position the control on top of the canvas, rather than attempting to render the control inside the canvas (and having to then deal with event handling,
RE: JavaFX Sightings (forked from Re: Can JavaFX do CAD?)
I think there are two kinds of sightings = a) Small demo apps that show up on blogs. b) Commercial apps or significant A+ open-source projects. I think a Sightings type site should not host both styles, or if it does, it should clearly delineate between the two, so that it is clear to people accessing the site what can be done in JavaFX with a team over a period, versus something quick done by an individual which does not demonstrate many capabilities of the platform. There have been attempts to host JavaFX demo sites before, especially on the JavaFX 1.x days = http://www.jfxia.com/JFXDemos/ https://www.java.net/community/javafx The demos that used to be hosted at the JavaFX 1.x site. Other sites which have since disappeared from the web. Some of these sites (especially the ones that hosted applets), were (IMO) more harmful to JavaFX than they were helpful. I'm sure Oracle received that feedback already many times over, hence why the JavaFX 2.x site is so different in the way it presents samples than the JavaFX 1.x site. IMO, the JavaFX 2.x site handles samples and showcases in a better way than the JavaFX 1.x site did. I think to be considered a showcase app, the app should exceed certain minimal quality checks and provide significant functionality. It's nice for the showcase app to be usable in a full feature or demo form, so that somebody can actually try it out, but failing that, screenshots are ok. The best showcase apps I have seen so far are all from Oracle or Oracle employees, (Scenebuilder, Scenicview, Henley Sales and Ensemble). It would be nice to see more showcase style apps which are not sourced from Oracle or the JavaFX team. There are some difficulties in easily trying out these showcases because you need to download and install them, but that is probably OK for somebody seriously investigating the platform, and it is probably better than hosting them as applets which may provide runtime difficulties and security issues for users. For developers learning the platform, 50 little demos (like Ensemble) is fantastic, but in determining the full capabilities of the platform, five really great samples and one killer app is more impressive. Hopefully, if another JavaFX Sightings site is started, it will prove a higher quality showcase of JavaFX capabilities than prior attempts. Enhancing the existing java.net community page might be an appropriate place for such a JavaFX Sightings site? Maybe just adding more examples to what is already at java.net community and having info on the really nice apps stay on the front page is enough? Though I do get the feeling that fxexperience is more the true hub of the JavaFX community than the java.net community page? Regards, John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of John C. Turnbull Sent: Saturday, July 27, 2013 5:20 PM To: 'Daniel Zwolenski'; 'Pedro Duque Vieira' Cc: 'OpenJFX Mailing List' Subject: RE: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) +1 Such a site could be very useful. -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Daniel Zwolenski Sent: Sunday, 28 July 2013 09:56 To: Pedro Duque Vieira Cc: OpenJFX Mailing List Subject: JavaFX Sightings (forked from Re: Can JavaFX do CAD?) The idea of a JFX Sightings page (in the tradition of the Swing Sightings page) has been raised before and I think is a good one. It deserves it's own page though, that technet section isn't up to it in my opinion. Personally I think this would be great under the fxexperience site as it partners nicely with the links of the week? On 28/07/2013, at 4:17 AM, Pedro Duque Vieira pedro.duquevie...@gmail.com wrote: I have an Swing/JavaFX app, the site is: http://modellus.co How can I get it to be on that real world usecases section? Or does it not have the necessary requirements to be in it? Thanks, best regards, @John: On the JavaFx community site they have a section with references to real world usecases. http://www.oracle.com/technetwork/java/javafx/community/index.html On Sat, Jul 27, 2013 at 1:40 AM, John C. Turnbull ozem...@ozemail.com.au wrote: Like Daniel said, none of what we say is in any way a criticism of the JavaFX development team who, in my view and that of the entire community, are doing an awesome job. For mine, all the shortcomings of JavaFX (perceived or actual) can be blown away if I could just demonstrate what JavaFX is really capable of. We have Ensemble from Oracle and also Ensemble from JFXtras (whose demo incidentally doesn't run since Java 7 Update 21). With Oracle Ensemble we can see that JavaFX has quite a nice set of basic controls and that it at least supports very simple animations. With JFXtras Ensemble we can see that very nice controls are possible but unfortunately many of
RE: Java Deployment (was Re: JavaFX 8 Progress)
auto updating so people can easily release patch updates Checkout getdown = http://code.google.com/p/getdown/. It's simple, proven open source tech used to distribute the Puzzle Pirates MMORPG which had 4 million accounts and 250 million hours of play time in 2008. Forking getdown, swapping out its existing thin Swing UI and replacing it with a configurable JavaFX UI is likely a pretty easy process. Some additional work would need to be done to integrate it into modern build/deploy tool chains such as the javafx maven and gradle plugins. I think it makes sense for the native bundling option where the combination of the two allows (IMO) a reasonable replacement for webstart. Replacing applets is more difficult, you probably want to use something like CacioWeb or have cloud based logic and some rendering with a streaming protocol to the browser and final rendering inside an html5 canvas, but that kind of technology does not exist for JavaFX as far as I know. John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Mario Torre Sent: Thursday, July 18, 2013 3:10 PM To: Daniel Zwolenski Cc: mike.ehrenberg@barchart.comEhrenberg; openjfx-dev@openjdk.java.net; JeremyJongsma Subject: Re: Java Deployment (was Re: JavaFX 8 Progress) For Swing you can actually use CacioWeb, works quite well. Zero deployment, no VM needed, no plugin, just an HTML 5 capable browser. Doesn't work with JavaFX unfortunately. Cheers, Mario Il giorno 19/lug/2013 00:03, Daniel Zwolenski zon...@gmail.com ha scritto: There are definitely credible alternatives. The problem is currently the alternatives are not implemented well enough so web still ends up a contender just by being the only one able to stand up. And for the record I build both public facing apps and back-office apps and web deploy does not work well for either. I stopped using jfx because of deployment. I now build only webapps because of deployment. Credible alternatives: 1. Native bundlers, but we need: - auto updating so people can easily release patch updates - smaller co-bundled jre's so that the initial download and install is smooth and quick - better build tools to make this easier to integrate into a standard build process, with some solution for cross-platform build support or to at least minimize the pain 2. App stores: - ready to go right now for Mac but we don't have the tools and I think we need everything fully open sourced for licensing reasons (hard to say) - need to either pick one of the unofficial win app stores for pre-win8 support (there's a few), or build our own app store - we just need tools for building and deploying to app stores (not that hard) and cut down jre sizes again (app stores are an extension of cobundling approach). 3. Self-hosted 'app store' for corporate settings. install a small, native client on the machine that allows that user to download and install apps from your private server, with auto-updating, etc - we need to build one, not that hard, maybe a month or two of work to get a first working version out. I would have built one by now but because jfx packaging tools are so bad I've burnt up all my spare time just putting wrappers around these to get the most basic of maven plugins to work. All of the above could have been implemented by now if there was just a little bit of love in this area. One resource ticking away would have been enough to get something going. As it stands there has been zero, nada, zip changes into anything other than web/security deployment efforts over the last year. J8 due next year (!) will not include any of the above, or even any simple improvements to deployment approaches other than web, to the best of my knowledge. On 19/07/2013, at 7:30 AM, Mark Fortner phidia...@gmail.com wrote: I've heard the webstart is broke, don't fix it, move on song before from a number of people. What I haven't heard is a credible solution to solving the very real problem of keeping an app up-to-date in a corporate setting. For the most part, I agree that if you're in the business of selling commercial software, selling and distributing through an app store probably makes sense for you. Although I wouldn't relish having to build on all of those platforms. However, posting proprietary apps to external OS-specific app stores doesn't really work for anyone in a corporate setting. Neither does making a user re-install an application every time you post a bug fix. In addition, many corporations limit the privileges they give users. Cheers, Mark
RE: MSAA and Scene anti aliasing
The discussion on choice of anti-aliasing algorithms reminds be me of the cipher suite setup for the jce, which represents this kind of information using String tokens. http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html There you end up with stuff like = TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_RSA_WITH_AES_256_CBC_SHA256 ... ad infinitum It's kind of similar because you are choosing an algorithm (or combination of algorithms) and various combinations of key lengths, hash lengths, etc. For the cipher suite stuff, the implementation just punts completely on attempting to provide something which is type safe. Instead, the cipher suite is just an opaque string token. You can enumerate at runtime what are the available cipher suites (in code). You can have different implementations which support different cipher suites. If the user requests a cipher using a string which is not known to the currently enabled security providers, the cipher request will throw an exception. There is a subset of known cipher suites which must be present in all implementations. What is available in any given release for an implementation can be found be consulting the technote documentation (as linked above). You can lookup a cipher algorithm without specifying the fully qualified string and let the underlying implementation make a best guess for stuff you don't specify. For example Cipher.getInstance(DES/CBC/PKCS5Padding), or just Cipher.getInstance(DES). So for an antialiasing sample if you didn't want to be specific about the number of samples, you could specify MSAA, and if your did want to be specific, use MSAA_8. It works OK and has allowed a flexible specification of algorithms in the jce for years. It does lack a discoverability aspect though, i.e. your IDE is not going to hint you what the available cipher suites are. The cipher suites don't show up with appropriate documentation in javadoc. Instead you need try to dig up the obscure technote documentation on the internet (later revisions of the jce class javadoc have been a bit better in linking to this technote). A sample of what the javadoc ends up being for an approach like this is: http://docs.oracle.com/javase/7/docs/api/javax/crypto/Cipher.html#Cipher%28javax.crypto.CipherSpi,%20java.security.Provider,%20java.lang.String%29 JCE is an older api created before enums existed, but I'm not sure you would realize this level of flexibility with an enum. There are tradeoffs for just using a String to represent this information versus other typesafe options. I'm not recommending this approach, just submitting it for consideration. Regards, John -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Scott Palmer Sent: Monday, July 15, 2013 3:03 PM To: Richard Bair Cc: openjfx-dev@openjdk.java.net Subject: Re: MSAA and Scene anti aliasing I would vote for option b) Use a full class that can be extended later as needed. You don't have to use it like an enum. It could be a container for configuration parameters, possibly including the enum that says the antialiasing mode, but with separate fields (or maybe even just a single map) to supply the additional details e.g. x2, x4, x16. I also find that mixing the kind of antialiasing with the parameters in a single enum is smellier than keeping those things distinct, but I don't like methods with a lot of parameters either. You could supply simple static fields or methods to get a class configured for the common cases so it could be used as easily as an enum. Scott On 2013-07-15, at 4:45 PM, Richard Bair richard.b...@oracle.com wrote: I think there should be a simple way to request full scene anti-aliasing to improve 3D rendering. And also an optional more advanced way to specify which type… I agree it should be nice and simple. It should also allow us the freedom to make it better in the future. I think that adding a secondary property to refine what is meant by the first property is not a good idea for the following reason. As our API stands today it is not possible to later add any API without cluttering things up. Specifically this is because we require you to specify anti-aliasing at the time the scene is constructed. Ostensibly this is because it is easier for our implementation. I think this is wrong (and the fact that we expose a read only property for anti-aliasing is going to come back to bite us if we ever attempt to make it a read-write property). But suppose we decide that no, it really should be read-only for all time. In that case, in 8.1 we decide to add more API that lets you specify various details about the implementation, such as the algorithm to use. Now we have to add yet another constructor with yet more parameters to be able to specify this additional constraint. This is bad. What
RE: How are Mnemonics On Buttons Supposed To Work?
Are you using OS X? For me, mnemonics in JavaFX work on Windows, but not at all in OS X (which is perhaps by undocumented design?). Apple's platform integration guide contains a section on Mnemonics, it based on Swing but I think the concepts translate to JavaFX: https://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/07-NativePlatformIntegration/NativePlatformIntegration.html The JMenuItem class inherits the concept of mnemonics from the JAbstractButton class. In the context of menus, mnemonics are shortcuts to menus and their contents, which are executed by using a modifier key in conjunction with a single letter. When you set a mnemonic in a menu item, Java underscores the mnemonic letter in the title of the JMenuItem or JMenu component when the Option key is held down. Using mnemonics is discouraged in OS X, because mnemonics violate the principles of OS X Human Interface Guidelines. If you are developing a Java application for multiple platforms and some of those platforms recommend the use of mnemonics, just include a single setMnemonics() method that is conditionally called (based on the platform) when constructing your interface. How then do you get the functionality of mnemonics without using Java's mnemonics? If you have defined a keystroke sequence in the setAccelerator() method for a menu item, that key sequence is automatically entered into your menus. Accelerators work on both Windows and OS X (http://stackoverflow.com/questions/12710468/using-javafx-2-2-mnemonic). -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Mark Fortner Sent: Monday, July 01, 2013 10:35 AM To: openjfx-dev@openjdk.java.net Subject: How are Mnemonics On Buttons Supposed To Work? Recently, I added mnemonics to some buttons and enabled mnemonic parsing, and noticed that the mnemonic isn't rendered. I came across this issue: https://javafx-jira.kenai.com/browse/RT-18849 which seems to indicate that NOT showing mnemonics is the expected behavior. If that's correct, how are user's supposed to know what mnemonics are available? Cheers, Mark
RE: Tooltip is interfering with mouseEntered/mouseExited events
A somewhat related inconvenience I have with tooltips is that if you put a tooltip on a button, then hover the mouse so that the tooltip shows up, you can't click to activate the button unless you move the mouse pixel to left or top because the resultant click will go to the tooltip and not to the button. It's especially strange on Modena, because there the tooltip has a rounded corner, so you visibly aren't clicking on the tooltip, though you are clicking in the tooltip's rectangular bounds. Some examples of how other apps handle tooltips: In NetBeans the tooltip shows up below the button rather than at the mouse position - this has the advantage of not obscuring the thing which the tooltip is providing information on. Intellij Idea is similar, except that it's tooltip is a callout has with a little triangular area which overlaps the thing the tooltip is for. If you click in the overlapped area, the underlying node still takes the expected action. Microsoft apps like Outlook show tooltips below the things they are providing info on (or above if there is not enough screen area below to show the tooltip). -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Pedro Duque Vieira Sent: Monday, June 10, 2013 2:42 PM To: OpenJFX Mailing List Subject: Tooltip is interfering with mouseEntered/mouseExited events Hi, I have a toolbar composed by a couple of buttons. The toolbar fades away when the mouse exits. The problem is that I have tooltips set up with the toolbar and sometimes they appear under the mouse which triggers a mouseExit event that makes the toolbar fade-away. My point is maybe the tooltips should be viewed by the API as a component that is part of the other component which they are set upon. In this situation I'm getting random mouse exits depending when whether the tooltip appears below the mouse or not. Cheers, -- Pedro Duque Vieira
RE: Handling uncaught exceptions during event dispatching
RT-30239 Use Thread.UncaughtExceptionHandler instead of ExceptionDescribe() to report exceptions https://javafx-jira.kenai.com/browse/RT-30239 It was fixed by Artem Ananiev for Java 8 It links outstanding: RT-30369 Lens: implement RT-30239, Thread.UncaughtExceptionHandler https://javafx-jira.kenai.com/browse/RT-30369 I don't know if the Lens Jira is relevant, as I don't know what Lens is, but I'm sure you do. -Original Message- From: openjfx-dev-boun...@openjdk.java.net [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of Richard Bair Sent: Tuesday, June 04, 2013 1:38 PM To: OpenJFX Mailing List Subject: Handling uncaught exceptions during event dispatching Hi, If I wanted to handle all uncaught exceptions that occurred during event dispatch (whether Mouse / Pulse / Key / Runnable / etc), how could I do it? I assume at present we can't. Is there a JIRA already for such a thing that anybody knows of? Thanks Richard
