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 c
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 : > > 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 ob
Re: Stage hide/show from Swing
Thanks Kevin, I did it like that :)
Matthias
> Am 19.05.2015 um 16:59 schrieb Kevin Rushforth :
>
> Actually, I was saying that you should call Platform.setImplicitExit(false).
> This is good practice for Swing interop applications, and is absolutely
> needed in your case. l Note that this is attribute state so you only need to
> do it once at the beginning of your application.
>
> My other point is that you should not use the internal PlatformImpl class at
> all. It is not supported now, and will stop working in JDK 9. What you should
> do instead is this:
>
> Platform.setImplicitExit(false);
> new JFXPanel();
> Platform.runLater(() -> {
> // your code goes here
> });
>
> You don't actually need to do anything with the JFXPanel unless you want to
> use it to display a JavaFX scene in a Swing component.
>
> -- Kevin
>
>
> Matthias Hänel wrote:
>> Hey Tom and Kevin,
>>
>>
>> thanks for you answers.
>>
>>
>> I see setImplicitExit should be avoided but I don't get it working without.
>>
>> I have now a running version with follwing code:
>>
>>
>> public void show()
>> {
>> Platform.setImplicitExit(false);
>> if( invisibleJFXPanel==null )
>> {
>> PlatformImpl.startup(new Runnable()
>> {
>> @Override
>> public void run()
>> {
>> invisibleJFXPanel = new JFXPanel();
>> invisibleJFXPanel.setSize(100,100);
>> invisibleJFXPanel.setVisible(true); // this should be
>> invisible in the future
>> }
>> });
>> }
>>
>> PlatformImpl.runLater(new Runnable()
>> {
>> @Override
>> public void run()
>> {
>> myStage = new MyStage();
>> myStage();
>> }
>> });
>> }
>>
>> public void hide()
>> {
>> Platform.setImplicitExit(false);
>> if (myStage != null)
>> {
>> Platform.runLater(new Runnable()
>> {
>> @Override
>> public void run()
>> {
>> myStage.hide();
>> }
>> });
>> }
>> }
>>
>>
>> When I understand Kevin correctly, this code should work without any call to
>> Platform.setImplicitExit(false);
>> Unfortunately, it does not.
>>
>>
>> regards
>> Matthias
>>
>>
>>
>>
>>
>>> Am 18.05.2015 um 17:24 schrieb Kevin Rushforth
>>> :
>>>
>>>
>>> You should call Platform.setImplicitExit(false) to disable the default
>>> behavior where the FX toolkit exits when the last Stage is closed.
>>>
>>> One more suggestion:
>>>
>>>
>>>
>>>> PlatformImpl.startup(new Runnable()
>>>>
>>>>
>>> This is not public API and should be avoided. If you are running a Swing
>>> application and want to startup the FX toolkit, you should create a new
>>> instance of JFXPanel (even if you don't use it).
>>>
>>>
>>> -- Kevin
>>>
>>>
>>>
>>>
>>> Matthias Hänel 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 :
>
> 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 :
>>>
>>> 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 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
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 :
>
> 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 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
>>
>>
>>
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 : > 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 : > On Thu, Jun 26, 2014 at 9:40 AM, John Hendrikx 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 : > 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 > 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 >>> 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 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 >&g
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 : > 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 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 : >> 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.at>wrote: > >> 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 : 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
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 : > 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 >>> Sender: openjfx-dev-boun...@openjdk.java.net >>> Date: Thu, 24 Oct 2013 18:20:42 >>> To: OpenJFX Mailing List >>> 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
Re: mouse vs. touch events on touch systems like iOS/Android/Dukepad
Hi Richard, I can't wait to get an answer from Assaf :) regards Matthias Am 22.10.2013 um 18:33 schrieb Richard Bair : > Hi Matthias, I think Assaf, one of the embedded engineers, is now on the > mailing list and can help answer these questions. > > Thanks > Richard > > On Oct 21, 2013, at 1:58 AM, Matthias Hänel wrote: > >> 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 >> >
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
Am 17.10.2013 um 17:45 schrieb Richard Bair : > 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 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
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 :
> 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 :
>
>> 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 :
>>
>>> 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 :
>>>>
>>>>> 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 so
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 : > 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 : > >> 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 : >>> >>>> 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
Re: GlassScene: setSecurityContext()
Hey Tobi, yes, I faced the same on the Android port. After uncommenting the new security stuff in GlassStage and GlassScene it's working again. This is just a preliminary solution. @Oracle is there a legal way that we can use parts of the jdk8 rt.jar? regards Matthias Am 17.10.2013 um 10:17 schrieb Tobias Bley : > Hi, > > why do you introduced the security concept in GlassScene and GlassStage? > setSecurityContext() > > What is the goal? > > The problem is the used class sun.misc.SharedSecrets is not available in the > android class library. Altough I have added it to the robovm compat lib I’m > getting a security error and are not able to start the app on iOS. > > Tobi >
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 : > 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 : >> >>> 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 >>> >
Re: JAVAFX on ANDROID
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 : > 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 : >> >>> 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 s
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 : > 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 : >> >>> 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(ES2Resourc
Re: JAVAFX on ANDROID
Hi Felipe,
thanks for your fast answer.
Unfortunately, this is not enough information for a sufficient solution ;)
Maybe I am too far from gradle away in my thinking (Makefiles) to understand
this one fully.
I know where the sources are and I am pretty sure I can build a library by
hand. Actually, I added
to the android gradle script the Linux fontpango parts and the pkg-config tool.
I assume that the default linux gradle script looks for the pango libs in
/usr/share ...
(default paths). Now we are in a cross platform enviornment for Android. At
least I have to call
./configure with the android toolchain. That should not be hard to do.
What I don't know is, how do I add this to the gradle script?
I see the pkg-config in crosslibs but that relies on the assumption that pango
resides
somewhere in ${SYSROOT}.
Well, I probably could build pango (haven't tried yet) for android and put it
in the NDK,
from my point of view, that wouldn't work later at run time. The .so must be
linked and
delivered with the App. Maybe someone can enlighten me how I can integrate a
third party
library build into the gradle universe ;)
regards
Matthias
Am 14.10.2013 um 17:45 schrieb Felipe Heidrich :
>
> Hi, I'm not familiar with the Android build process but basically this is
> what you need:
>
> Build graphics/src/main/native-font/fontpath_linux.c to a library called
> "javafx_font", that it will be loaded by PrismFontFactory.java (but used by
> FontConfigManager.java).
> This is our fontconfig binding used to locate fonts. All references to
> fontconfig in the native code are dynamic, so you should only need the JNI
> references while building this object.
>
>
> Build
> graphics/src/main/native-font/freetype.c
> and
> graphics/src/main/native-font/pango.c
> To a library named "javafx-font-pango"
>
> The cc flags to build them are "pkg-config --cflags pangoft2" +
> "-D_ENABLE_PANGO", the lib flags are pkg-config --libs pangoft2
> (see rt/buildSrc/linux.gradle, search pangoCCFlags and pangoLinkFlags).
>
> This library will be used by
> graphics/src/main/java/com/sun/javafx/font/pango/OS.java
>
> During runtime you will need to explicitly set "-Dprism.text=native" so that
> PangoFactory.java is used (instead of T2KFactory.java).
>
> Note: if that is too hard to build pango.o I suppose you could link
> javafx-font-pango.so only with freetype.o, you should not see any unsatisfied
> link exception as long as PangoFactory.createGlyphLayout is not called.
>
> Setting -Dprism.debugfonts=true should help to see what is getting loaded,
> -Djavafx.verbose=true prints what library as being loaded by JFX.
>
> Regards,
> Felipe
>
>
> On Oct 13, 2013, at 11:49 PM, Matthias Hänel wrote:
>
>> 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.
>
Re: JAVAFX on ANDROID
Hi Tomas,
Am 14.10.2013 um 14:31 schrieb tomas.brandalik :
> 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, 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 : > 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(QuantumRendere
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 :
> 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
Hey Niklas, Am 13.10.2013 um 11:49 schrieb Niklas Therning : > 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
Hi Tomas, thanks for your fast answer. Am 12.10.2013 um 14:04 schrieb Tomas Brandalik : > 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
Hi Felie, thanks for you fast answer. Am 12.10.2013 um 01:36 schrieb Felipe Heidrich : > 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 Stefan, thanks for your fast answer. Am 12.10.2013 um 00:47 schrieb Stefan Fuchs : > 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 Richard, thanks for your fast answer. Am 11.10.2013 um 18:53 schrieb Richard Bair : > 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
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 : > 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, 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 : > 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 : >> >> 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 > Brandalik: > > 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 >>> TIFFEAU: >>> >>> 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?)
Hey Toni, cancelling the session is one thing. Keeping us in a nebula of hopes is another thing. I'd not say anything if I would have got any information how we can plan for our future product development. Sure those are Oracle legal issues, but inflaming hopes and expectations and the burn down the house makes no sense to me. I don't wan't to blame the engineers but we don't have an appropriate contact to blame ;) I really think the time to calm is very much over. We'll need the solution now, not tomorrow or the day after tomorrow. We will consider other opportunities in the next days. This argy-bargy is not only frustrating it doesn't lead to a solution. JavaFX in a browser: Beeing a native coder myself, in general everything else than hand made assembly doesn't fit my performance expectations ;) I got used to java since the Sun/Oracle guys have done a brilliant gob in optimizing the JRE, so running jit'ed code is pretty fast compared to any interpreted stuff. That's why I accept and kinda love Java as a foundation for a cross platform UI framework and as cross platform deployment solution. Development time tops it all and runtime is feasable. But, when I hear that a single threaded javascript engine should decode java 51'binary code inside a browser my acceptance stop right away ;) It's nearly impossible to run a full fledged multi media application in a browser with for example native backed audio stuff or video mixing. Sure, once browsers interface all kind of audio/video/USB/IEEE1394... it will be possible one time in the future, but it is not yet. As of today, I'll need pretty low level access to the OS to do fancy stuff and that means JNI for Java. This is nearly impossible in a browser. I know Google Native Client but this is not xplatform, so iOS support wouldn't be possible either. Conclusion: You can build nice looking demos with this bck2brwsr project, but when it comes to the real hard stuff you will get stuck pretty fast in your browser bounds. BTW, we tried to replace java with web technology. This is a desaster as well ;) kind regards Matthias Am 30.09.2013 um 17:38 schrieb Anton Epple : > Hi guys, > > I understand your frustration about the cancelled sessions, and I share it. > But when I talk to the engineers and see their posts here, they're clearly > interested in the same stuff we'd like to see in JavaFX. I guess nobody was > more frustrated that these sessions were cancelled than the engineers who > submitted them. If you want to talk about something new and exiting you will > have to let some company lawyers approve it. This takes some time. My guess > is, that the approval for the talks might not have arrived in time. > > If I was right, and the reason for the talks being removed are just of > temporary nature, then I guess the best strategy now is to "keep calm and > carry on" for a bit. > > Regards > > --Toni > > P.s.: @Matthias: > Regarding your thoughts about JavaFX in a browser: > - WORA matters - I think it's the whole point that started this discussion. > - Using Cordova you can package your app as a native app. So you've got a > working solution, which is admittedly not feature complete and not usable for > every application, but much better than nothing. > - JavaScript is a huge problem as it leads to ugly unmaintainable code. Right > now there are tons of projects desperately trying to solve that issue (GWT, > typescript, ...). bck2brwsr is one of the solutions. It enables you to write > clean Java(FX) code and still run in the browser without the need to install > any plugin. So bck2brwsr solves a real world problem. That's why it matters. > > > > > Am 30.09.2013 um 14:03 schrieb Matthias Hänel : > >> 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 dir
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, bu
