negative line spacing in Text
Hey guys, since Java 8 all javafx multiline text controls (Label, TextArea, TextFlow) support linespacing via the css -fx-line-spacing attribute and Properties (on TextArea on Text-Node of Skin accessible via lookup). However none of them seem to support negative value which would be necessary to achieve a linespacing smaller then the default, since default value is 0. If a negative value is used, e.g. for a Labels line spacing, it will simply not wrap or line feed(\n). Is there a way to achieve a line spacing smaller than the default with these components? Thank you in advance Matthias -- Matthias Hänel hae...@onexip.com onexip GmbH Am Waldschloesschen 2 | D-01099 Dresden | Germany http://www.ultramixer.com http://www.onexip.com
Re: Blur effect on live scene?
Hi Jim, On 8/10/2015 11:44 PM, Matthias Hänel wrote: If we had a snapshot to texture mechanism then that might reduce the memory copying of the work around technique. Well, did you say there is no snapshot to texture in JavaFX? In plain OpenGL you can use FBO's (Frame Buffer Objects) to render them. This is nothing more than a snapshot. They are even sliceable and strechable. To be clear, there is no API to directly specify snapshot this Node/Group to a texture and give me a handle to it to manipulate. As I said later, there is a mechanism to get Node/trees rendered into a texture and that is the Node cache property, but we do that behind the scenes, the developer doesn't get a handle to the texture in that case. Okay, that are different OSI layers. On the lowest OpenGL Layer it could be a FBO implementation. On higher layers there must be APIs that support this. I'd argue that we sort of do have something like that - it is the cache flag. If a Node is cached then we do have a copy of it in a texture and that can help make the Blur Effect work more efficiently, but there may be some additional copies between textures if everything isn't set up right. Still, that is an avenue for someone to check to see if there isn't a better way to achieve this effect in the short term... I am not pretty sure what cache does. Probably some hasmap that holds objects and they are not instantly destroyed in the graphics RAM? It is not a hashmap. It is a hint to save the rendering of that node in a buffer: https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#cacheProperty I don't like the way that this doc comment is worded as it implies that using it on a node that is blurred is unwise, but if the node is animated over even GPU acceleration of the rendering and blurring operations are going to have some cost that it could save. That documentation says nodes are cached as Bitmaps. In GPU or in CPU space? It is not clear here. I suspect it is in CPU RAM space. That will just lead to more copy-tasks from CPU to GPU or not? If optimized there is no benefit at all as stated in the docu note that on some platforms such as GPU accelerated platforms there is little benefit. Actually, I would expect that renered Nodes are textures in GPU-VRAM to get the most performance out of it. From my current point the major problem with JavaFX is still the same. 1. Has a good API 2. renders most of its stuff in software, hence does not run performant 3. Has good approaches, but the overall sight on the technology is broken somewhere. I am not sure how you come to the conclusion that it renders most of its stuff in software. It renders quite a lot in hardware. Even the example here of using snapshot to optimize a blurred background - the rendering of the scene is done in hw. It is only copied to main memory because the API requires a persistent image. If you render that image to the screen it is copied back into a texture and reused from that texture unless we run low on vram. There is no rendering in software there, only use of a heap buffer for persistent storage... Your point is that it uses hardware to render and it just uses snapshot to satisfy the API? My current understaning is ... what happens in our blurred-effect case? 1. the application constructs a JavaFX node tree. 2. the node tree is rendered mostly in hardware (shader effects and so on on top) to the main framebuffer 3. Snapshot calls ReadPixels (or whatever it is called on the particular platform) 4. JavaFX encapsulates this new image with Object 5. We draw the new image with effects to the OGL context with the same node-tree API as we did before on top of the first node-tree. That works, but there is too much CPU and memcpy involved for my believe. Furthermore ReadPixels takes forever in an OpenGL perspective. Since this is just one very simple effect, it is actually not good to spend more than approx. 20% CPU (i7) load on it. I expect 0% (not noticable) for this blurry effect. The ideal implementation from my perspective would be: 1. the application constructs a JavaFX node tree. 2. the node tree is rendered mostly in hardware (shader effects and so on on top) to a virtual framebuffer in the GPU space 3. The virtual framebuffer is drawn by a simple drawVert-call for the background 4. The virtual framebuffer is drawn once again shaped and shaded (blurry filter) by another drawVert-call This would reduce CPU usage by a very big amount of cycles. (From an Shader perspective we could reduce GPU load one more if we merge point 3 and 4 and run a partially shader to blur just the upper corner. Well this is much more hand-coding and not good integratable in a bigger API.) Even tough these ReadPixel-Functions to retrieve GPU rendered images to the CPU space are not very fast. I have to correct my assumption that JavaFX renders most
Re: Blur effect on live scene?
Hey Jim, internally we are argueing pretty often about pro and cons of different technologies espacially java. When I first read about JavaFX I was very happy to see a hardware accelerated approach in the Java world that could stop the common sense of laggy java-apps. From a software persepective I am located at the very first few layers right in the hardware (firmware) and right above (drivers, interfaces etc.). That's why please forgive me if I am wrong on UI specific stuff. This is not my expertice. Actually, I build the native opengl implementation for our software. That means it uses jogl, but it is pretty standard OGL. Therefor I a know a bit about the OGL state machine and their usage. I am very sure DirectX has similar techniques for any of those purposes. Am 10.08.2015 um 20:29 schrieb Jim Graham james.gra...@oracle.com: Let me understand what is going on here. I get the result you are trying to achieve - blur the scene as background for something. I get that Mac and iOS seem to have direct support for this technique which appears to work faster than what we provide via the Effect mechanism. I also get that attempts to make it appear better via snapshot will unfortunately involve a copy to main memory to produce the Image object. If we had a snapshot to texture mechanism then that might reduce the memory copying of the work around technique. Well, did you say there is no snapshot to texture in JavaFX? In plain OpenGL you can use FBO's (Frame Buffer Objects) to render them. This is nothing more than a snapshot. They are even sliceable and strechable. Yesterday we discussed the JavaFX API and we came to the conclusion that there must be tow APIs 1. standard copyFromRAMAnDraw 2. FBO based. Drawing to a framebuffer and manipulating. This is not only needed for this small effect here. It is much more. One very big damand of a new technology would be a feature that's called conext sharing. This is one of the most important copy-prevention-mechanisms to us. That makes it possible to push an image to the graphics RAM and draw it two, three or even multiple times. I'd argue that we sort of do have something like that - it is the cache flag. If a Node is cached then we do have a copy of it in a texture and that can help make the Blur Effect work more efficiently, but there may be some additional copies between textures if everything isn't set up right. Still, that is an avenue for someone to check to see if there isn't a better way to achieve this effect in the short term... I am not pretty sure what cache does. Probably some hasmap that holds objects and they are not instantly destroyed in the graphics RAM? There is the implication that one can add a shader to an overlay texture that will cause it to have a dynamic blurred lens effect. I'm not familiar with how that would be done. AFAIK, shaders work on inputs and produce an output which is transferred to the destination using the pixel transfer functions and you can't source the destination pixels in the shader in order to blur them. I would imagine that the Mac/iOS technique is done by sourcing directly from the back buffer into the overlay texture using a blurring shader. That gives the overlay texture a solid background that is a blurred copy of the back buffer. They then draw the overlay contents (menu bar?) on top of that blurred background data and transfer the overlay texture back into the scene. The blurred vision you are seeing is not the pixels being blurred through the overlay texture but rather a very quickly managed blurred copy of the data in the underlying buffer. If the scene changes, then the entire process would need to be repeated on the new underlying pixels to get a new blurred copy of them as background in the overlay texture. I can also imagine that they may have more direct support for blurring (there is an OpenGL EXT_convolution extension which we do not use - using our own convolution shaders instead - which may potentially work faster than what we do). Also, they may be a little more efficient at managing the buffers involved in that dynamic operation (our Decora Effect engine isn't necessarily set up to use the back buffer as a source and so sometimes we may have to render parts of a scene an extra time specially to make an input texture for Decora). I am not sure what Decora is, but you are right with the sourcing from the back. You can only shade 1:1 in OGL's shading Engine but that's not a real problem since we have FBO's :) The Background is rendered to an FBO. This FBO renders as a Background and a second time the same FBO is rendered as Blurry shaped Foreground. If I'm understanding all of this correctly, then it seems that: - it may be time to investigate tighter integration of Decora and Prism texture mechanisms (they use the same underlying objects, but don't have a good way to
Re: Stage hide/show from Swing
Thanks Scott for your fast answer.
Well, in this case
PlatformImpl.runLater(new Runnable()
{
@Override
public void run()
{
...
is never called. I believe it is not called because the Stage is not running
anymore and
therefore the JFX Main Thread is stopped.
I am now on 1.8.0_60 and have still the same behaviour :(
regards
Matthias
Am 18.05.2015 um 14:17 schrieb Scott Palmer swpal...@gmail.com:
I would have thought that #2 was correct. What happened when you tried it?
Did you make sure JavaFX didn't try to shutdown automatically when the last
Stage was hidden?
Scott
On May 18, 2015, at 7:37 AM, Matthias Hänel hae...@ultramixer.com wrote:
Hello there,
I have a stage that is been called from a Java Swing application. This is
not a real problem
since I can run follwing code:
PlatformImpl.startup(new Runnable()
{
@Override
public void run()
{
myStage = new myStage();
myStage.show();
}
});
That works so far.
No I would like to close this stage from the swing application. I can call:
Platform.runLater(new Runnable()
{
@Override
public void run()
{
myStage.hide();
}
});
This also works.
Since I have a toggle-Button to hide and show the stage from the swing
application, I would like
to re-show the stage and I would like to know when the stage is showing or
not. This seems to be nearly impossible by now.
What did I try?
1. I tried to shutdown the javafx entire with
com.sun.javafx.tk.Toolkit.getToolkit().exit(); in the hide process. So I
expected to use PlatformImpl.startup again. Unfortunately, it did not work.
2. I tried to leave javafx untouched. The second time I only call
PlatformImpl.runLater to create a new scene.
3. I tried to run it from the swing thread without Platform.run... ... this
failed obviuosly. (I just had no further ideas ;))
Does anyone tried this before? Any advise will be helpful :)
Thanks in advance
Matthias
Re: Stage hide/show from Swing
thanks Tom for your answer.
I just tried to use Platform.setImplicitExit(false) but it didn't do anything
different.
I suspect I should have this runLater behaviour for the second start/show
phase. And hide will not close
the JFX thread interanally. Still there is no Runable call at the second try.
PlatformImpl.runLater(new Runnable()
{
@Override
public void run()
is still not called :(
Matthias
Am 18.05.2015 um 16:26 schrieb Tom Schindl tom.schi...@bestsolution.at:
So then simply call Platform.setImplicitExit(false)?
Tom
On 18.05.15 16:19, Matthias Hänel wrote:
Thanks Scott for your fast answer.
Well, in this case
PlatformImpl.runLater(new Runnable()
{
@Override
public void run()
{
...
is never called. I believe it is not called because the Stage is not running
anymore and
therefore the JFX Main Thread is stopped.
I am now on 1.8.0_60 and have still the same behaviour :(
regards
Matthias
Am 18.05.2015 um 14:17 schrieb Scott Palmer swpal...@gmail.com:
I would have thought that #2 was correct. What happened when you tried it?
Did you make sure JavaFX didn't try to shutdown automatically when the last
Stage was hidden?
Scott
On May 18, 2015, at 7:37 AM, Matthias Hänel hae...@ultramixer.com wrote:
Hello there,
I have a stage that is been called from a Java Swing application. This is
not a real problem
since I can run follwing code:
PlatformImpl.startup(new Runnable()
{
@Override
public void run()
{
myStage = new myStage();
myStage.show();
}
});
That works so far.
No I would like to close this stage from the swing application. I can call:
Platform.runLater(new Runnable()
{
@Override
public void run()
{
myStage.hide();
}
});
This also works.
Since I have a toggle-Button to hide and show the stage from the swing
application, I would like
to re-show the stage and I would like to know when the stage is showing or
not. This seems to be nearly impossible by now.
What did I try?
1. I tried to shutdown the javafx entire with
com.sun.javafx.tk.Toolkit.getToolkit().exit(); in the hide process. So I
expected to use PlatformImpl.startup again. Unfortunately, it did not work.
2. I tried to leave javafx untouched. The second time I only call
PlatformImpl.runLater to create a new scene.
3. I tried to run it from the swing thread without Platform.run... ...
this failed obviuosly. (I just had no further ideas ;))
Does anyone tried this before? Any advise will be helpful :)
Thanks in advance
Matthias
--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
Stage hide/show from Swing
Hello there,
I have a stage that is been called from a Java Swing application. This is not a
real problem
since I can run follwing code:
PlatformImpl.startup(new Runnable()
{
@Override
public void run()
{
myStage = new myStage();
myStage.show();
}
});
That works so far.
No I would like to close this stage from the swing application. I can call:
Platform.runLater(new Runnable()
{
@Override
public void run()
{
myStage.hide();
}
});
This also works.
Since I have a toggle-Button to hide and show the stage from the swing
application, I would like
to re-show the stage and I would like to know when the stage is showing or not.
This seems to be nearly impossible by now.
What did I try?
1. I tried to shutdown the javafx entire with
com.sun.javafx.tk.Toolkit.getToolkit().exit(); in the hide process. So I
expected to use PlatformImpl.startup again. Unfortunately, it did not work.
2. I tried to leave javafx untouched. The second time I only call
PlatformImpl.runLater to create a new scene.
3. I tried to run it from the swing thread without Platform.run... ... this
failed obviuosly. (I just had no further ideas ;))
Does anyone tried this before? Any advise will be helpful :)
Thanks in advance
Matthias
Re: (Multi)Touch with Windows 7
I'll try to answer this inhouse ;) Oracle guys, please correct me if I am wrong. JavaFX 2.2 had touch support for Windows7 and this is still there in JFX8. On the other hand multi touch is only availible from Windows8 on. regards Matthias Am 25.07.2014 um 09:40 schrieb Tobias Bley t...@ultramixer.com: Hi, does anyone know if it’s possible to use JavaFX 8 and touch gestures like swipe on Windows 7? Best regards, Tobi
Re: Exposing native surface or opengl handle
Hey John, Am 26.06.2014 um 10:23 schrieb Robert Krüger krue...@lesspain.de: On Thu, Jun 26, 2014 at 9:40 AM, John Hendrikx hj...@xs4all.nl wrote: On 13/06/2014 08:57, Robert Krüger wrote: Hi, it has been discussed a number of time in the passed but let me quickly summarize: A number of people have requested a feature that provides the ability to have native code draw into a surface provided by a JavaFX application as fast as technically possible, i.e. with no indirection or copying because use cases for this were mostly cases where performance was critical, e.g. HD/UHD video players, real-time visualization etc. where losing even e few percent would make a software written in JavaFX unable to compete with native products (e.g. in the video area nobody will use a video player that is not able to play the content smoothly that VLC player or Quicktime can on the same machine). Although copying is used, I've combined JavaFX and VLC in this fashion for over a year already, and video is smooth and stable -- stable enough to watch full length HD movies, at 20% increased speed (the speed I normally watch them). Of course, if the target machine is barely able to play these, then the extra copying overhead (which is smaller than people think) may be too much. Yes and this becomes more and more a problem of not so weak machines when you go to higher resolutions than FHD that you can display well on a Retina display and thus a competitive disadvantage when targeting that market. I agree that for a lot of video applications the copying approach is probably good enough, though. Well, from my perspective it is always a bad idea to memcpy whenever you can avoid it ;) Our applications do a lot more than just display a video image. I really don't want to have a bottleneck by design. Matthias
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 as a child of the FX window. The problem is that there isn’t a straight-forward, reliable, supported way to get the window handle to use for the parent (JavaFX) window. There are ways to hack it, but they aren’t pretty. Scott On Jun 13, 2014, at 7:55 AM, Robert Krüger krue...@lesspain.de wrote: Just for my understanding: Your approach would be to get the native window handle for the hosting JFX stage, then leave an open space in the layout for e.g. the player canvas that will be implemented natively and then create a native child window that just reacts to move and resize events of its native parent? On Fri
Re: JavaFX 2 + with LWJGL ( OpenGL )
Hey guys, I followed the discussion with interest. I just checked the lwjdlfx-approach. It looked promising in the first place but it has still major performance issues. It is based on the snapshot functionality in the Node base class. This is actually a similar approach we've seen in the JFXPanel which indeed has horrible performance. From my point of view it is not the way to go. What I really like to see is a way to get a textureID directly into the JavaFX opengl context wraped with an Image object. I know it's pretty hard to do this cross-platform and cross-implementation (DirectX, OpenGl) but otherwise JFX can't be mixed with Third-Party applications. Okay, using JFX on top of a OpenGL game just as a replacement of the UI-framework like Ogre-UI etc. might still be a good point since there is no high performance need. In our case we need both high performance UI and high performance additional OpenGL drawings. As of today I could only use JavaFX with a SwingPanel that encapsulates a JOGL context... just my 2 cents Matthias Am 07.04.2014 um 18:47 schrieb Stephen F Northover steve.x.northo...@oracle.com: 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 they limit you like they do. Them trying to recreate the wheel and make their own version of a 3D interface is just plain stupid if it can't run low level. I can see 2D games and applications with a LOT of usage for JavaFX and its 2D graphics API. But True 3D needs low level other wise its a waste of time. Well, thanks for the replies. Guess I'll have to stick with using other sources for my GUI. It's just that I like JavaFX
Re: JFXPanel vs. real world usage
okay, we w#ll do this soon. It's currently inside a bigger project. Since the performance lag is huge, I am not sure how any application could work ;) Technical spoken... I have seen the implementation is something like this: 1. creating a standard swing panel 2. call the software rendering process from paintComponent 2.1. basically, inside the rendering the following is done: 1. capturing the JFX Scene to an IntBuffer. Just this step is very hardware dependent. The capturing from an opengl context is very different for any graphics card. 2. passing the IntBuffer to java 3. draw the IntBuffer to a graphics object From my perspective this code can be used to get nothing better than 10fps on a current state PC, while a direct capsulation of the opengl context would be fps unlimited. regards Matthias Am 24.10.2013 um 21:05 schrieb Stephen F Northover steve.x.northo...@oracle.com: Please enter a JIRA with your sample code attached. Steve On 2013-10-24 2:37 PM, Tobias Bley wrote: I added a simple accordion as JFXPanel into a swing frame and the performance is not good. the cpu usage goes up to 100% when moving the mouse over the accordion title panes (hover effect). The resizing performance is bad too. Am 24.10.2013 um 20:10 schrieb rdarr...@yahoo.com: I have the same experience. We're using this and it works ok as far as performance. -Original Message- From: Pedro Duque Vieira pedro.duquevie...@gmail.com Sender: openjfx-dev-boun...@openjdk.java.net Date: Thu, 24 Oct 2013 18:20:42 To: OpenJFX Mailing Listopenjfx-dev@openjdk.java.net Subject: RE: JFXPanel vs. real world usage Hi Matthias, I don't see any problems with performance and I've been using this a lot. Best regards, -- Pedro Duque Vieira
JFXPanel vs. real world usage
Hi, I just took a look at JFXPanel. This implementation is from my perspective just a pin point for a real implementation. The problem with the current one is, that a JFX scene is rendered down to a pixelbuffer that is rendered on a Swing Panel by paintComponent. Is there a particular reason for this? Actually, I expected the embedding of the OpenGL/DirectX context in other words the heavy weigth component of the entire JFX scene. In the current stage of the JFXPanel it's not even usable for very small addons, since the performance is soo damn bad ;) Maybe I missed another way to get JFX inserted into an existing Swing-Application? Any hints? regards Matthias
mouse vs. touch events on touch systems like iOS/Android/Dukepad
Hi, I believe my conceptual question on touch/mouse events has been missed because of the other questions in the JAVAFX on ANDROID thread. That's why I would like to start a new discussion about touch events. 1. The main question is how are touch and internal mouse events handled? Javafx controls seem to rely on mouse events. That's why I assume there must be some kind of an emulation layer. Are these emulated in Prism, Glass (Java-Glasses) or even lower? Where is it suppose to emulate the mouse events? What I've seen right now is that iOS-native glass does the mouse emulation by itself in GlassViewDelegate.m. Touch events and Mouse events are sent from the lowest layer. In Android there are only touch events passed to the lens implementation. On udev which I assume is the implementation that's used for Dukepad it does only pass touch events. Udev and Android are lens implementations so, they are using the same Java classes which do kind of mouse emulation for toch events. But it's not exactly the same as the iOS codes does. iOS: sends Touch, Mouse-Enter and Mouse-Down Lens (Android/Dukepad): sends Mouse-Enter and Touch The major differences in calling order and the missung mouse down leeds me to the assumption that the events are actually missing. 2. Is that mouse emulation supposed to be eliminated due to the latest lensWindow changes? I believe that must be handled in higher layers not in the input layer itself. 3. What is the input layer for the Dukepad? I think it's the udev implementation and this does pretty much the same as the current android implementation. I just want to have a stable reference to look at ;) 4. Has anyone with a Dukepad the opportunity to test the ListView-Example? For me on Android, it doesn't scroll at all with any touches. With the automatic scrolling (from Richard sources) I get around 30fps on the Samsung Galaxy Tab 10.1. regards Matthias
Re: JAVAFX on ANDROID
Hi Tomas,
I am currently running a bit different openjfx than yours and got it kind of
running.
1. the main difference is font deactivation. You disabled the entire CSS
renderer, which I did not.
I am deactivating just the font renderer. That means a lot more patching but it
gives me the chance
to see CSS rendering taking place ;) It works pretty well even without fonts
(hard coded font sizes).
2. I probably found the touch handling crash. Since I have an old Samusung
Galaxy Tab 10.1 here
I can assure this bug effects the device as well. It's the Platform.runLater
bugfix. This is also quite
stable and makes it possible to play Brickbreaker ;)
3. I had to disable the new security stuff in GlassStage and GlassScene.
further testing:
Tobi, gave me his iOS/JavaFX testing tool that just displays a colored ListView
and while it scrolls
the rendering process writes fps to stdout. This tool compiles and runs but it
does nothing while touching.
The reason is probably that some javafx controls are still using mouse
emulation.
I see in the iOS port that the events are fired twice at first as touch events
and then
as mouse events. It looks like the latest change for multitouch events dropped
the dual event
sending. I tried to patch android.c like this:
JNIEXPORT void JNICALL
Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onMultiTouchEventNative
(JNIEnv *env, jobject jview, jint jpcount, jintArray jactions, jintArray jids,
jintArray jtouchXs, jintArray jtouchYs) {
...
(*_notifyMultiTouchEvent)(jpcount, actions, ids, touchXs, touchYs);
if( jpcount == 1
(actions[0]==com_sun_glass_events_TouchEvent_TOUCH_PRESSED ||
actions[0]==com_sun_glass_events_TouchEvent_TOUCH_RELEASED) )
{
int pressed = 0;
if (actions[0] == com_sun_glass_events_TouchEvent_TOUCH_PRESSED)
pressed = com_sun_glass_events_MouseEvent_DOWN;
else
if (actions[0] == com_sun_glass_events_TouchEvent_TOUCH_RELEASED)
pressed = com_sun_glass_events_MouseEvent_UP;
LOGV(TAG, emulate button click event - UM hacked pressed:%i x:%i
y:%i\n, pressed, touchXs[0], touchYs[0] );
(*_notifyButtonEvent)(pressed,
com_sun_glass_events_MouseEvent_BUTTON_LEFT,
touchXs[0], touchYs[0]);
}
...
}
Unfortunately, it doesn't work as expected.
I have some questions:
1. Is that mouse emulation supposed to be eliminated due to the latest
lensWindow changes?
I believe that must be handled in higher layers not in the input layer
itself.
2. What is the best way to fix this issue? Reimplementing the mouse emulation
is not a real good solution.
3. The Listview shows a scrollbar. That makes me believe that the control
doesn't really know that it is running
in embedded mode. Maybe the mouse emulation is not possible if the embedded
mode is correcly enabled.
Where do I enable the embedded mode? I though it is this property
android.com.sun.javafx.isEmbedded=true. That's of course enabled
in javafx.platform.properties.
4. What is the input layer for the Dukepad? I think it's the udev
implementation and this does pretty much the same as the current
android implementation. I just want to have a stable reference to look at ;)
Probably those questions are not only for Tomas since they are pretty general.
regards
Matthias
Re: JAVAFX on ANDROID
Am 17.10.2013 um 17:45 schrieb Richard Bair richard.b...@oracle.com: Usually, file jira and attach a patch (and a unit test for expedited service :-)) Richard Ok, I'll check that for the future. Actually, I am not sure how a unit test would look like for a crash fix like that ;) Matthias
Re: JAVAFX on ANDROID
Hi, I found the reason for the touch crashes on Android. It's a JNI threading error in the current implementation. We have to enqueue the touch events into the javafx dispatch thread. There is a workaround for this attached in the java source file at dispatchTouchEvent and dispatchKeyEvent. What is the best way to propose changes in the future? regards Matthias Am 15.10.2013 um 13:50 schrieb Matthias Hänel hae...@ultramixer.com: Hey Tomas, I've seen a check-in for RT-32802. This seems to be your fix. There are a lot of interface changes. Could you explain the changes a bit, so I can merge it by hand into my jfx678 code? Today, I merged from Stefans b111 JFX78 but it will take a while to get your changes through this way ;) regards Matthias Am 14.10.2013 um 14:31 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Matthias, cool, I'm surprised you we're able to run it on emulator. I run on device not on emulator for a long time. There wasn't opengl extension GL_EXT_texture_format_BGRA in emulator. But that could have changed overtime. Regarding events: yes there seems to be a problem which I haven't discovered. I've pushed multitouch support and broke touch events on dalvik. I will fix that soon. In order to replace t2k there is freetype library for fonts and glyphs access and harfbuzz for layouting available among system libraries. Although google discourages to use them since they aren't part of public api. It can bring all sorts of compatibility problems (harfbuzz implementation has changed in recent android releases for example). Yes try pango if you have time to spare and share results please. good luck -Tomas On 10/14/2013 01:45 PM, Matthias Hänel wrote: Hi Tomas, never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. There are two things missing: 1. fonts- here we probably need to get pango working for Android right? 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. After fixing the touch events Brickbreaker with Niklas' no-font-patch should work. I'd pleased to test this. kind regards Matthias Am 14.10.2013 um 12:17 schrieb Matthias Hänel hae...@ultramixer.com: Hi Tomas, since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) 10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.659: WARN/System.err(1546): java.lang.reflect.InvocationTargetException 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invokeNative(Native Method) 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invoke(Method.java:525) 10-14 06:06:49.709: DEBUG/dalvikvm(1546): GC_FOR_ALLOC freed 330K, 10% free 4129K/4564K, paused 32ms, total 32ms 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:253) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) 10-14 06:06:49.709: WARN
Re: JAVAFX on ANDROID
the mailerdemon striped my java file ;)
The fixed code snippet from FXActivity.java is:
} else {
//single touch
actions[0] = actionCode;
ids[0] = event.getPointerId(0);
touchXs[0] = (int)event.getX();
touchYs[0] = (int)event.getY();
}
//System.out.println(Android original event = + event);
Platform.runLater(new Runnable()
{
@Override
public void run()
{
onMultiTouchEventNative(pcount, actions, ids, touchXs,
touchYs);
}
});
return true;
}
@Override
public boolean dispatchKeyEvent(final KeyEvent event) {
Platform.runLater(new Runnable() {
@Override
public void run() {
onKeyEventNative(event.getAction(), event.getKeyCode(),
event.getCharacters());
}
});
return true;
}
regards
Matthias
Am 17.10.2013 um 17:01 schrieb Matthias Hänel hae...@ultramixer.com:
Hi,
I found the reason for the touch crashes on Android. It's a JNI threading
error in the
current implementation. We have to enqueue the touch events into the javafx
dispatch thread.
There is a workaround for this attached in the java source file at
dispatchTouchEvent
and dispatchKeyEvent. What is the best way to propose changes in the future?
regards
Matthias
Am 15.10.2013 um 13:50 schrieb Matthias Hänel hae...@ultramixer.com:
Hey Tomas,
I've seen a check-in for RT-32802. This seems to be your fix. There are a
lot of interface changes.
Could you explain the changes a bit, so I can merge it by hand into my
jfx678 code? Today, I merged
from Stefans b111 JFX78 but it will take a while to get your changes through
this way ;)
regards
Matthias
Am 14.10.2013 um 14:31 schrieb tomas.brandalik tomas.branda...@oracle.com:
Hi Matthias,
cool, I'm surprised you we're able to run it on emulator. I run on device
not on emulator for a long time. There wasn't opengl extension
GL_EXT_texture_format_BGRA in emulator. But that could have changed
overtime.
Regarding events: yes there seems to be a problem which I haven't
discovered. I've pushed multitouch support and broke touch events on
dalvik. I will fix that soon.
In order to replace t2k there is freetype library for fonts and glyphs
access and harfbuzz for layouting available among system libraries.
Although google discourages to use them since they aren't part of public
api. It can bring all sorts of compatibility problems (harfbuzz
implementation has changed in recent android releases for example). Yes try
pango if you have time to spare and share results please.
good luck
-Tomas
On 10/14/2013 01:45 PM, Matthias Hänel wrote:
Hi Tomas,
never mind, I found the problem over here in the simulator ;) I had to
activate the GPU support.
So, now I had to BGRA image format for Android and now I get JFX up and
running without fonts.
There are two things missing:
1. fonts- here we probably need to get pango working for Android
right?
2. touch events - I saw that you have got a special Android proxy for the
input stuff
Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative
This seems to crash for some reason. any idea? It's not that complicated
but it is producing a stack trace.
After fixing the touch events Brickbreaker with Niklas' no-font-patch
should work. I'd pleased to test this.
kind regards
Matthias
Am 14.10.2013 um 12:17 schrieb Matthias Hänel hae...@ultramixer.com:
Hi Tomas,
since Tobi told me he had a similiar problem in the first place with the
iOS port and he managed to run JFX8 without font.
We deactivated fonts. There is some code to deactivate and after that it
looks like it is starting the JFX-Application.
10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin
10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow()
from glass.
10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API
10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API
10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API
10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API
10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or
programming error occurred. Framebuffer object status is invalid. (FBO -
823)
10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API
10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object
with TexID 1)
10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API
10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API
10-14 06:06
Re: JAVAFX on ANDROID
Hi Tomas, thanks for your patch. Your way doesn't seem to be so different to the jfx78 approach except the retro-stuff ;) In the meanwhile I am pretty sure, this will not be entirely needed since DAVLIK can run java7 class code. Nevertheless, I tried your patch... Patching works. After adapting some files and putting the correct pathes in the configuration I got the gradle script working. Unfortunatly, I used the tip of openjfx8. That means there is a lot of new stuff e.g. usage of Function.java that's required from jdk8. Which tag did you use? B111 or are you on the cutting edge at tip? I'll try B111 from master hopefully this new stuff isn't in there ;) It looks like porting Function.java back to java7 is not so easy. regards Matthias Am 15.10.2013 um 15:52 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Matthias, you are right when I build for dalvik I build with a flag DALVIK_VM. Pls be careful when building changes in native code you have to do clean build. There is still an issue in jfx gradle script. I create my build differently. I start with openjfx patch it to be jdk7 compatible then use retrolambda to replace class file versions to jdk6. If you want give it a try use attached patch and do following: clone openjfx cd rt patch -p1 fix_jdk7_compat.patch edit android-build.sh with your paths android-build.sh retrojfxrt iI will build dalvik compatible jfxrt6.jar -Tomas On 10/15/2013 03:07 PM, Matthias Hänel wrote: Hi Tomas, I couldn't stand to merge it by hand ;) I merged the changes from RT-32802 into my backport. Unfortunately, it still crashes: 10-15 08:59:47.182: INFO/GLASS(3644): JNI call notifyTouchEvent 10-15 08:59:47.202: INFO/GLASS(3644): Window 1[0x2a41a138] isVisible=true, state=NORMAL 10-15 08:59:47.202: INFO/GLASS(3644): Absolute coordinates 542,414 are on window 1[0x2a41a138] as relative coordinates 670,292 10-15 08:59:47.202: INFO/GLASS(3644): Returning focused window 1[0x2a41a138] 10-15 08:59:47.202: ERROR/dalvikvm(3644): ERROR: detaching thread with interp frames (count=42) 10-15 08:59:47.213: INFO/dalvikvm(3644): main prio=5 tid=1 RUNNABLE 10-15 08:59:47.213: INFO/dalvikvm(3644): | group=main sCount=0 dsCount=0 obj=0x414c5578 self=0x2a00d090 10-15 08:59:47.222: INFO/dalvikvm(3644): | sysTid=3644 nice=0 sched=0/0 cgrp=apps handle=1073811452 10-15 08:59:47.222: INFO/dalvikvm(3644): | state=R schedstat=( 6545290672 1534059118 8044 ) utm=610 stm=44 core=0 10-15 08:59:47.252: INFO/dalvikvm(3644): at com.oracle.dalvik.FXActivity$InternalSurfaceView.onMultiTouchEventNative(Native Method) 10-15 08:59:47.252: INFO/dalvikvm(3644): at com.oracle.dalvik.FXActivity$InternalSurfaceView.dispatchTouchEvent(FXActivity.java:234) Do you have any idea? The error ERROR: detaching thread with interp frames (count=42) seems to be a thread attach/detach mistake in the code. In androidLens.c there is some ATTACH_JNI_THREAD and DTACH_JNI_THREAD code. There are two implementations. One that's filled with (*vm)- and the other one is left blank. Currently, the macro DALVI_VM is not defined, so the code is filled. This seems to be odd to me. Actually, I tried defining DAVLIK_VM but it doesn't help. It still crashes with the sme error. regards Matthais Am 14.10.2013 um 14:31 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Matthias, cool, I'm surprised you we're able to run it on emulator. I run on device not on emulator for a long time. There wasn't opengl extension GL_EXT_texture_format_BGRA in emulator. But that could have changed overtime. Regarding events: yes there seems to be a problem which I haven't discovered. I've pushed multitouch support and broke touch events on dalvik. I will fix that soon. In order to replace t2k there is freetype library for fonts and glyphs access and harfbuzz for layouting available among system libraries. Although google discourages to use them since they aren't part of public api. It can bring all sorts of compatibility problems (harfbuzz implementation has changed in recent android releases for example). Yes try pango if you have time to spare and share results please. good luck -Tomas On 10/14/2013 01:45 PM, Matthias Hänel wrote: Hi Tomas, never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. There are two things missing: 1. fonts- here we probably need to get pango working for Android right? 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. After fixing the touch events Brickbreaker with Niklas' no-font-patch should
Re: JAVAFX on ANDROID
Hey Tomas, I've seen a check-in for RT-32802. This seems to be your fix. There are a lot of interface changes. Could you explain the changes a bit, so I can merge it by hand into my jfx678 code? Today, I merged from Stefans b111 JFX78 but it will take a while to get your changes through this way ;) regards Matthias Am 14.10.2013 um 14:31 schrieb tomas.brandalik tomas.branda...@oracle.com: Hi Matthias, cool, I'm surprised you we're able to run it on emulator. I run on device not on emulator for a long time. There wasn't opengl extension GL_EXT_texture_format_BGRA in emulator. But that could have changed overtime. Regarding events: yes there seems to be a problem which I haven't discovered. I've pushed multitouch support and broke touch events on dalvik. I will fix that soon. In order to replace t2k there is freetype library for fonts and glyphs access and harfbuzz for layouting available among system libraries. Although google discourages to use them since they aren't part of public api. It can bring all sorts of compatibility problems (harfbuzz implementation has changed in recent android releases for example). Yes try pango if you have time to spare and share results please. good luck -Tomas On 10/14/2013 01:45 PM, Matthias Hänel wrote: Hi Tomas, never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. There are two things missing: 1. fonts- here we probably need to get pango working for Android right? 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. After fixing the touch events Brickbreaker with Niklas' no-font-patch should work. I'd pleased to test this. kind regards Matthias Am 14.10.2013 um 12:17 schrieb Matthias Hänel hae...@ultramixer.com: Hi Tomas, since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) 10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.659: WARN/System.err(1546): java.lang.reflect.InvocationTargetException 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invokeNative(Native Method) 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invoke(Method.java:525) 10-14 06:06:49.709: DEBUG/dalvikvm(1546): GC_FOR_ALLOC freed 330K, 10% free 4129K/4564K, paused 32ms, total 32ms 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:253) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) 10
Re: JAVAFX on ANDROID
Hey Tom, thanks for you answer. while the OSX font stuff is there and Orcale's goal is to use the native font renderer on each platform. I am sure there must be some kind of an Android font renderer in the code. I couldn't find one until now. Another question: Since I ported you latest jfx78 to Java6 it's now jfx678 ;) What would be the best way to contribute the port? Do you think it's good to contribute it to jfx78 or to have a separate jfx68 branch? regards Matthias Am 11.10.2013 um 18:22 schrieb Tom Schindl tom.schi...@bestsolution.at: On 11.10.13 18:10, Matthias Hänel wrote: Hi Tomas, today, I took the time to investigate a little more time on this. 1. I build an entirely new openjfx78 build for android 2. starting this gave me several errors that lead me to the conclusion that I need a java6 openjfx 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper is called with a static call to createStyleHelper. That looks like the font stuff is not in jfx78. That's why new Font returns with null and therefore On OS-X font stuff is definately there in jfx78, but the low-level font stuff is loaded using reflection (at least this was the cause on robovm)! Tom
Re: JAVAFX on ANDROID
Hi Richard, thanks for your fast answer. Am 11.10.2013 um 18:53 schrieb Richard Bair richard.b...@oracle.com: As frustrating as it is, the fact is that today Oracle has no announced plans to release any official JVM for Android and iOS. That being the case, the biggest hurdle to getting FX on iOS and Android is the VM. On the iOS side there has been some success with RoboVM. On Android you can just use Dalvik if you back port to Java 6, or you have to find another VM (XMLVM maybe?? Anybody convince Excelsior to support Android?) that can do the job. The main point of irritation comes from an quite unclear position about providing the JVM and JFX of the Java-platform. That's why I will sumarize what I heard between the lines: 1. there is NO official jvm planned for iOS and Android in the near future. 2. jfx8 is beeing officially maintained until some point for iOS and Android but the actual port is left to the open source community. 3. Linux ARM support is beeing focused officially on the Freescale ARM-platform. our conclusion is: 1. that's not that bad anymore since we have RoboVM for iOS and Davlik on Android. 2. this statement should have been made 1 year ago. Probably, I missed it but it was not clear to my team as well until last week. That's why we took the challenge to do it our selves. 3. This is good for the open source development since we probably can rely on the CPU optimized parts for ARM. There are two parts the problem of a VM. One is the VM technology itself, which is probably the lesser of the two issues because there are a handful of decent VMs around (if you include Dalvik, you've already got one on Android). The second problem are the class libraries. Generally JavaFX doesn't rely on too much from JavaSE beyond what is in the base module; threading and collections and concurrency and so forth. However we are using the diamond operator and in a few places we might use multi-catch (although I don't know of such places myself) and definitely we use default methods in interfaces in one location (ObservableList). Generally we've tried to make it easy to back port to 7, but haven't tried to keep 6 up to date. I would be very interested in the list of code changes Matthias had to make to better understand the situation. Yes, mainly it was the multi-catch stuff and the diamonds and some default methods. It's still enough to maintain ;) As far as fonts (from Matthias' email) I believe the Android port currently uses T2K but Felipe and Tomas were talking about using the new Font support which would delegate directly to Android APIs. This might be one area that Matthias' and Felipe and Tomas can work closely on to get a contribution to make this happen! I have seen T2K in the ARM-Linux port but it's not in the sources since it's one of the libraries that are still in the closed parts of OpenJFX. Is there a fallback? Pango doesn't work either it's not used in the android gradle scripts. I would be happy to integrate it and I am sure I can compile pango for android. I just need a pointer to how I can integrate it into the build process. I changed android.gradle but I am not sure where to put the pango sources. How much time do you think it would take community designers to develop this? RoboVM for iOS I think is basically at this stage, where they've got something up and running to the point of being able to do performance analysis and looking for bugs. It has been a several month process with stops and starts. Tom and the others working on RoboVM might be able to give a better estimate. Does it support swing and javafx or just javafx like the Pi port? What parts of java8 don't work on your standalone VM? I couldn't tell you what does / doesn't work on the standalone VM as that would break all kinds of confidential legal mumbo-jumbo. But I can tell you I've never seen a port of AWT to iOS or Android. kind regards Matthias
Re: JAVAFX on ANDROID
Hi Stefan, thanks for your fast answer. Am 12.10.2013 um 00:47 schrieb Stefan Fuchs snfu...@gmx.de: I think you must |add the flag ||-PCOMPILE_PANGO=true to build the new opensource font stuff. I am sure that's not that easy ;) Actually, I tried it but it didn't do anything in the first place. If I remember correctly I got a similar error, when I first build jfx78 on linux. I made some experiments with javafx on android by myself. I found the following interesting read: http://stackoverflow.com/questions/7153989/java-7-language-features-with-android Well, I didn't use jfx78 vanilla, I used it as a base for the port to java6. I am quite sure that we need a java6 port on the long run to support davlik stable. One other problem I hit, when trying to compile a larger application was: http://stackoverflow.com/questions/15508477/android-my-application-is-too-large-and-gives-unable-to-execute-dex-method-id Ok, interessting, I'll take a look at it when I hit the error. Apparently there is a limit of ||65536 methods per apk file. Besides, I'm currently two releases behind with the jfx78. I'll try to catch up soon. It would be great to read your findings. kind regards Matthias
Re: JAVAFX on ANDROID
Hi Felie, thanks for you fast answer. Am 12.10.2013 um 01:36 schrieb Felipe Heidrich felipe.heidr...@oracle.com: The 'native' font stack for Linux uses Pango (to handle complex text) and freetype (rendering glyph images, outlines, metrics, etc). As long as we manage to build our freetype code on Android we should be able to have something that works. As for pango, I heard it is not available on Android, but JavaFX should be able to work without it (except that Arabic, Hebrew, Thai, Indic and other complex scripts won't work). For the long run I would like to implement our glyph-layout code based on Harfbuzz, which is would replace pango entirely and is available on Android. As far as I can see freetype and pango are conntected to each other in the linux implementation. It's not yet possible to compile just freetype without pango and the other way around. Just an idea. Shouldn't it be possible to have javafx running by default when the font renderer is not working? Most applications don't need a very fancy font renderer, many could rely on any software fallback. Don't you think so? kind regards Matthias
Re: JAVAFX on ANDROID
Hi Tomas, thanks for your fast answer. Am 12.10.2013 um 14:04 schrieb Tomas Brandalik tomas.branda...@oracle.com: I think that PlatformLogger initialization in CssHelper was causing problems. I had to write one. I took the compat library fro robovm. I believe this should be sufficient. But the CssStyleHelper was still causing problems. Not 100% sure though I will look at it when I'm back in the office. (Or you can comment out css processing in the node.) I was able to run without font then. Commenting out Css processing in the node is a good I idea which I tried yesterday but the I ran into other errors that will be caused by the same reason front is missing. I would be great, I you could give me a direction for further investigation. regards Matthias
Re: JAVAFX on ANDROID
Hey Niklas, Am 13.10.2013 um 11:49 schrieb Niklas Therning nik...@therning.org: For PlatformLogger et al you can probably use the compatibility lib we have been using for jfx78+RoboVM: https://github.com/robovm/robovm-jfx78-compat Hehe, yes I read it in Tobi's blog post that you wrote one that's why this is what I did in the first place ;) regards Matthias
Re: JAVAFX on ANDROID
:49.759: WARN/System.err(1546): at
com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485)
10-14 06:06:49.769: WARN/System.err(1546): at
com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418)
10-14 06:06:49.769: WARN/System.err(1546): at
com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351)
10-14 06:06:49.769: WARN/System.err(1546): at
com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116)
10-14 06:06:49.769: WARN/System.err(1546): at
com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78)
10-14 06:06:49.769: WARN/System.err(1546): at
com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460)
10-14 06:06:49.769: WARN/System.err(1546): at
com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331)
10-14 06:06:49.779: WARN/System.err(1546): at
com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88)
10-14 06:06:49.779: WARN/System.err(1546): at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390)
10-14 06:06:49.779: WARN/System.err(1546): at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276)
10-14 06:06:49.779: WARN/System.err(1546): at
com.sun.javafx.tk.RenderJob.run(RenderJob.java:58)
10-14 06:06:49.779: WARN/System.err(1546): at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
10-14 06:06:49.779: WARN/System.err(1546): at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
10-14 06:06:49.779: WARN/System.err(1546): at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129)
10-14 06:06:49.779: WARN/System.err(1546): at
java.lang.Thread.run(Thread.java:841)
10-14 06:06:49.779: INFO/GLASS(1546): glass_view_drawEnd
I track the error down to, compileShader in ES2Shader.java on line 130. This is
returning 0 from native code.
The native codes looks okay for me and the Android Simulator is supposed to
emulate OpenGL ES 2.0 correclty, so I am not sure
why the compileShader returns 0...
int vertexShaderID = glCtx.compileShader(vert, true);
if (vertexShaderID == 0) {
throw new RuntimeException(Error creating vertex shader); //---
this Exception occours.
}
I know this is the common error from the shader compiler, but this should have
worked for you,
when you started your own application. Do you have a hint, what I could have
been done wrong?
I assume right now that the native build is correctly, since it is called from
java and it does
return the correct EGLContext. This assumption might be wrong.
regards
Matthias
Am 12.10.2013 um 14:04 schrieb Tomas Brandalik tomas.branda...@oracle.com:
I think that PlatformLogger initialization in CssHelper was causing problems.
I had to write one. Not 100% sure though I will look at it when I'm back in
the office. (Or you can comment out css processing in the node.) I was able
to run without font then.
-Tomas
On 10/11/2013 06:22 PM, Tom Schindl wrote:
On 11.10.13 18:10, Matthias Hänel wrote:
Hi Tomas,
today, I took the time to investigate a little more time on this.
1. I build an entirely new openjfx78 build for android
2. starting this gave me several errors that lead me to the
conclusion that I need a java6 openjfx
3. based on openjfx78 I ported it back to java6 (adapted gradled scripts,
and tons of java source code)
4. Now it's almost running on an 18th android. All libraries are firing up
until the CssStyleHelper
is called with a static call to createStyleHelper.
That looks like the font stuff is not in jfx78. That's why new Font
returns with null and therefore
On OS-X font stuff is definately there in jfx78, but the low-level font
stuff is loaded using reflection (at least this was the cause on robovm)!
Tom
Re: JAVAFX on ANDROID
Hi Tomas, never mind, I found the problem over here in the simulator ;) I had to activate the GPU support. So, now I had to BGRA image format for Android and now I get JFX up and running without fonts. There are two things missing: 1. fonts- here we probably need to get pango working for Android right? 2. touch events - I saw that you have got a special Android proxy for the input stuff Java_com_oracle_dalvik_FXActivity_00024InternalSurfaceView_onTouchEventNative This seems to crash for some reason. any idea? It's not that complicated but it is producing a stack trace. After fixing the touch events Brickbreaker with Niklas' no-font-patch should work. I'd pleased to test this. kind regards Matthias Am 14.10.2013 um 12:17 schrieb Matthias Hänel hae...@ultramixer.com: Hi Tomas, since Tobi told me he had a similiar problem in the first place with the iOS port and he managed to run JFX8 without font. We deactivated fonts. There is some code to deactivate and after that it looks like it is starting the JFX-Application. 10-14 06:06:49.529: INFO/GLASS(1546): glass_view_drawBegin 10-14 06:06:49.529: INFO/javafx(1546): Using getAndroidNativeWindow() from glass. 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/javafx(1546): Some video driver error or programming error occurred. Framebuffer object status is invalid. (FBO - 823) 10-14 06:06:49.579: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.579: ERROR/javafx(1546): Error creating framebuffer object with TexID 1) 10-14 06:06:49.599: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.649: ERROR/libEGL(1546): called unimplemented OpenGL ES API 10-14 06:06:49.659: WARN/System.err(1546): java.lang.reflect.InvocationTargetException 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invokeNative(Native Method) 10-14 06:06:49.669: WARN/System.err(1546): at java.lang.reflect.Method.invoke(Method.java:525) 10-14 06:06:49.709: DEBUG/dalvikvm(1546): GC_FOR_ALLOC freed 330K, 10% free 4129K/4564K, paused 32ms, total 32ms 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2ResourceFactory.createStockShader(ES2ResourceFactory.java:253) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.getPaintShader(BaseShaderContext.java:227) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:485) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:418) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.ps.BaseShaderContext.validatePaintOp(BaseShaderContext.java:351) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.impl.BaseContext.validateClearOp(BaseContext.java:116) 10-14 06:06:49.709: WARN/System.err(1546): at com.sun.prism.es2.ES2Graphics.clear(ES2Graphics.java:78) 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.doPaint(ViewPainter.java:460) 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.ViewPainter.paintImpl(ViewPainter.java:331) 10-14 06:06:49.719: WARN/System.err(1546): at com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:88) 10-14 06:06:49.719: WARN/System.err(1546): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390) 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:276) 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080) 10-14 06:06:49.729: WARN/System.err(1546): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573) 10-14 06:06:49.729: WARN/System.err(1546): at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:129) 10-14 06:06:49.729: WARN/System.err(1546): at java.lang.Thread.run(Thread.java:841) 10-14 06:06:49.729: WARN/System.err(1546): Caused by: java.lang.RuntimeException: Error creating vertex shader 10-14 06:06:49.740: WARN/System.err(1546
Re: JAVAFX on ANDROID
Hi Tomas,
Am 14.10.2013 um 14:31 schrieb tomas.brandalik tomas.branda...@oracle.com:
Hi Matthias,
cool, I'm surprised you we're able to run it on emulator. I run on device not
on emulator for a long time. There wasn't opengl extension
GL_EXT_texture_format_BGRA in emulator. But that could have changed
overtime.
well, this is probably not an coinsidence. I have seen your BGRA quirk, but
this doesn't apply to Android actually.
I fixed it like someone fixed it for iOS:
public boolean isFormatSupported(PixelFormat format) {
GLFactory glFactory = ES2Pipeline.glFactory;
switch (format) {
case BYTE_RGB:
case BYTE_GRAY:
case BYTE_ALPHA:
case MULTI_YCbCr_420:
return true;
case BYTE_BGRA_PRE:
case INT_ARGB_PRE:
if (glFactory.isGL2() || PlatformUtil.isIOS() ||
PlatformUtil.isAndroid()) {
Regarding events: yes there seems to be a problem which I haven't discovered.
I've pushed multitouch support and broke touch events on dalvik. I will fix
that soon.
It would be great, if you could pass the changes to me as well, since I have a
backport (java6) from a backport(java7) running over here ;)
Otherwise, it could take a while.
In order to replace t2k there is freetype library for fonts and glyphs access
and harfbuzz for layouting available among system libraries. Although google
discourages to use them since they aren't part of public api. It can bring
all sorts of compatibility problems (harfbuzz implementation has changed in
recent android releases for example). Yes try pango if you have time to spare
and share results please.
Hhm, this sounds like quite some work. Pango would probably the fastest way to
do. Do you know
where I have to place it?
regards
Matthias
Re: JAVAFX on ANDROID
Hi Tomas, today, I took the time to investigate a little more time on this. 1. I build an entirely new openjfx78 build for android 2. starting this gave me several errors that lead me to the conclusion that I need a java6 openjfx 3. based on openjfx78 I ported it back to java6 (adapted gradled scripts, and tons of java source code) 4. Now it's almost running on an 18th android. All libraries are firing up until the CssStyleHelper is called with a static call to createStyleHelper. That looks like the font stuff is not in jfx78. That's why new Font returns with null and therefore CssStyleHelper crashes. Do you have any idea how to proceed? Do I really have to port JFX8 from Java8 back to Java6 to get a full flegded JFX8 running on Android? That would be pretty heavy it took me nearly 10 hours to port jfx78 to Java6 (without Ensemble). I am willing to contribute, in case we've got a development direction. kind regards Matthias Am 11.10.2013 um 07:51 schrieb Tobi t...@ultramixer.com: Is this standalone vim working with JIT? Does it works well? We recently tried to use the embedded version of oracle JdKs com Linux/ARMv7 soft float on Android but if doesn't work because if missing linked dylibs on Android..,. Am 11.10.2013 um 06:52 schrieb Tomas Brandalik tomas.branda...@oracle.com: COMPILE_TARGETS=android Good, then use FX78 and you can give it a try. I have my local fork of javafx for testing DalvikLauncher. Standalone Vm for Android is not available for download. -Tomas FX78 should be compatible with Java6 because RoboVM is built on dalvik classlib and JavaFX works there! Tom On 10.10.13 22:42, Tobi wrote: Hi Tomas, How did you test the Dalviklauncher? Do you have a Java6 compatible jFX version? And how did you test the JavaSELauncher? Do you have a JVM for android? Where can we download it? Am 10.10.2013 um 22:01 schrieb Tomas Brandaliktomas.branda...@oracle.com: Hi Tobi and Philippe, Android port is being developed in open source so all developers can see every progress. There is nothing to hide. You can understand it as an example of porting javafx runtime to a linux based platform not a product with a roadmap. As you've noticed there are 2 launchers DalvikLauncher and JavaSELauncher. Have a look at DalvikLauncher it is quite simple how it launches an application. What you need to try it out is an java6 (dalvik vm limitation) compatible javafx fork. On the other hand JavaSELauncher uses standalone vm which is not part of the port. It expects that the vm is packaged with an apk. The launcher unpacks vm, installs it, setup classpath, main class debug port etc (all specified in manifest) and launches it . These are the 2 options which can be further extended by the community. best regards -Tomas On 10/10/2013 06:10 PM, Tobias Bley wrote: Tomas from Oracle is working on the Android port of JavaFX. He has developed a DalvikLauncher and a JavaSELauncher. So he is able to tell you (and me :)) more about that important theme „JavaFX on Android“. Best regards, Tobi Am 10.10.2013 um 16:55 schrieb Philippe TIFFEAUphilippe.tiff...@steria.com: Hello, Someone can make a clear answer about JavaFX on ANDROID ? If it works how to use ? Otherwise the roadmap is Best Regard. This email and any attachments may contain confidential information and intellectual property (including copyright material). It is only for the use of the addressee(s) in accordance with any instructions contained within it. If you are not the addressee, you are prohibited from copying, forwarding, disclosing, saving or otherwise using it in any way. If you receive this email in error, please immediately advise the sender and delete it. Steria may monitor the content of emails within its network to ensure compliance with its policies and procedures. Emails are susceptible to alteration and their integrity (including origin) cannot be assured. Steria shall not be liable for any modification to a message, or for messages falsely sent.
Re: Moving on to a round house kick (forked from Re: JavaOne roundup?)
Hi Richard, thank you for your fast answer. I know you are a bussy man. The longer I think about that, the longer I am getting angry to see a 100 men powered development team to build a demo on a demo board for a hand full nerds. I don't know where you got that impression. Jasper did the design, and there were a couple of people who spent a couple weeks working on software. And that wasn't writing the DukePad software, predominantly, but it was fixing performance issues in Prism that affect all platforms. The value is in embedded development. Before JavaOne we didn't have all the agreements in place to work with Freescale. The Raspberry PI has a nice following, is great for educational purposes and home-brew, so it was a great choice to build a demo on top of (as opposed to, say, a BeagleBoard or BeagleBone which is either more expensive or doesn't have the same size following). Having an actual project to work on also teases out bugs and performance issues, and most of the work leading up to JavaOne was in finding and fixing these issues. These same issues will affect any embedded project, including the RoboVM / iOS / Android work. Why do you guys always talk about embedded development? The old days of embbedded stuff have been without an OS. What we are talking about are not really embedded platforms, these are Desktop systems like Linux/Android (linux base)/iOS (berkley based) with energy optimized kernels which are primary used on an ARM CPUs. From my point of view the summary of an ARM cpu, operating systems and toolkits build the platform. Unfortunately, I missed the Freescale announcment. How could I miss it? (I used to work with their Motorola dev boards back in time) http://gigaom.com/2013/09/23/oracle-and-freescale-push-java-for-the-internet-of-things/ I read this announcement and now I hopefully understand the idea where JavaFX should end up. Oracle wants to establish a network of little running devices based on Linux/JavaFX build inside any electric device. Now I understand everything much better. off topic: Nice idea, but keep in mind we have 2013 and it is the phase of consolidation in the software and OS market. The costumer don't want a closed system. Just one question. You want to buy a fridge in late 2014 with a tablet interface on the front door. You are in a very big Target super market. There you will find one with JavaFX powered logo and another one with Google Android. Which one do you buy? What I want to say is, that as long as there are others using well known operating interfaces it will be very very hard to enter this market. Sure there is always a chance to enter a new market but wouldn't it be smart to enter a currently used operating system and let the customer get used to a particular technology? Well that would be ok, if Oracle said that this is a demo on a prototyping board and the important platforms will follow soon. No word about iOS, Android, Windows8. Do you mean Windows Phone 8? Because Windows 8 is a given. Yes, I meant Windows Phone 8. Sure, this is currently not a major player in my opinion it has a much broader audiance and end-user acceptance than a linux based system. Do you really believe that there are many people to build a Tablet like this? I am really sure non of the major hardware manufacturer will build a tablet on top of this platform soon since Android is also free to us and is much more attractive to the end-user. The only thing that I can image is that Oracle comes up with their own iPad-Killer in the near future (don't wait too long) otherwise this decision make no sense to me. No, none of this. DukePad is not a product. We made that pretty clear, it's an open source hardware/software design for the Raspberry PI community. We will make no money off the designs and Oracle isn't selling anything here. For us it was a vehicle on which we could demonstrate our ability to run well on embedded devices, and find and fix bugs along the way. Oracle isn't going to produce a mobile device. DukePad was not any kind of product announcement. Those kinds of things happen in strategy keynotes, not in technical keynotes. Ok, the rasp-pi stuff is done for demonstration purposes and as a development platform. I see. The direction is clearly enriched internet things. That means for me it is the end of my hopes for JavaFX as a game changer on every platform. Thanks for enlighten me, this makes our future decisions a bit easier. kind regards Matthias
Re: Moving on to a round house kick (forked from Re: JavaOne roundup?)
Hi, @Felix: you are kidding are you? We cannot take another breath without choking on it. Sure there are many positive things about JavaFX but in the real world I can't be happy over and over again about the same things. A university can just devlop until a certain point, but we have a running bussiness where we need to decide the future of the underlaying technology. This is my very first post to this mailing list. My collegue tobi is an active member of this community. He is head of the java devlopement department in our company and I am the counterpart by managing the backend native codes and the interfacing to JNI/Java for the upper layers. Since Javafx could be a game changer for our company we have had internal workshops for the developers to get a common sense about the furture of development directions. This summer we focused our development on JavaFX for further products. This meant reworking all UI-stuff, cleaning APIs and fixing JNI for java8. Tobi was soo excited to see the new technologies and his presentation to our fellow developers has been more than ethusiastic. It sounded almost like the old dream code-once-run-anywhere comes true. The closer JavaOne got and the more session of interest for us has been canceled, the more we got fed up over here. As a result non of the session that had been a sort of interest for us had been held. Just to summarize our feeling about that, we are taking this really personally. There is investment of money and time on one side and on the other side it is personal investment into a future technology. I would like to give you an overview of the things that happend and how they appear over here. What did we heard over here from JavaOne? 1. JavaFX is still in development 2. Dukepad is released 3. Oracle wong a sailing cup (4. Javafx runs in a browser) I'll start at the bottom: (4. When Javafx runs in a browser, why do I need it? I could use JavaScript and web technologies as well. This is quite a failure of time investment. Sure write-once-run-anywhere applies but all tough real world applications are not buildable since there is no native interfacing and won't be cross platform in the near future.) 3. Larry Ellison spent 200 million dollar to win a sailing cup. I don't want to image what Oracle could have been done to revolutionize the world. I don't speak only about JavaFX, there is a lot to be done with the right power. But doesn't lead to much here. 2. Wow, there is a JavaFX enabled Dukepad. Beeing a soldering nerd myself, hacking firmware and much cool stuff in my spare time it really kicked me in the first place. Then I grounded when I have seen that it was a childish puzzle with lego blocks. The longer I think about that, the longer I am getting angry to see a 100 men powered development team to build a demo on a demo board for a hand full nerds. Well that would be ok, if Oracle said that this is a demo on a prototyping board and the important platforms will follow soon. No word about iOS, Android, Windows8. Do you really believe that there are many people to build a Tablet like this? I am really sure non of the major hardware manufacturer will build a tablet on top of this platform soon since Android is also free to us and is much more attractive to the end-user. The only thing that I can image is that Oracle comes up with their own iPad-Killer in the near future (don't wait too long) otherwise this decision make no sense to me. 1. JavaFX is in active development is the only great news for me. As of today it looks like a major development for years that is not released for actual use. For me it is currently just a very big shiny demo. short history summarize: 4 years ago when javafx1 hit's the world, desktop use was okay. JavaFX1 couldn't really convince due to an strange way of design. It is okay to make an mistake and to learn from it, so JavaFX2 was create. The software design is outstanding and the potential is not even comparable from my point of view. Well, it was already time to look at the other platforms. 2012 it was announced (but canceled) to run on iOS/Android and now 2013 it was announced again (but canceled). From our current point of view it looks like we just have to use the already developed parts on desktop and for mobile we will have to start a complete new development branch. This will work for a short time but in the long term we'll probably step back from JavaFX and even Java and develop our own abstraction layer. This is sad and costs a lot of time that we would need to build our real products. To make it clear. Everytime I read arm-build I think there is further development in the right direction, but wrong it's still the same linux-arm-build. We don't need an arm build for javafx. We need an iOS-build, an Android-build and a Windows-build for the jre and javafx. Don't get me wrong you can prototype where ever you want even on Pi, but
