Re: Optimised, high-performance, multi-threaded rendering pipeline
We should discuss a new rendering pipeline on the openjfx mailing list. It’s not off topic - it’s an important topic for the future of JavaFX. > Am 28.11.2016 um 06:54 schrieb Felix Bembrick : > > Sorry Gerrit - you did indeed. > > Maybe you'd also like to participate in the offline discussion (especially > now that you don't work for Oracle)? > >> On 28 Nov. 2016, at 16:07, han.s...@icloud.com wrote: >> >> Well I mentioned before that I'm interested too :) >> >> Cheers, >> >> Gerrit >> >> >> Am 27. Nov. 2016, 22:58 +0100 schrieb Felix Bembrick >> : >>> Well, given that you and Benjamin seem to be the only people interested in >>> it, perhaps we should discuss it offline (so as not to bother Oracle or >>> spam list this)... >>> >>>> On 28 Nov. 2016, at 06:57, Tobias Bley wrote: >>>> >>>> Where can we read more about your HPR renderer? >>>> >>>> >>>> >>>> >>>>> Am 25.11.2016 um 16:45 schrieb Felix Bembrick : >>>>> >>>>> Short answer? Maybe. >>>>> >>>>> But exactly one more word than any from Oracle ;-) >>>>> >>>>>> On 26 Nov. 2016, at 00:07, Tobias Bley wrote: >>>>>> >>>>>> A very short answer ;) …. >>>>>> >>>>>> Do you have any URL? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Am 25.11.2016 um 12:19 schrieb Felix Bembrick >>>>>>> : >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>>> On 25 Nov. 2016, at 21:45, Tobias Bley wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> @Felix: Is there any Github project, demo video or trial to test HPR >>>>>>>> with JavaFX? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Tobi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick >>>>>>>>> : >>>>>>>>> >>>>>>>>> Thanks Laurent, >>>>>>>>> >>>>>>>>> That's another thing we discovered: using Java itself in the most >>>>>>>>> performant way can help a lot. >>>>>>>>> >>>>>>>>> It can be tricky, but profiling can often highlight various patterns >>>>>>>>> of object instantiation that show-up red flags and can lead you >>>>>>>>> directly to regions of the code that can be refactored to be >>>>>>>>> significantly more efficient. >>>>>>>>> >>>>>>>>> Also, the often overlooked GC log analysis can lead to similar >>>>>>>>> discoveries and remedies. >>>>>>>>> >>>>>>>>> Blessings, >>>>>>>>> >>>>>>>>> Felix >>>>>>>>> >>>>>>>>>> On 11 Nov. 2016, at 21:55, Laurent Bourgès >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> To optimize Pisces that became the Marlin rasterizer, I carefully >>>>>>>>>> avoided any both array allocation (byte/int/float pools) and also >>>>>>>>>> reduced array copies or clean up ie only clear dirty parts. >>>>>>>>>> >>>>>>>>>> This approach is generic and could be applied in other critical >>>>>>>>>> places of the rendering pipelines. >>>>>>>>>> >>>>>>>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>>>>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>>>>>>> >>>>>>>>>> Of course I would be happy to share my experience and work with a >>>>>>>>>&
Re: Optimised, high-performance, multi-threaded rendering pipeline
Hi, thanks Felix, Laurent and Chris for sharing your stuff with the community! I am happy to see starting a discussion about boosting up the JavaFX rendering performance. I can confirm that the performance of JavaFX scene graph is not there where it should be. So multithreading would be an excellent, but difficult approach. Felix, concerning your research of other toolkits: Do they all use multithreading or are there any toolkits which use single threading but are faster than JavaFX? So maybe there are other points than multithreading where we can boost the performance? 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark with your HPR? Best regards, Tobi > Am 10.11.2016 um 19:11 schrieb Felix Bembrick : > > (Thanks to Kevin for lifting my "awaiting moderation" impasse). > > So, with all the recent discussions regarding the great contribution by > Laurent Bourgès of MarlinFX, it was suggested that a separate thread be > started to discuss parallelisation of the JavaFX rendering pipeline in > general. > > As has been correctly pointed-out, converting or modifying the existing > rendering pipeline into a fully multi-threaded and performant beast is > indeed quite a complex task. > > But, that's exactly what myself and my colleagues have been working on for > about 2 years. > > The result is what we call the Hyper Rendering Pipeline (HPR). > > Work on HPR started when we developed FXMark and were (bitterly) > disappointed with the performance of the JavaFX scene graph. Many JavaFX > developers have blogged about the need to dramatically minimise the number > of nodes (especially on embedded devices) in order to achieve even > "acceptable" performance. Often it is the case that most (if not all > rendering) is eventually done in a single Canvas node. > > Now, as well already know, the JavaFX Canvas does perform very well and the > recent awesome work (DemoFX) by Chris Newland, just for example, shows what > can be done with this one node. > > But, the majority of the animation plumbing in JavaFX is related to the > scene graph itself and is designed to make use of multiple nodes and node > types. At the moment, the performance of this scene graph is the Achilles > Heel of JavaFX (or at least one of them). > > Enter HPR. > > I personally have worked with a number of hardware-accelerated toolkits > over the years and am astounded by just how sluggish the rendering pipeline > for JavaFX is. When I am animating just a couple of hundred nodes using > JavaFX and transitions, I am lucky to get more than about 30 FPS, but on > the same (very powerful) machine, I can use other toolkits to render > thousands of "objects" and achieve frame rates well over 1000 FPS. > > So, we refactored the entire scene graph rendering pipeline with the > following goals and principles: > > 1. It is written using JavaFX 9 and Java 9 (but could theoretically be > back-ported to JavaFX 8 though I see no reason to). > > 2. We analysed how other toolkits had optimised their own rendering > pipelines (especially Qt which has made some significant advances in this > area in recent years). We also analysed recent examples of multi-threaded > rendering using the new Vulkan API. > > 3. We carefully analysed and determined which parts of the pipeline should > best utilise the CPU and which parts should best utilise the GPU. > > 4. For those parts most suited to the CPU, we use the advanced concurrency > features of Java 8/9 to maximise parallelisation and throughput by > utilising multiple cores & threads in as an efficient manner as possible. > > 5. We devoted a large amount of time to optimising the "communication" > between the CPU and GPU to be far less "chatty" and this alone led to some > huge performance gains. > > 6. We also looked at the structure of the scene graph itself and after > studying products such as OpenSceneGraph, we refactored the JavaFX scene > graph in such a way that it lends itself to optimised rendering much more > easily. > > 7. This is clearly not a "small" patch. In fact to refer to it as a > "patch" is probably rather inappropriate. > > The end result is that we now have a fully-functional prototype of HPR and, > already, we are seeing very significant performance improvements. > > At the minimum, scene graph rendering performance has improved by 500% and, > with judicious and sometimes "tricky" use of caching, we have seen > improvements in performance of 10x or more. > > And... we are only just *starting* with the performance optimisation phase. > > The potential for HPR is massive as it opens-up the possibili
Embedding JavaFX in Swing hardware accelerated
Hi, is there any other, more performant, way integrating JavaFX into Swing than using JFXPanel? The problem with JFXPanel is it seams to be not hardware accelerated because JFXPanel makes a snapshot of the JavaFX content and paints to Swing. With this way you can’t include JavaFX content like animations into Swing without getting a poor performance. Best regards, Tobi -- - UltraMixer :: Professional Digital DJ Solution - http://www.ultramixer.com | i...@ultramixer.com
Re: Running JavaFX headless without native dependencies
Hi, thanks for all your hints, but my problem is not to start JavaFX in headless mode with Monocle. I need to start JavaFX without loading any native libraries (e.g. dylibs). But even the software renderer uses native code… So I suppose currently there is no prism/monocle implementation which does not uses any native libraries… Kind Regals, Tobi -- UltraMixer Digital Audio Solutions Am Waldschlößchen 2 D-01099 Dresden Germany http://www.ultramixer.com > Am 05.10.2016 um 09:20 schrieb Daniel Glöckner : > > Hi, > > We're successfully running our full-blown JavaFX application on our build > server to run automated performance tests. > > Monocle is used as a renderer. Here are the relevant JVM arguments: > > -Dglass.platform=Monocle > -Dmonocle.platform=Headless > -Dprism.order=sw > -Dprism.useFontConfig=false > -Dprism.fontdir=" + jdk_path + "/jre/lib/fonts" > > The font dir stuff was required on our build server. I'm sure you need to > tweak this to make it work :) > > Kind regards, > Daniel > >> -Original Message- >> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf >> Of Tobi >> Sent: Tuesday, October 04, 2016 10:39 PM >> To: openjfx-dev@openjdk.java.net Mailing >> Subject: Running JavaFX headless without native dependencies >> >> Hi, >> >> is it possible to run JavaFX in a headless mode without native dependencies? >> Maybe I could use software rendering or monocle to do it? >> >> So I would like to cut off the real render part of JavaFX (e.g. OpenGL or >> DirectX). >> >> >> Thank you for your help. >> >> Best, >> Tobi >
Running JavaFX headless without native dependencies
Hi, is it possible to run JavaFX in a headless mode without native dependencies? Maybe I could use software rendering or monocle to do it? So I would like to cut off the real render part of JavaFX (e.g. OpenGL or DirectX). Thank you for your help. Best, Tobi
Re: What does this mean for the future of JavaFX on iOS?
The question is: How does perform JavaFX in comparison to e.g. Xamarian? > Am 19.04.2016 um 13:14 schrieb Scott Palmer : > > >> On Apr 19, 2016, at 4:18 AM, Felix Bembrick wrote: > >> >> Let's face it, without highly optimised AOT, Java and/or JavaFX on mobiles >> is simply not viable which in turn implies that JavaFX itself is not even >> worth looking at... RIP. > > Let's not go crazy. JavaFX is still the best bet for desktop apps. Despite > all the hype desktop apps aren't going away. Browser-based apps and > JavaScript are still garbage in comparison to what JavaFX offers. > > > Scott
Re: What does this mean for the future of JavaFX on iOS?
Hi, in my opinion the abandonment of RoboVM is a very big step back for Java on Mobile because there is NO real alternative to RoboVM. So it has definitely a big impact on Gluon and JavaFX on Mobile. Gluon uses RoboVM 1.8 - and old version of RoboVM which will be not developed anymore. So no serious company will decide to use a technology which is winding down! So ok, what could Gluon do now? Using OpenJDK9 for iOS and Android? Currently definitely not! OpenJDK9 for Mobile is in an experimental state and uses the Zero interpreter! So the performance will be not acceptable until the OpenJDK 9 provides the same level of AOT like RoboVM - or even better! What can we do now to reach the goal to develop modern mobile applications with Java - instead of with Xamarian…? We need as soon as possible one or more companies to continue the development of one of the RoboVM 1.8 forks (like BugVM) or merge the know how of RoboVM with the current OpenJDK9 efforts… We need commitments of big companies to Java like Oracle, Intel, IBM, SAP! We need the RoboVM team which breaks out of Microsofts Xamarian world! In my dreams Niklas, Henric and their team take the money of Xamarian and Microsoft and revive their baby „RoboVM“ in the context of a fork based on open sourced RoboVM 1.8… Maybe with in a join venture with Intel (concerning Intel’s Multi-OS engine) What do you think about it guys? What are your plans Niklas…? Best regards, Tobi // follow me on twitter: https://twitter.com/tobibley <https://twitter.com/tobibley> > Am 18.04.2016 um 19:15 schrieb Johan Vos : > > Indeed, this doesn't have any impact on JavaFX. > The Gluon tools are currently using the RoboVM AOT 1.8, which was the last > open-source version. > > RoboVM delivered a whole set of products, including an AOT, but also a > system that provides some JNI functionality, a set of bindings that create > Java classes that have a 1-1 mapping to native iOS classes, and a whole > "Studio" allowing developers to create applications. > > Only the AOT is relevant to us. We don't use the bindings, as we happen to > have a great set of UI classes: the JavaFX platform. We don't need the > studio, as we directly provide plugins for NetBeans, IntelliJ and Eclipse. > > The idea of JavaFX is to deliver a cross-platform UI for all devices. > RoboVM took a different approach, as they mainly promoted creating an iOS > specific UI (using the Java bindings to the native iOS UI components) and > an Android specific UI. > > We had different views on a cross-platform UI (JavaFX) versus a > platform-specific UI, but here is no doubt the RoboVM team consist of great > developers and it is a real pity and shame they won't be able to continue > working on their product. > > But for JavaFX and Gluon, it doesn't make a difference. > > - Johan > > > On Mon, Apr 18, 2016 at 6:52 PM, Steve Hannah wrote: > >> According to Gluon, they're not impacted by this. >> https://twitter.com/GluonHQ/status/721784161728471041 >> >> >> >> On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick >> wrote: >> >>> I just read this article which states that RoboVM is effectively >>> "shutting down". >>> >>> https://www.voxxed.com/blog/2016/04/robovm/ >>> >>> Given that they seem to be a critical part of the puzzle that is making >>> JavaFX viable on mobile platforms, what does this actually mean for that >>> goal? >>> >>> Is there an alternative technology or product that can fill this void? Or >>> is the final nail in the coffin for JavaFX to ever be a truly viable cross >>> platform technology? >>> >>> Thanks, >>> >>> Felix >> >> >> >> >> -- >> Steve Hannah >> Web Lite Solutions Corp. >>
JavaFX Metal port ob Mac OSX 10.11 El Capitan
Hi, Are there any plans to port prism to use the new fast metal rendering pipeline on the upcoming OSX 10.11? Best regards, Tobi
Re: JavaFX on iOS and Android: The real problem and challenge
There must be other reasons than money to do not support jfx on mobile because oracle could also sell licenses for JFX on mobile. I am tired to discuss this topic again and again. The point is: oracle does not talk to the community. Richard tries to do it within the legal zone but that is not satisfying for us and this discussion. Just a dream: what would happen if the JavaFX team of Oracle would Leave the company and start a "spin off" to develop and promote jFX as real cross platform solution for desktop, mobile, embedded and web. That would be the real juck Norris experiment ;) Cheers Tobi blog.software4java.com > Am 10.11.2013 um 05:39 schrieb Felix Bembrick : > > Tobi, I don't think the issue of whether Oracle stands to make any money out > of JavaFX on mobiles is relevant as I discussed here > http://news.kynosarges.org/2013/10/10/javafx-on-ios-android/ and from which > this excerpt is taken: > > "Now, on the point of little or no revenue coming Oracle’s way directly from > JavaFX, the Glass Half Empty approach is to believe that JavaFX on iOS and > Android *has* to generate revenue for Oracle to be interested in it. The > Glass Half Full approach is to recognise that this is total fallacy and I’ll > tell you why… > When you go to buy a car, you go to a car dealer whose core business is > selling cars… right? Wrong! The car dealer’s core business is actually > servicing cars and selling spare parts. Most dealers actually make a *loss* > on the sale of vehicles themselves and make the vast majority of their > revenue and profits from servicing the cars and through selling spare parts > to maintain them. The selling of cars is just a tool to enable their core > business to exist. > > And it’s the same with Oracle and JavaFX on iOS and Android. Their core > business is in licensing Java for embedded platforms and that is why you see > so much focus on JavaFX on Raspberry Pi for example and an “official” JDK8 > release for such hardware devices. However, for JavaFX to succeed long-term > and be a viable technology into the future it *has* to run on the devices > that most people already use namely mobile phones and tablets. > > Having JavaFX run on these platforms is akin to selling vehicles in my > example whereas licensing Java on embedded platforms is the core business. > One enables the other." > > So basically, Oracle doesn't need to make any money from JavaFX on mobiles > for it to be considered an important port. > > We need to encourage Oracle to let us in on their efforts in this area and I > am sure the excellent work done on RoboVM can become part of that. As I > said, there just aren't enough resources to maintain two projects basically > trying to do the same thing. Whether that means enhancing RoboVM to work > with OpenJFX/OpenJDK 8 or contributing to an Oracle-created project i just > don't know at this time. > > Felix > > > > > >> On 10 November 2013 06:23, Tobias Bley wrote: >> The question is: Is JavaFX for mobile a business for Oracle to make big >> money? I suppose Oracle don’t believe in it. They believe in servers, cloud >> and the „Internet of Things“ - that’s why they invest in Rasp.PI, >> Freescale, etc. >> >> btw: With „Oracle“ I mean „the management of Oracle“, not the guys of >> Richards team. >> >> For me: RoboVM & OpenJDK is the right direction. >> >> >> Am 09.11.2013 um 19:15 schrieb Tom Eugelink : >> >> > >> > Oracle has a strict do-not-communicate-what-is-not-certain policy and I >> > actually commend them for it. Better to not communicate than make promises >> > you can't keep (I'm seeing the effect on that in many of the projects I'm >> > asked to assist). I think the urgency of mobile platforms is clear to >> > Oracle, given the recent focus on JavaME and the internet-of-things. >> > Patience is a virtue. >> > >> > My 2 cents, >> > >> > Tom >> > >> > >> > On 2013-11-9 18:21, Pedro Duque Vieira wrote: >> >> Sure we should listen to Richard. He is doing a great job as well as his >> >> team. >> >> I don't think however that enough is being communicated.. >> >> >> >> I don't think those legal boundaries are being layed out explicitly. >> >> What are those legal boundaries? >> >> Will RoboVM not be subject to those legal issues? >> >> What's the difference between us creating a project and trying to >> >> integrate >> >> it into openjdk and Oracle doing it? >> &g
Re: JAVAFX on ANDROID
I absolutely agree. The point is: nobody can expect from oracle to build such a vm. But if they won't do it, JavaFX will die. Even in the embedded space where companies will use QT or HTML5 instead. Without license fees So to sell JavaFX for embedded devices oracle MUST support mobile platforms via VM too. Von meinem iPhone gesendet > Am 14.10.2013 um 07:09 schrieb Tom Eugelink : > > >> On 2013-10-14 01:06, Rafal wrote: >> If you honestly encourage community to make a such big effort as developing, >> adjusting and maintaining JVMs on the two leading mobile platforms, you >> don't have any plans that Oracle VM on android will be released in the next >> 2 years. :/ >> Otherwise, if Oracle announce own VM, then all this community's effort be >> for nothing and pointless. > > Open source done in the spare time by people with a full time job usually > never grows much bigger than a nice but not too complex library; layout > engines, testing frameworks, a web framework, that kind of stuff. Because as > a project grows in size and complexity, so do the (number of) issues and the > time required to provide support. That usually is the point where either a > company is started (projects like Maven and Gradle) or the project gets > corporate "funding" usually by that a corporation allows some developers to > spent worktime on it (Apache, Eclipse, and Java & JavaFX is getting there). > > A full fledged port of a JVM to a mobile platform cannot be carried in spare > time, it can be showcased (which it has), but to make it production worthy > one or more corporations needs to put their weight behind it. > > My 2 cents, > > Tom >
Re: JAVAFX on ANDROID
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: JAVAFX on ANDROID
No, targets=Android > Am 10.10.2013 um 22:41 schrieb Tom Schindl : > > So when I compile my own FX what target to I compile to? I guess I > compile on linux, right? > > Tom > >> On 10.10.13 22:01, Tomas Brandalik wrote: >> 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: JAVAFX on ANDROID
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: Raspberry Pi + JavaFX 3D demo
Painting a plain rectangle is ok. But using a stackpane to draw a javafx styled button over a plain painted rectangle node is very slow. Am 12.07.2013 um 17:03 schrieb Richard Bair : > BTW, we've run a VM performance benchmark against HotSpot on PI vs. RoboVM on > iOS and for raw power RoboVM seems faster (lower time to invoke a method, > read a field, etc etc). However in the real world RoboVM is slow and I don't > know why (GC overhead maybe)? > > Richard > > On Jul 12, 2013, at 7:52 AM, Richard Bair wrote: > >> That should be encouraging, since the CPU on the PI is *way* worse than the >> CPU on an iPhone or iPad. Is the difference HotSpot vs. RoboVM? The graphics >> code being executed should be pretty much exactly the same, and I would >> expect the PowerVR to be able to handle this without any trouble. >> >> Richard >> >> On Jul 12, 2013, at 7:14 AM, Tobias Bley wrote: >> >>> The performance is much better than JavaFX8 on iOS :( >>> >>> >>> Am 12.07.2013 um 15:37 schrieb August Lammersdorf, InteractiveMesh >>> : >>> Found this on YouTube: http://www.youtube.com/watch?v=-scxqJjTJKI August >>> >> >
Re: JDK 8 for ARM Early Access Releases (with JavaFX)
So where is JDK8 for ARMv7 for iPad and IPhone Oracle ;)? Am 10.07.2013 um 16:22 schrieb Gerrit Grunwald : > I made some tests already and I have to say it works really well. You can > also use custom JavaFX8 controls without any problem. I just saw some > problems with complex -fx-shape based paths. The performance improvements are > really visible, so Oracle did a good job here. > Because it's based on b97 you can also use lambdas, 3D and even Nashorn > should be useable (even if I did not tried yet). > > Now it's really useful because you could easily use the same jar of your > application and let it run on the Pi without any modification. > > Cheers, > > Gerrit > > > > Am 10.07.2013 um 16:14 schrieb Robert Krüger : > >> If anyone plays around with this on the Raspberry, please share your >> experience here. >> >> On Wed, Jul 10, 2013 at 3:09 PM, wrote: >>> JDK 8 for ARM hard float is now part of the regular JDK 8 Early Access >>> releases. You can get it athttps://jdk8.java.net/download.html; this >>> >>> page will be regularly updated with new builds. >>> >>> As in the previous Early Access release, this includes JavaFX for the >>> Raspberry Pi. >>> >>> Daniel >
Re: JavaFX8 on iPhone! It works!
Maybe there is a AOT based JavaVM from http://www.excelsior-usa.com/ available soon for iOS... Am 06.07.2013 um 04:34 schrieb Richard Bair : > It's complicated. We've prototyped on all kinds of VMs including the CVM used > with ADF mobile and a hacked up Java SE embedded 7. It's a long way from > prototype to product and as I mentioned on my blog we have not announced any > plan around SE embedded VM on iOS / Android. But at least we know that our > port of fx was (mostly) functional and could be successful. > > On Jul 5, 2013, at 12:44 PM, Tobias Bley wrote: > >> Richard, the question is: Has Oracle a hidden Java8 VM for Android and iOS? >> Or how do you test your Android and iOS JavaFX implementation??? >> >> >> Am 05.07.2013 um 16:42 schrieb Richard Bair : >> >>> We have implementations for Android and iOS that are both functional on a >>> Java 8 VM. It looks like, because the iOS one is so closely related to the >>> Mac build, it was the easiest one to get a build for the open community. >>> We're working on the Android build scripts. The situation on Android is >>> exactly the same as iOS -- we're open sourcing the library code, but not a >>> Java 8 VM. I would expect that if the iOS build on RoboVM works, that the >>> Android build for RoboVM would also work, but I haven't tried it. >>> >>> Richard >>> >>> On Jul 5, 2013, at 5:07 AM, Daniel Zwolenski wrote: >>> Thanks Niklas - sounds like there's still a bit to do. I'm still a bit confused though, I thought the JFX team were/are giving us a version of jfx that is specifically designed to work on Android but it sounds like that's pretty far from the actuality? What will the gradle build for android actually give us? I'd be keen to hear from someone on the jfx side on all of this. Is this how you planned for your smart device releases to work or has something gone wrong in the journey here? On 05/07/2013, at 9:57 PM, Niklas Therning wrote: > >>
Re: JavaFX8 on iPhone! It works!
Mono is not Java and does not need the android java class library... Von meinem iPhone gesendet Am 05.07.2013 um 14:37 schrieb Hervé Girod : > I'm with Tobias. Android class library has really stalled a lot compared to > Java, and it wont improve in the future, and sticking to an outdated class > library is not very interesting IMO. > > Beside we don't specifically need Android class library to compile AOT. Mono > work on Android, and it even does not use Android class library. > > Hervé > > Sent from my iPhone > > On 5 juil. 2013, at 13:57, Niklas Therning wrote: > >> Even the latest version of Android are missing these classes and Dalvik >> (the VM in Android) doesn't support invokedynamic so a backport is >> required, not just for RoboVM. I managed to get Ensemble working yesterday >> on iOS with the jfx78 sources and RoboVM. But even this backport contains >> code which won't work on Android nor on RoboVM. E.g. I had to patch >> FontFileWriter to get Ensemble working (it uses java.nio.file.Files which >> is a Java7+ class). IMO the backport needs to target Android/RoboVM >> specifically and not Java7. A first step would be to make it compile with >> Java6. >> >> >> On Fri, Jul 5, 2013 at 1:21 PM, Tobias Bley wrote: >> >>> Maybe the missing classes in the android classes used by RoboVM are only >>> missing in an old android class library and Oracles android port is based >>> on a newer version? >>> >>> >>> Am 05.07.2013 um 13:11 schrieb Daniel Zwolenski : >>> >>>> This is great Tobi, thanks! >>>> >>>> I'm a bit confused though - seems to be mixed messages on the need for >>> the 78 backport? >>>> >>>> Danno, since Niklas is saying we need the backport, what steps do we >>> need to take to get this working? >>>> >>>> I also don't understand Tobi's comments below about not using the >>> android jdk. What is it that's not working, and isn't jfx suppose to run on >>> android as well? >>>> >>>> >>>> >>>> On 04/07/2013, at 11:53 PM, Tobias Bley wrote: >>>> >>>>> I published by blog post about using JavaFX8 and RoboVM to build a iOS >>> app: http://blog.software4java.com/?p=41 >>>>> >>>>> @Niklas: IMO it’s important that RoboVM support OpenJDK as alternative >>> to the android class library because OpenJFX depends on OpenJDK not on >>> Android class library (Apache Harmony). >>>>> >>>>> Best regards, >>>>> Tobi >>>>> >>>>> Am 04.07.2013 um 14:49 schrieb Niklas Therning : >>>>> >>>>>> RoboVM doesn't do invokedynamic so I guess this only works if the app >>>>>> doesn't depend on any of the code in JavaFX8 that compiles down to >>>>>> invokedynamic calls. Also, there are quite a few API's available in >>> Java8 >>>>>> (and also Java7) that RoboVM doesn't have. We really need to get the >>> jfx78 >>>>>> backport to compile for iOS and generate the static libs properly. >>>>>> >>>>>> I've just got the font related code in the BrickBreaker sample working >>>>>> using the jfx78 backport. There's still a bit of manual command line >>> work >>>>>> needed to merge the static libraries into universal libraries like the >>> old >>>>>> ant build system did automatically. But it isn't too hard. I'll try to >>> put >>>>>> up instructions on the robovm blog later today. I'll let you know. >>>>>> >>>>>> >>>>>> On Thu, Jul 4, 2013 at 1:31 AM, wrote: >>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> >>>>>>> On 03/07/2013 7:17 PM, Daniel Zwolenski wrote: >>>>>>> >>>>>>>> Can I just use this: https://jdk8.java.net/**download.html< >>> https://jdk8.java.net/download.html>? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 4, 2013 at 9:15 AM, Daniel Zwolenski >>>>>>>> wrote: >>>>>>>> >>>>>>>> Thanks Richard, in the building for Mac section there is a link to >>>>>>>>> "Install the late
Re: iOS: Calling native methods on iPhone
Yes I know and I tried it already. But it throws an classCastException when setting the delegate to imagepicker. I think the problem could be that I do not use cocoa touch for the UI, I use javafx. Am 05.07.2013 um 14:03 schrieb Niklas Therning : > RoboVM already has bindings for most of the stuff in UIKit, > UIImagePickerController included [1]. It's in the robovm-cocoatouch.jar file > included in the download. It's mostly untested though. Please go ahead and > try it out and let me know how it goes. > > [1] > https://github.com/robovm/robovm/blob/master/cocoatouch/src/main/java/org/robovm/cocoatouch/uikit/UIImagePickerController.java > > > On Fri, Jul 5, 2013 at 12:26 PM, Tobias Bley wrote: >> Hi Tom, >> >> thats great! We need such efforts! >> the goal should be to use the automatically wrapped UIKit from Java, call >> the image picker and fetch an image from the iphone to show it in JavaFX! >> >> Who is the first guy who posts a demo image ;)? >> >> Best regards, >> Tobi >> >> It would be fantastic to have a real use case for using a native cocoa touch >> function in JavaFX (on RoboVM). I suggest to load an image via ImagePicker >> from the iPhone image library. So we need to use the UIKit framework and the >> UIImagePickerController... >> >> Am 05.07.2013 um 11:56 schrieb Tom Schindl : >> >> > Hi, >> > >> > To not write the bro stuff manually I fired up xtext yesterday and created >> > a small DSL which holds the (relevant) Header-Information and generates >> > the Bro-Files for you. >> > >> > You can see the input >> > https://github.com/tomsontom/objcgenerator/tree/master/bundles/at.bestsolution.objc.mapper.cocoatouch/mappings >> > and output >> > https://github.com/tomsontom/objcgenerator/tree/master/bundles/at.bestsolution.objc.mapper.cocoatouch/src/main/java/org/robovm/cocoatouch/corelocation >> > . >> > >> > Currently it is bound to Eclipse but I could add support to run the mapper >> > on the command line as well. >> > >> > Tom >> > >> > On 04.07.13 18:16, Tom Schindl wrote: >> >> Robovm does that without jni it is called bro >> >> >> >> Tom >> >> >> >> Von meinem iPhone gesendet >> >> >> >> Am 04.07.2013 um 17:44 schrieb Tobias Bley : >> >> >> >>> Hi, >> >>> >> >>> after successfully using JavaFX (including font and CSS) on iOS I tried >> >>> to call native code on iPhone. I successfully fetched and visualized the >> >>> battery level of the iPhone! >> >>> >> >>> To do this I wrote objective c code and bind it to Java via JNI. No >> >>> problem so far. >> >>> >> >>> >> >>> >> >>> But what I would like to do is using a technology like JNA to directly >> >>> access Cocoa frameworks without writing native JNI code. Does anybody >> >>> knows if JNA (or something else) could also be used in RoboVM? >> >>> >> >>> Best regards, >> >>> Tobi >> >>> >> >>> >> >>> >> > >
JavaFX8 on iPhone! It works!
It works! Latest JavaFX 8 (gradle based) with RoboVM on a real iPhone with native text rendering and JFX CSS rendering! Tobi
OpenJDK 32 bit on Mac?
Hi, Is it possible to build the OpenJDK for Mac with 32bit?
Using RoboVM+JavaFX8+Bro to develop apps for iOS and Android? - Google Groups
https://groups.google.com/forum/m/?fromgroups#!topic/robovm/Iii-ARUp3W0 Von meinem iPhone gesendet
