From kevin.rushforth at oracle.com Mon Apr 3 20:22:11 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 03 Apr 2017 13:22:11 -0700 Subject: review: Generate bss for all css files, remove TODO In-Reply-To: <58DD50A2.80707@Oracle.com> References: <58DD4560.3030000@Oracle.com> <856d76a1-bdd0-0aa3-e7d3-c22e087519bc@oracle.com> <58DD50A2.80707@Oracle.com> Message-ID: <58E2AEF3.30702@oracle.com> Inline David Hill wrote: > On 3/30/17, 1:57 PM, David Grieve wrote: >> The question I have about this change is, do you necessarily want all >> of the css/bss files that may be in that directory in the dist? If >> someone adds a css file in the future, should it be a conscience >> decision to put it into the dist? > David, > > Certainly a valid question, and one that was answered "yes", at least > so far. > We already as shipping the .css files but only converting some of them. > > This change means we ship the bss to go with them. Exactly. By converting them all we treat them the same way as .java --> .class files are handled. All .java files are compiled and all generated .class files are included by default. > The gradle code block can easily tolerate the addition of exclusions > if needed. Indeed. We can filter them like we do with .class files in some cases. > The other part of the question was if we even should ship the .css > files a all and css2bin. To shorten a long conversation, continuing to > do so allows widget developers access to them, access we have no other > standard way of providing. This seems like it should be a separate question, and dealt with as a separate JBS issue, if we decide there is good reason to stop delivering the .css files. I don't think we have a compelling reason to exclude them. -- Kevin > Dave >> >> >> On 3/30/17 1:50 PM, David Hill wrote: >>> >>> Jonathan, >>> please review this change automating the CSS to BSS conversion in >>> our build >>> The list of 6 newly converted files as well as the existing ones are >>> in the JBS. >>> So 9 existing plus 6 new = 15. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8174944 >>> webrev: http://cr.openjdk.java.net/~ddhill/8174944/ >>> >> > > From Rony.Flatscher at wu.ac.at Tue Apr 4 16:37:36 2017 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Tue, 4 Apr 2017 18:37:36 +0200 Subject: t e / s t Message-ID: <19eef8be-d850-5302-746e-12a50fb35c35@wu.ac.at> In case this e-mail makes it to the openjfx-dev-list, please ignore it. (I have been trying for months to post a message without success.) ---rony From semyon.sadetsky at oracle.com Tue Apr 4 17:27:07 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 4 Apr 2017 10:27:07 -0700 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 Message-ID: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8176844 webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/ --Semyon From semyon.sadetsky at oracle.com Tue Apr 4 17:28:13 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 4 Apr 2017 10:28:13 -0700 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 In-Reply-To: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> References: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> Message-ID: <0c028498-abb9-bff3-ea67-44595d9020b7@oracle.com> Sorry. The fix is for JFX *10*. On 04/04/2017 10:27 AM, Semyon Sadetsky wrote: > Hello Kevin & David, > > Please review the fix for jfx9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8176844 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/ > > --Semyon > From semyon.sadetsky at oracle.com Tue Apr 4 19:21:47 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 4 Apr 2017 12:21:47 -0700 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 In-Reply-To: <0c028498-abb9-bff3-ea67-44595d9020b7@oracle.com> References: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> <0c028498-abb9-bff3-ea67-44595d9020b7@oracle.com> Message-ID: <557e7e78-5849-a3bd-cb40-3a3810563c98@oracle.com> it also fixes https://bugs.openjdk.java.net/browse/JDK-8171980 --Semyon On 04/04/2017 10:28 AM, Semyon Sadetsky wrote: > Sorry. The fix is for JFX *10*. > > > On 04/04/2017 10:27 AM, Semyon Sadetsky wrote: >> Hello Kevin & David, >> >> Please review the fix for jfx9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8176844 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/ >> >> --Semyon >> > From David.Hill at Oracle.com Tue Apr 4 22:43:30 2017 From: David.Hill at Oracle.com (David Hill) Date: Tue, 04 Apr 2017 18:43:30 -0400 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 In-Reply-To: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> References: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> Message-ID: <58E42192.5000706@Oracle.com> On 4/4/17, 1:27 PM, Semyon Sadetsky wrote: > Hello Kevin & David, > > Please review the fix for jfx9: > > bug: https://bugs.openjdk.java.net/browse/JDK-8176844 > > webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/ > > --Semyon > Semyon, I have been sitting here for a while thinking about adding gdk_display_sync(gdk_display_get_default()); I can see why this might address many issues, as it flushes the pipeline and waits for the X11 server to catch up. That is balanced out by a historical distrust of using XSync in any situation where the consequences. Part of me thinks it is minimal overhead though, the other part does not like stalling the asynchronous X11 design. The other part of me would like to use this only for the window events that need it, instead of all of them. and I found this in hte GTK docs: gdk_events_pending () Waits for a GraphicsExpose or NoExpose event from the X server. This is used in the GtkText and GtkCList widgets in GTK+ to make sure any GraphicsExpose events are handled before the widget is scrolled. so perhaps this should be used in some cases (like setVisible). sigh. Will try to make up my mind tomorrow. Dave. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From philip.race at oracle.com Tue Apr 4 22:53:23 2017 From: philip.race at oracle.com (Philip Race) Date: Tue, 04 Apr 2017 15:53:23 -0700 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 In-Reply-To: <58E42192.5000706@Oracle.com> References: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> <58E42192.5000706@Oracle.com> Message-ID: <58E423E3.20600@oracle.com> AWT used to have really bad at X11 remote display and it was looked at a few times and I think it was improved noticeably when we could get rid of "round trip" requests. I think Jim had a hand in some of that work. So I am sure a round trip - or similar - is bad for performance. If you want to measure the effect of such change, remote display to your desktop from a machine in a geographically distant site. It is the latency that kills performance, not the bandwidth. -phil. On 4/4/17, 3:43 PM, David Hill wrote: > On 4/4/17, 1:27 PM, Semyon Sadetsky wrote: >> Hello Kevin & David, >> >> Please review the fix for jfx9: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8176844 >> >> webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/ >> >> --Semyon >> > > Semyon, > > I have been sitting here for a while thinking about adding > gdk_display_sync(gdk_display_get_default()); > > I can see why this might address many issues, as it flushes the > pipeline and waits for the X11 server to catch up. That is balanced > out by a historical distrust of using XSync in any situation where the > consequences. > > Part of me thinks it is minimal overhead though, the other part does > not like stalling the asynchronous X11 design. > > The other part of me would like to use this only for the window events > that need it, instead of all of them. > > and I found this in hte GTK docs: > gdk_events_pending () > Waits for a GraphicsExpose or NoExpose event from the X server. This > is used in the GtkText and GtkCList widgets in GTK+ to make sure any > GraphicsExpose events are handled before the widget is scrolled. > > so perhaps this should be used in some cases (like setVisible). > > sigh. > > Will try to make up my mind tomorrow. > > Dave. > From David.Hill at Oracle.com Tue Apr 4 23:28:31 2017 From: David.Hill at Oracle.com (David Hill) Date: Tue, 04 Apr 2017 19:28:31 -0400 Subject: Review: Provide generic add-exports mechanism Message-ID: <58E42C1F.7080009@Oracle.com> Kevin, Jonathan, https://bugs.openjdk.java.net/browse/JDK-8178075 webrev: http://cr.openjdk.java.net/~ddhill/8178075 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From james.graham at oracle.com Tue Apr 4 23:48:37 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 4 Apr 2017 16:48:37 -0700 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 In-Reply-To: <58E423E3.20600@oracle.com> References: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> <58E42192.5000706@Oracle.com> <58E423E3.20600@oracle.com> Message-ID: I don't think I was specifically involved in AWT fixes for that issue, but the concerns that David raises are all valid and Phil correctly points out that this is much worse in a network display environment... ...jim On 4/4/17 3:53 PM, Philip Race wrote: > AWT used to have really bad at X11 remote display and > it was looked at a few times and I think it was improved > noticeably when we could get rid of "round trip" requests. > I think Jim had a hand in some of that work. > > So I am sure a round trip - or similar - is bad for performance. > > If you want to measure the effect of such change, remote display to > your desktop from a machine in a geographically distant site. > > It is the latency that kills performance, not the bandwidth. > > -phil. > > On 4/4/17, 3:43 PM, David Hill wrote: >> On 4/4/17, 1:27 PM, Semyon Sadetsky wrote: >>> Hello Kevin & David, >>> >>> Please review the fix for jfx9: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8176844 >>> >>> webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/ >>> >>> --Semyon >>> >> >> Semyon, >> >> I have been sitting here for a while thinking about adding >> gdk_display_sync(gdk_display_get_default()); >> >> I can see why this might address many issues, as it flushes the pipeline and waits for the X11 server to catch up. >> That is balanced out by a historical distrust of using XSync in any situation where the consequences. >> >> Part of me thinks it is minimal overhead though, the other part does not like stalling the asynchronous X11 design. >> >> The other part of me would like to use this only for the window events that need it, instead of all of them. >> >> and I found this in hte GTK docs: >> gdk_events_pending () >> Waits for a GraphicsExpose or NoExpose event from the X server. This is used in the GtkText and GtkCList widgets in >> GTK+ to make sure any GraphicsExpose events are handled before the widget is scrolled. >> >> so perhaps this should be used in some cases (like setVisible). >> >> sigh. >> >> Will try to make up my mind tomorrow. >> >> Dave. >> From kevin.rushforth at oracle.com Tue Apr 4 23:53:19 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 04 Apr 2017 16:53:19 -0700 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 In-Reply-To: References: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> <58E42192.5000706@Oracle.com> <58E423E3.20600@oracle.com> Message-ID: <58E431EF.6060206@oracle.com> I raised the same concern in the JBS issue, especially for mouse and keyboard events. -- Kevin Jim Graham wrote: > I don't think I was specifically involved in AWT fixes for that issue, > but the concerns that David raises are all valid and Phil correctly > points out that this is much worse in a network display environment... > > ...jim > > On 4/4/17 3:53 PM, Philip Race wrote: >> AWT used to have really bad at X11 remote display and >> it was looked at a few times and I think it was improved >> noticeably when we could get rid of "round trip" requests. >> I think Jim had a hand in some of that work. >> >> So I am sure a round trip - or similar - is bad for performance. >> >> If you want to measure the effect of such change, remote display to >> your desktop from a machine in a geographically distant site. >> >> It is the latency that kills performance, not the bandwidth. >> >> -phil. >> >> On 4/4/17, 3:43 PM, David Hill wrote: >>> On 4/4/17, 1:27 PM, Semyon Sadetsky wrote: >>>> Hello Kevin & David, >>>> >>>> Please review the fix for jfx9: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176844 >>>> >>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/ >>>> >>>> --Semyon >>>> >>> >>> Semyon, >>> >>> I have been sitting here for a while thinking about adding >>> gdk_display_sync(gdk_display_get_default()); >>> >>> I can see why this might address many issues, as it flushes the >>> pipeline and waits for the X11 server to catch up. >>> That is balanced out by a historical distrust of using XSync in any >>> situation where the consequences. >>> >>> Part of me thinks it is minimal overhead though, the other part does >>> not like stalling the asynchronous X11 design. >>> >>> The other part of me would like to use this only for the window >>> events that need it, instead of all of them. >>> >>> and I found this in hte GTK docs: >>> gdk_events_pending () >>> Waits for a GraphicsExpose or NoExpose event from the X server. This >>> is used in the GtkText and GtkCList widgets in >>> GTK+ to make sure any GraphicsExpose events are handled before the >>> widget is scrolled. >>> >>> so perhaps this should be used in some cases (like setVisible). >>> >>> sigh. >>> >>> Will try to make up my mind tomorrow. >>> >>> Dave. >>> From semyon.sadetsky at oracle.com Wed Apr 5 16:52:09 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 5 Apr 2017 09:52:09 -0700 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 In-Reply-To: <58E431EF.6060206@oracle.com> References: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> <58E42192.5000706@Oracle.com> <58E423E3.20600@oracle.com> <58E431EF.6060206@oracle.com> Message-ID: Okay. Thank you to you all! The root cause why we need to add sync is a new way to grab/ungrab focus used in the GTK3 glass implementation. The GTK2 way to grab/ungrab is still applicable in GTK3 though it is deprecated. But the used GTK3 grab/ungrab is deprecated as well since version 3.20 (Ubuntu 16.04 LTS has 3.18 assigned, but newer OS versions will come with higher number). David, do you think we could use the same GTK2 grab/ungrab for GTK3 to avoid sync? Also, I found some other potential issues in the GTK3 implementation. 1. gdk_device_manager_get_client_pointer() is used for getting pointer position and for D&D pointer grab, and the documentation to this function says: You should use this function seldomly, only in code that isn?t triggered by aGdkEvent and there aren?t other means to get a meaningfulGdkDevice to operate on. but we are using it in processing of GDK_BUTTON_PRESS, GDK_BUTTON_RELEASE and GDK_DRAG_STATUS events. 2. GList obtained by gdk_device_manager_list_devices() during grab/ungrab operations is not freed, so it causes memory leak. I will file bug for 1. and for 2. if the new GDK3 grab/ungrab will be preserved. --Semyon On 04/04/2017 04:53 PM, Kevin Rushforth wrote: > I raised the same concern in the JBS issue, especially for mouse and > keyboard events. > > -- Kevin > > > Jim Graham wrote: >> I don't think I was specifically involved in AWT fixes for that >> issue, but the concerns that David raises are all valid and Phil >> correctly points out that this is much worse in a network display >> environment... >> >> ...jim >> >> On 4/4/17 3:53 PM, Philip Race wrote: >>> AWT used to have really bad at X11 remote display and >>> it was looked at a few times and I think it was improved >>> noticeably when we could get rid of "round trip" requests. >>> I think Jim had a hand in some of that work. >>> >>> So I am sure a round trip - or similar - is bad for performance. >>> >>> If you want to measure the effect of such change, remote display to >>> your desktop from a machine in a geographically distant site. >>> >>> It is the latency that kills performance, not the bandwidth. >>> >>> -phil. >>> >>> On 4/4/17, 3:43 PM, David Hill wrote: >>>> On 4/4/17, 1:27 PM, Semyon Sadetsky wrote: >>>>> Hello Kevin & David, >>>>> >>>>> Please review the fix for jfx9: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176844 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/ >>>>> >>>>> --Semyon >>>>> >>>> >>>> Semyon, >>>> >>>> I have been sitting here for a while thinking about adding >>>> gdk_display_sync(gdk_display_get_default()); >>>> >>>> I can see why this might address many issues, as it flushes the >>>> pipeline and waits for the X11 server to catch up. >>>> That is balanced out by a historical distrust of using XSync in any >>>> situation where the consequences. >>>> >>>> Part of me thinks it is minimal overhead though, the other part >>>> does not like stalling the asynchronous X11 design. >>>> >>>> The other part of me would like to use this only for the window >>>> events that need it, instead of all of them. >>>> >>>> and I found this in hte GTK docs: >>>> gdk_events_pending () >>>> Waits for a GraphicsExpose or NoExpose event from the X server. >>>> This is used in the GtkText and GtkCList widgets in >>>> GTK+ to make sure any GraphicsExpose events are handled before the >>>> widget is scrolled. >>>> >>>> so perhaps this should be used in some cases (like setVisible). >>>> >>>> sigh. >>>> >>>> Will try to make up my mind tomorrow. >>>> >>>> Dave. >>>> From David.Hill at Oracle.com Wed Apr 5 18:23:33 2017 From: David.Hill at Oracle.com (David Hill) Date: Wed, 05 Apr 2017 14:23:33 -0400 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 In-Reply-To: References: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> <58E42192.5000706@Oracle.com> <58E423E3.20600@oracle.com> <58E431EF.6060206@oracle.com> Message-ID: <58E53625.7060406@Oracle.com> On 4/5/17, 12:52 PM, Semyon Sadetsky wrote: > Okay. Thank you to you all! > > The root cause why we need to add sync is a new way to grab/ungrab focus used in the GTK3 glass implementation. > > The GTK2 way to grab/ungrab is still applicable in GTK3 though it is deprecated. But the used GTK3 grab/ungrab is deprecated as well since version 3.20 (Ubuntu 16.04 LTS has 3.18 assigned, but newer OS versions will come with higher number). > > David, do you think we could use the same GTK2 grab/ungrab for GTK3 to avoid sync? I am OK with that. > > Also, I found some other potential issues in the GTK3 implementation. > > 1. gdk_device_manager_get_client_pointer() is used for getting pointer position and for D&D pointer grab, and the documentation to this function says: > > You should use this function seldomly, only in code that isn?t triggered by aGdkEvent and there aren?t other means to get a meaningfulGdkDevice to operate on. > > but we are using it in processing of GDK_BUTTON_PRESS, GDK_BUTTON_RELEASE and GDK_DRAG_STATUS events. > > 2. GList obtained by gdk_device_manager_list_devices() during grab/ungrab operations is not freed, so it causes memory leak. > > I will file bug for 1. and for 2. if the new GDK3 grab/ungrab will be preserved. > > --Semyon > > > On 04/04/2017 04:53 PM, Kevin Rushforth wrote: >> I raised the same concern in the JBS issue, especially for mouse and keyboard events. >> >> -- Kevin >> >> >> Jim Graham wrote: >>> I don't think I was specifically involved in AWT fixes for that issue, but the concerns that David raises are all valid and Phil correctly points out that this is much worse in a network display environment... >>> >>> ...jim >>> >>> On 4/4/17 3:53 PM, Philip Race wrote: >>>> AWT used to have really bad at X11 remote display and >>>> it was looked at a few times and I think it was improved >>>> noticeably when we could get rid of "round trip" requests. >>>> I think Jim had a hand in some of that work. >>>> >>>> So I am sure a round trip - or similar - is bad for performance. >>>> >>>> If you want to measure the effect of such change, remote display to >>>> your desktop from a machine in a geographically distant site. >>>> >>>> It is the latency that kills performance, not the bandwidth. >>>> >>>> -phil. >>>> >>>> On 4/4/17, 3:43 PM, David Hill wrote: >>>>> On 4/4/17, 1:27 PM, Semyon Sadetsky wrote: >>>>>> Hello Kevin & David, >>>>>> >>>>>> Please review the fix for jfx9: >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8176844 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/ >>>>>> >>>>>> --Semyon >>>>>> >>>>> >>>>> Semyon, >>>>> >>>>> I have been sitting here for a while thinking about adding >>>>> gdk_display_sync(gdk_display_get_default()); >>>>> >>>>> I can see why this might address many issues, as it flushes the pipeline and waits for the X11 server to catch up. >>>>> That is balanced out by a historical distrust of using XSync in any situation where the consequences. >>>>> >>>>> Part of me thinks it is minimal overhead though, the other part does not like stalling the asynchronous X11 design. >>>>> >>>>> The other part of me would like to use this only for the window events that need it, instead of all of them. >>>>> >>>>> and I found this in hte GTK docs: >>>>> gdk_events_pending () >>>>> Waits for a GraphicsExpose or NoExpose event from the X server. This is used in the GtkText and GtkCList widgets in >>>>> GTK+ to make sure any GraphicsExpose events are handled before the widget is scrolled. >>>>> >>>>> so perhaps this should be used in some cases (like setVisible). >>>>> >>>>> sigh. >>>>> >>>>> Will try to make up my mind tomorrow. >>>>> >>>>> Dave. >>>>> > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From semyon.sadetsky at oracle.com Wed Apr 5 20:26:51 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 5 Apr 2017 13:26:51 -0700 Subject: [10] Review request for 8176844: Menus not always selected properly with GTK 3 In-Reply-To: <58E53625.7060406@Oracle.com> References: <03b22237-40d2-5afd-4c49-472f35643570@oracle.com> <58E42192.5000706@Oracle.com> <58E423E3.20600@oracle.com> <58E431EF.6060206@oracle.com> <58E53625.7060406@Oracle.com> Message-ID: <28565b55-9cc9-f4d4-42bf-dce811b2403a@oracle.com> On 04/05/2017 11:23 AM, David Hill wrote: > On 4/5/17, 12:52 PM, Semyon Sadetsky wrote: >> Okay. Thank you to you all! >> >> The root cause why we need to add sync is a new way to grab/ungrab >> focus used in the GTK3 glass implementation. >> >> The GTK2 way to grab/ungrab is still applicable in GTK3 though it is >> deprecated. But the used GTK3 grab/ungrab is deprecated as well since >> version 3.20 (Ubuntu 16.04 LTS has 3.18 assigned, but newer OS >> versions will come with higher number). >> >> David, do you think we could use the same GTK2 grab/ungrab for GTK3 >> to avoid sync? > I am OK with that. > I could not make the new grab/ungrab working without sync. So, I fall-back to the GTK2 way to grab/ungrab: http://cr.openjdk.java.net/~ssadetsky/8176844/webrev.01/ --Semyon From kevin.rushforth at oracle.com Wed Apr 5 22:05:48 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 05 Apr 2017 15:05:48 -0700 Subject: [9] Review request: 8169555: Need unit tests for JDK-8169289 Message-ID: <58E56A3C.9050306@oracle.com> Dave and Dave, Please review: https://bugs.openjdk.java.net/browse/JDK-8169555 http://cr.openjdk.java.net/~kcr/8169555/webrev.00/ This adds three new unit tests for verifying that we can launch modular FX applications. -- Kevin From kevin.rushforth at oracle.com Wed Apr 5 22:51:38 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 05 Apr 2017 15:51:38 -0700 Subject: [9] Review request: 8173080: Add licenses for non-distributed third-party source code in repo Message-ID: <58E574FA.3030606@oracle.com> Dave, Please review the following fix to add missing .md license files for non-distributed third-party source code in our repo: https://bugs.openjdk.java.net/browse/JDK-8173080 http://cr.openjdk.java.net/~kcr/8173080/webrev.00/ -- Kevin From mandy.chung at oracle.com Wed Apr 5 22:53:13 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 5 Apr 2017 15:53:13 -0700 Subject: [9] Review request: 8173080: Add licenses for non-distributed third-party source code in repo In-Reply-To: <58E574FA.3030606@oracle.com> References: <58E574FA.3030606@oracle.com> Message-ID: <43236A77-C047-42B6-B031-6723C6CE7838@oracle.com> > On Apr 5, 2017, at 3:51 PM, Kevin Rushforth wrote: > > Dave, > > Please review the following fix to add missing .md license files for non-distributed third-party source code in our repo: > > https://bugs.openjdk.java.net/browse/JDK-8173080 > http://cr.openjdk.java.net/~kcr/8173080/webrev.00/ > The license files look good to me. Mandy From ajit.ghaisas at oracle.com Thu Apr 6 14:38:52 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 6 Apr 2017 07:38:52 -0700 (PDT) Subject: [10] Review request : JDK-8153509 : MenuButton label padding is not ignored for ignored labels Message-ID: Hi Jonathan, Request you to review following fix : Bug : https://bugs.openjdk.java.net/browse/JDK-8153509 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8153509/webrev.1/ Regards, Ajit From david.dehaven at oracle.com Thu Apr 6 22:12:11 2017 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 6 Apr 2017 15:12:11 -0700 Subject: [9] RfR: 8091078: [JavaDoc] Mispelling in MediaView Constructor documentation Message-ID: <3142357A-9DB1-4C94-8EC5-1C1C643B0E1E@oracle.com> Kevin, Alexander, please review this rather trivial javadoc fix for 9. JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8091078 Patch: diff --git a/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java b/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java --- a/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java +++ b/modules/javafx.media/src/main/java/javafx/scene/media/MediaView.java @@ -325,7 +325,7 @@ *

      * MediaPlayer player; // initialization omitted
      * MediaView view = new MediaView();
-     * view.setPlayer(player);
+     * view.setMediaPlayer(player);
      * 
* * @param mediaPlayer the {@link MediaPlayer} the playback of which is to be (patch is also in the JBS issue) -DrD- From kevin.rushforth at oracle.com Thu Apr 6 22:12:45 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 06 Apr 2017 15:12:45 -0700 Subject: [9] Review request: 8178281: Remove @link reference to Module class until boot JDK is updated Message-ID: <58E6BD5D.7050604@oracle.com> Phil, Please review the following fix (which is a follow-on to JDK-8177751). https://bugs.openjdk.java.net/browse/JDK-8178281 The patch is in the JBS; it changes "{@link Module#addOpens}" to {@code Module.addOpens} in one more place. -- Kevin From kevin.rushforth at oracle.com Thu Apr 6 22:42:20 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 06 Apr 2017 15:42:20 -0700 Subject: [9] Review request: 8178282: Add '@since 9' javadoc tags to JavaFX module descriptions Message-ID: <58E6C44C.5060109@oracle.com> Jonathan & Chris, Please review the following to add the missing @since tags, and simple javadoc description for jdk.packager.* https://bugs.openjdk.java.net/browse/JDK-8178282 http://cr.openjdk.java.net/~kcr/8178282/webrev.00/ Thanks. -- Kevin From kevin.rushforth at oracle.com Thu Apr 6 22:51:52 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 06 Apr 2017 15:51:52 -0700 Subject: [9] Review request: 8178132: Add @moduleGraph javadoc tag to javadoc for JavaFX modules Message-ID: <58E6C688.7070906@oracle.com> Mandy and Dave, Please review the following fix to add '@moduleGraph' tags to the javafx.* and jdk.packager* modules: https://bugs.openjdk.java.net/browse/JDK-8178132 http://cr.openjdk.java.net/~kcr/8178132/webrev.00/ I also ignore the tag when building the FX javadocs. -- Kevin From dipak.kumar at oracle.com Fri Apr 7 12:43:24 2017 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Fri, 7 Apr 2017 05:43:24 -0700 (PDT) Subject: Review Request 8088681:Underscore not visible in HTML combo box options inside webview In-Reply-To: References: Message-ID: <5052ee84-c046-4699-9c36-65321c878e2a@default> Hi Kevin, Arun, Please review the fix for : JBS: https://bugs.openjdk.java.net/browse/JDK-8088681 Webrev: http://cr.openjdk.java.net/~asrivastava/dipak/8088681/webrev.00/ I have tested the fix on Win64 and Linux 64. I have run Junit test cases and DRT. Many thanks, Dipak From dlemmermann at gmail.com Mon Apr 10 08:32:30 2017 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Mon, 10 Apr 2017 10:32:30 +0200 Subject: Canvas Content Shift Message-ID: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> HI there, I was wondering if there is any chance that Java 10 could implement some sort of ?content shifting? for the Canvas API? I would love to have this feature for supporting faster horizontal scrolling in my Gantt Chart framework FlexGanttFX. Currently when the user scrolls then the entire content of each canvas in each row of the chart will be redrawn. This could be optimized by only drawing the time range that has been moved into the ?viewport? and by shifting or copying the remaining time range graphics. E.g. the user currently looks at one week and scrolls one day to the right then the data / graphics of 6 days would stay the same and could just be reused. Only one day worth of data would need to be redrawn. I think in Swing this is comparable with the BLIT_SCROLL_MODE of JViewport. Dirk From mp at jugs.org Mon Apr 10 09:20:45 2017 From: mp at jugs.org (Michael Paus) Date: Mon, 10 Apr 2017 11:20:45 +0200 Subject: Canvas Content Shift In-Reply-To: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> References: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> Message-ID: <00a4dd59-b923-a4df-ec4b-3f9fd90125de@jugs.org> I also have that on my wishlist. Actually I would like to see that in some update release for Java 8/9 too because Java 10 is still very far away at the horizon. Michael Am 10.04.17 um 10:32 schrieb Dirk Lemmermann: > HI there, > > I was wondering if there is any chance that Java 10 could implement some sort of ?content shifting? for the Canvas API? > > I would love to have this feature for supporting faster horizontal scrolling in my Gantt Chart framework FlexGanttFX. Currently when the user scrolls then the entire content of each canvas in each row of the chart will be redrawn. This could be optimized by only drawing the time range that has been moved into the ?viewport? and by shifting or copying the remaining time range graphics. E.g. the user currently looks at one week and scrolls one day to the right then the data / graphics of 6 days would stay the same and could just be reused. Only one day worth of data would need to be redrawn. > > I think in Swing this is comparable with the BLIT_SCROLL_MODE of JViewport. > > Dirk > From dlemmermann at gmail.com Mon Apr 10 09:21:55 2017 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Mon, 10 Apr 2017 11:21:55 +0200 Subject: Canvas Content Shift In-Reply-To: <00a4dd59-b923-a4df-ec4b-3f9fd90125de@jugs.org> References: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> <00a4dd59-b923-a4df-ec4b-3f9fd90125de@jugs.org> Message-ID: +1 on Java 8/9 update. But I have a feeling that will be hard to accomplish. > Am 10.04.2017 um 11:20 schrieb Michael Paus : > > I also have that on my wishlist. Actually I would like to see that in some update release for Java 8/9 too > because Java 10 is still very far away at the horizon. > Michael > > Am 10.04.17 um 10:32 schrieb Dirk Lemmermann: >> HI there, >> >> I was wondering if there is any chance that Java 10 could implement some sort of ?content shifting? for the Canvas API? >> >> I would love to have this feature for supporting faster horizontal scrolling in my Gantt Chart framework FlexGanttFX. Currently when the user scrolls then the entire content of each canvas in each row of the chart will be redrawn. This could be optimized by only drawing the time range that has been moved into the ?viewport? and by shifting or copying the remaining time range graphics. E.g. the user currently looks at one week and scrolls one day to the right then the data / graphics of 6 days would stay the same and could just be reused. Only one day worth of data would need to be redrawn. >> >> I think in Swing this is comparable with the BLIT_SCROLL_MODE of JViewport. >> >> Dirk >> > From ambarish.rapte at oracle.com Mon Apr 10 12:53:31 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 10 Apr 2017 05:53:31 -0700 (PDT) Subject: Review request: JDK-8145887: ListView selectionModel selectedIndices ListIterator nextIndex broken Message-ID: Hi Jonathan, Ajit Please review this fix: Webrev : http://cr.openjdk.java.net/~arapte/fx/8145887/webrev.00/ Bug : https://bugs.openjdk.java.net/browse/JDK-8145887 Issue: The private class SelectionListIterator implements the interface java.util.ListIterator. But the class SelectionListIterator does not follow specifications of java.util.ListIterator. Fix: Updated the required SelectionListIteratorclas class APIs as per the specification of interface java.util.ListIterator. https://docs.oracle.com/javase/8/docs/api/java/util/ListIterator.html Verification: Verified that no controls test fails due to this change. Regards, Ambarish From kevin.rushforth at oracle.com Mon Apr 10 14:54:15 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Apr 2017 07:54:15 -0700 Subject: Canvas Content Shift In-Reply-To: References: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> <00a4dd59-b923-a4df-ec4b-3f9fd90125de@jugs.org> Message-ID: <58EB9C97.8070900@oracle.com> Please file an Enhancement request and we can consider this for JDK 10. Dirk Lemmermann wrote: > +1 on Java 8/9 update. But I have a feeling that will be hard to accomplish. > Indeed it will be. We have a general policy against further enhancements for JDK 8uNN. I suspect the same is likely for JDK 9.x, but I can't say that for sure until there is a JDK 9 updates project. -- Kevin > >> Am 10.04.2017 um 11:20 schrieb Michael Paus : >> >> I also have that on my wishlist. Actually I would like to see that in some update release for Java 8/9 too >> because Java 10 is still very far away at the horizon. >> Michael >> >> Am 10.04.17 um 10:32 schrieb Dirk Lemmermann: >> >>> HI there, >>> >>> I was wondering if there is any chance that Java 10 could implement some sort of ?content shifting? for the Canvas API? >>> >>> I would love to have this feature for supporting faster horizontal scrolling in my Gantt Chart framework FlexGanttFX. Currently when the user scrolls then the entire content of each canvas in each row of the chart will be redrawn. This could be optimized by only drawing the time range that has been moved into the ?viewport? and by shifting or copying the remaining time range graphics. E.g. the user currently looks at one week and scrolls one day to the right then the data / graphics of 6 days would stay the same and could just be reused. Only one day worth of data would need to be redrawn. >>> >>> I think in Swing this is comparable with the BLIT_SCROLL_MODE of JViewport. >>> >>> Dirk >>> >>> > > From dlemmermann at gmail.com Mon Apr 10 16:04:43 2017 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Mon, 10 Apr 2017 18:04:43 +0200 Subject: Canvas Content Shift In-Reply-To: <58EB9C97.8070900@oracle.com> References: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> <00a4dd59-b923-a4df-ec4b-3f9fd90125de@jugs.org> <58EB9C97.8070900@oracle.com> Message-ID: <71672B19-EBD6-4620-9BC2-5C65E137501C@gmail.com> I have submitted the RFE. ? Dirk > Am 10.04.2017 um 16:54 schrieb Kevin Rushforth : > > Please file an Enhancement request and we can consider this for JDK 10. > > Dirk Lemmermann wrote: >> >> +1 on Java 8/9 update. But I have a feeling that will be hard to accomplish. >> > > Indeed it will be. We have a general policy against further enhancements for JDK 8uNN. I suspect the same is likely for JDK 9.x, but I can't say that for sure until there is a JDK 9 updates project. > > -- Kevin > >> >>> Am 10.04.2017 um 11:20 schrieb Michael Paus : >>> >>> I also have that on my wishlist. Actually I would like to see that in some update release for Java 8/9 too >>> because Java 10 is still very far away at the horizon. >>> Michael >>> >>> Am 10.04.17 um 10:32 schrieb Dirk Lemmermann: >>> >>>> HI there, >>>> >>>> I was wondering if there is any chance that Java 10 could implement some sort of ?content shifting? for the Canvas API? >>>> >>>> I would love to have this feature for supporting faster horizontal scrolling in my Gantt Chart framework FlexGanttFX. Currently when the user scrolls then the entire content of each canvas in each row of the chart will be redrawn. This could be optimized by only drawing the time range that has been moved into the ?viewport? and by shifting or copying the remaining time range graphics. E.g. the user currently looks at one week and scrolls one day to the right then the data / graphics of 6 days would stay the same and could just be reused. Only one day worth of data would need to be redrawn. >>>> >>>> I think in Swing this is comparable with the BLIT_SCROLL_MODE of JViewport. >>>> >>>> Dirk >>>> >>>> >> >> From mp at jugs.org Mon Apr 10 16:59:50 2017 From: mp at jugs.org (Michael Paus) Date: Mon, 10 Apr 2017 18:59:50 +0200 Subject: JavaFX graphics performance Message-ID: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> Hi, more and more people ask me why I am still doing GUI development in JavaFX instead of following the mainstream and use some web technology. One of the arguments I could use in the past was performance but nowadays this does not seem to be such a valid argument anymore. Web technologies are catching up quickly and JavaFX currently has not much to offer here. Actually the general drawing performance is very bad compared to what is in principle possible with a modern GPU. I even tried to use a TriangleMesh to better exploit the graphics hardware but this approach is also limited by the fact that a TrinangleMesh has an excessive memory usage (about 60 times its nominal memory consumption). I would therefore like to ask whether there are already any plans for Java 10 to improve this situation? Michael From ambarish.rapte at oracle.com Mon Apr 10 17:00:34 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 10 Apr 2017 10:00:34 -0700 (PDT) Subject: Review Request: JDK-8175963: ChoiceBox using events from ComboBox Message-ID: Hi Jonathan, Ajit, Please review this fix, Bug : https://bugs.openjdk.java.net/browse/JDK-8175963 Webrev: http://cr.openjdk.java.net/~arapte/fx/8175963/webrev.03/ Issue: EventType from class ComboBoxBase were used with ChoiceBox class in method ChoiceBox.setShowing(). Fix: Corrected the EventType in ChoiceBox.setShowing() & added a test. Similar changes are done for MenuButton Verification: Verified the :controls:test. This change does not cause any failure. Regards, Ambarish From james.graham at oracle.com Mon Apr 10 18:17:06 2017 From: james.graham at oracle.com (Jim Graham) Date: Mon, 10 Apr 2017 11:17:06 -0700 Subject: Canvas Content Shift In-Reply-To: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> References: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> Message-ID: <004e439f-a6f8-1047-c50c-bfe5549dadf3@oracle.com> Any suggestions on how to implement this when the size of pixels may be an arbitrary non-integer number? Consider rendering on a 125% scaled Windows 10 screen. If you want to scroll by 2 pixels you would want to scroll by 1.6 coordinate units. If you want to scroll by 2 coordinate units you are out of luck because that would attempt to "scroll by 2.5 pixels" and there is no good definition of that type of operation. We could add a pixel size parameter (note that it might be different than the window or screen render scale because the Canvas cannot re-render and so it chooses the scale of the deepest screen). Then it would be up to the developer to take this into account when determining how far to scroll, but that is a bit more complicated than what developers tend to be used to when they deal with scrolling. Note that the scrolling of JViewport is handled by our own code, not developer code, so we can take these adjustments into account ourselves internally and know if/when we can blit or if/when we need to re-render... ...jim On 4/10/17 1:32 AM, Dirk Lemmermann wrote: > HI there, > > I was wondering if there is any chance that Java 10 could implement some sort of ?content shifting? for the Canvas API? > > I would love to have this feature for supporting faster horizontal scrolling in my Gantt Chart framework FlexGanttFX. Currently when the user scrolls then the entire content of each canvas in each row of the chart will be redrawn. This could be optimized by only drawing the time range that has been moved into the ?viewport? and by shifting or copying the remaining time range graphics. E.g. the user currently looks at one week and scrolls one day to the right then the data / graphics of 6 days would stay the same and could just be reused. Only one day worth of data would need to be redrawn. > > I think in Swing this is comparable with the BLIT_SCROLL_MODE of JViewport. > > Dirk > From kevin.rushforth at oracle.com Mon Apr 10 20:08:04 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 10 Apr 2017 13:08:04 -0700 Subject: JavaFX graphics performance In-Reply-To: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> References: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> Message-ID: <58EBE624.9050009@oracle.com> We are planning some performance improvements in JDK 10, mostly in the areas of CSS and layout. If you have specific concerns in other areas we could look into them. Having a specific test case that shows a performance problem would be a good start. -- Kevin Michael Paus wrote: > Hi, > > more and more people ask me why I am still doing GUI development in > JavaFX instead > of following the mainstream and use some web technology. One of the > arguments > I could use in the past was performance but nowadays this does not > seem to be such > a valid argument anymore. Web technologies are catching up quickly and > JavaFX currently > has not much to offer here. Actually the general drawing performance > is very bad compared > to what is in principle possible with a modern GPU. I even tried to > use a TriangleMesh > to better exploit the graphics hardware but this approach is also > limited by the fact that > a TrinangleMesh has an excessive memory usage (about 60 times its > nominal memory > consumption). I would therefore like to ask whether there are already > any plans for Java 10 > to improve this situation? > > Michael From ambarish.rapte at oracle.com Tue Apr 11 10:34:40 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 11 Apr 2017 03:34:40 -0700 (PDT) Subject: Review Request: 8090192 : [TextArea] Previous char wrong at line start Message-ID: Hi Jonathan, Ajit, Please review this bug fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8090192 Webrev: http://cr.openjdk.java.net/~arapte/fx/8090192/webrev.00/ Regards, Ambarish From ambarish.rapte at oracle.com Tue Apr 11 10:50:00 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Tue, 11 Apr 2017 03:50:00 -0700 (PDT) Subject: Review Request: 8178417 : TextArea/TextField: Undo operation reverts the caret position. Message-ID: <7a7ce226-b586-4081-92f3-88789a8d987d@default> Hi Jonathan, Ajit, Please review a small fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8178417 Webrev: http://cr.openjdk.java.net/~arapte/fx/8178417/webrev.00/ Regards, Ambarish From mattias.eliasson at medsa.se Tue Apr 11 12:49:10 2017 From: mattias.eliasson at medsa.se (Mattias Eliasson) Date: Tue, 11 Apr 2017 14:49:10 +0200 Subject: JavaFX graphics performance In-Reply-To: <58EBE624.9050009@oracle.com> References: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> <58EBE624.9050009@oracle.com> Message-ID: <7586218B-C8F0-45CB-BF96-5BFD37CF6402@medsa.se> Excessive memory usage is more of a well documented JDK problem that impacts the performance of many applications. Especially when having a large collection of instances of the same class. In C++ an array of objects are in memory similar to an array of structs. In Java they are arrays of pointers to objects on the heap. This could of course be worked around by storing data in arrays and using classes to wrap those arrays. In one project I stored X and Y coordinates in an array. I had a class with getter and setters but also with a reference to the array and index. On top of that I had what worked similarly to a standard object pool but in fact only had a few instances of the object, changing index of a free object rather than allocating a new. For simplicity I used an array for X and another for Y. This pattern can be refined to align data in various ways for better cache performance. And in our case there may be alignments that gives better GPU performance. After all it's usually the GPU that process our data. Of course it would be best if the JVM had better memory management including something similar to a struct array without pointers to objects. But there would still be need to have refinements. For example is it better to have XXXYYY, XYXYXY, or perhaps YXYXYX? That in turn depends on cache infrastructure, the order data is accessed and other factors. In order notes the main competition to JavaFX is other Java APIs such as Swing and it's Java2D. When it comes to performance we obviously have a clear winner. But JavaFX isn't shipped within major Linux distributions so it is yet considered experimental by many that use Swing. There are also competition from SWT used by Eclipse and Azureus/Vuze. Packaging is one problem but there are also UI components missing. The SWT on JavaFX implementation has a list of SWT components and their JavaFX counterpart. That list illustrates that there are a lot of work to do. Of course once SWT on JavaFX is complete SWT will be eliminated as competition. Especially if Eclipse use JavaFX as its SWT backend. It would also mean that JavaFX is better equipped to compete with Swing as SWT already is a strong competitor to Swing. However SWT has been held back due to stability problems which probably will not be in the way when it's based on JavaFX which is good enterprise code. As for competing with web technologies it would have helped if we had a modern browser plugin. JavaFX as an UI may not be faster than browser technologies. But Java bytecode is a lot faster than JavaScript. Take RPC for example. If you use browser technology you would probably be using Json at best. With Java you have binary protocols like Jboss Remoting which ia easy to code and much faster than using Json in JavaScript. Web technologies can only compete where there is an API implemented in something other than JavaScript. Once processing is done in JavaScript the it becomes a lot slower than Java. I would suggest creating a new fully sandboxed applet technology based on JavaFX instead of AWT/Swing. That of course would be incompatible with classic Applets but those are dead anyway. Make it at least as good as Flash perhaps with an IDE like the commercial flash IDE. I mean activescript vs Hotspot will not be a very fair match. Another competitor is Unity and similar game engines. As unity is based on mono and MonoDevelop we could do something similar using Java and eclipse. When it comes to web/client server Vaadin has been gaining a lot of ground. It's model of having a combined client and server code base using byte buddy or ASM to separate client and server into separate executables is impressive. I would like more control such as specifying @client or @server in order to control where execution take place. But more to the point I would like a JavaFX UI. While web technologies are moving in on Java they do have a far way to go before they have what java has. We have Hotspot for starters and that's way ahead of JavaScript and Flash. What we don't have is browser integration. Let's take the lessons learned from both Flash and Java Applets and make something awesome. That doesn't carry "java" in the name. Like OpenFX? Or "Arrow" (yeah I'm a nerd). This including the creative tools that Flash has but perhaps also with features that Unity has. Kevin Rushforth skrev: (10 april 2017 22:08:04 CEST) >We are planning some performance improvements in JDK 10, mostly in the >areas of CSS and layout. If you have specific concerns in other areas >we >could look into them. Having a specific test case that shows a >performance problem would be a good start. > >-- Kevin > > >Michael Paus wrote: >> Hi, >> >> more and more people ask me why I am still doing GUI development in >> JavaFX instead >> of following the mainstream and use some web technology. One of the >> arguments >> I could use in the past was performance but nowadays this does not >> seem to be such >> a valid argument anymore. Web technologies are catching up quickly >and >> JavaFX currently >> has not much to offer here. Actually the general drawing performance >> is very bad compared >> to what is in principle possible with a modern GPU. I even tried to >> use a TriangleMesh >> to better exploit the graphics hardware but this approach is also >> limited by the fact that >> a TrinangleMesh has an excessive memory usage (about 60 times its >> nominal memory >> consumption). I would therefore like to ask whether there are already > >> any plans for Java 10 >> to improve this situation? >> >> Michael -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From nikos132 at gmail.com Tue Apr 11 13:26:52 2017 From: nikos132 at gmail.com (Nikos Nikolos) Date: Tue, 11 Apr 2017 15:26:52 +0200 Subject: JavaFX graphics performance Message-ID: Here is a copy of a previous post I sent, needs are still the same on my side and I don't see anything coming from the JavaFX side... OpenGL rendering was a nice solution for performance intensive application on the desktop. Since JavaFX doesn't offer a native OpenGL handle you can use such a solution. CSS and layout improvement are quite out of scope for the inital needs I think. Electron is becoming trendy maybe with some WebGL inside it you will be able to outperform JavaFX rendering speed! I really enjoyed desktop GUI development in Java but them came JavaFX... Following the thread http://mail.openjdk.java.net/ pipermail/openjfx-dev/2016-December/020025.html I would like to ask for more information on JavaFX plan to allow a simple way to use existing OpenGL code. I know this is not a new question and please forgive me if I?ve overlooked some answers already posted. I work in the niche area where desktop applications are still needed and use Swing since 2001, integrated Jogl and then Jogamp since 2006 and that try to figure out how we can use JavaFX without a huge performance drop. I think this bug https://bugs.openjdk.java.net/browse/JDK-8091324 is the best summary of potential needs. And the answer gave by Kevin Rushforth was quite disappointing. I remember Swing teams members (Kenneth Bradley Russell) working hard to have a nice way to use OpenGL in a platform independent manner which is one of the strength of Java. JOGAMP team also made a good work more recently. Some tricks have been used to try to provide a solution: ? https://github.com/SkyLandTW/JOGL-FX#jogl-on-javafx-es2 ? https://github.com/pepe1914/jfx-zoglpipeline ? https://www.youtube.com/watch?v=aYRF34UYu-E But they are very fragile (use of internal classes, rebundling JavaFx jars?). Is this need too specific for a change to have it implemented in JavaFX? Going on with Swing is a potential solution but it won?t resist a comparison with QT long. Thanks for any of your ideas on that. Regards ---------- Message transf?r? ---------- From: Mattias Eliasson To: openjfx-dev at openjdk.java.net Cc: Bcc: Date: Tue, 11 Apr 2017 14:49:10 +0200 Subject: Re: JavaFX graphics performance Excessive memory usage is more of a well documented JDK problem that impacts the performance of many applications. Especially when having a large collection of instances of the same class. In C++ an array of objects are in memory similar to an array of structs. In Java they are arrays of pointers to objects on the heap. This could of course be worked around by storing data in arrays and using classes to wrap those arrays. In one project I stored X and Y coordinates in an array. I had a class with getter and setters but also with a reference to the array and index. On top of that I had what worked similarly to a standard object pool but in fact only had a few instances of the object, changing index of a free object rather than allocating a new. For simplicity I used an array for X and another for Y. This pattern can be refined to align data in various ways for better cache performance. And in our case there may be alignments that gives better GPU performance. After all it's usually the GPU that process our data. Of course it would be best if the JVM had better memory management including something similar to a struct array without pointers to objects. But there would still be need to have refinements. For example is it better to have XXXYYY, XYXYXY, or perhaps YXYXYX? That in turn depends on cache infrastructure, the order data is accessed and other factors. In order notes the main competition to JavaFX is other Java APIs such as Swing and it's Java2D. When it comes to performance we obviously have a clear winner. But JavaFX isn't shipped within major Linux distributions so it is yet considered experimental by many that use Swing. There are also competition from SWT used by Eclipse and Azureus/Vuze. Packaging is one problem but there are also UI components missing. The SWT on JavaFX implementation has a list of SWT components and their JavaFX counterpart. That list illustrates that there are a lot of work to do. Of course once SWT on JavaFX is complete SWT will be eliminated as competition. Especially if Eclipse use JavaFX as its SWT backend. It would also mean that JavaFX is better equipped to compete with Swing as SWT already is a strong competitor to Swing. However SWT has been held back due to stability problems which probably will not be in the way when it's based on JavaFX which is good enterprise code. As for competing with web technologies it would have helped if we had a modern browser plugin. JavaFX as an UI may not be faster than browser technologies. But Java bytecode is a lot faster than JavaScript. Take RPC for example. If you use browser technology you would probably be using Json at best. With Java you have binary protocols like Jboss Remoting which ia easy to code and much faster than using Json in JavaScript. Web technologies can only compete where there is an API implemented in something other than JavaScript. Once processing is done in JavaScript the it becomes a lot slower than Java. I would suggest creating a new fully sandboxed applet technology based on JavaFX instead of AWT/Swing. That of course would be incompatible with classic Applets but those are dead anyway. Make it at least as good as Flash perhaps with an IDE like the commercial flash IDE. I mean activescript vs Hotspot will not be a very fair match. Another competitor is Unity and similar game engines. As unity is based on mono and MonoDevelop we could do something similar using Java and eclipse. When it comes to web/client server Vaadin has been gaining a lot of ground. It's model of having a combined client and server code base using byte buddy or ASM to separate client and server into separate executables is impressive. I would like more control such as specifying @client or @server in order to control where execution take place. But more to the point I would like a JavaFX UI. While web technologies are moving in on Java they do have a far way to go before they have what java has. We have Hotspot for starters and that's way ahead of JavaScript and Flash. What we don't have is browser integration. Let's take the lessons learned from both Flash and Java Applets and make something awesome. That doesn't carry "java" in the name. Like OpenFX? Or "Arrow" (yeah I'm a nerd). This including the creative tools that Flash has but perhaps also with features that Unity has. Kevin Rushforth skrev: (10 april 2017 22:08:04 CEST) >We are planning some performance improvements in JDK 10, mostly in the >areas of CSS and layout. If you have specific concerns in other areas >we >could look into them. Having a specific test case that shows a >performance problem would be a good start. > >-- Kevin > > >Michael Paus wrote: >> Hi, >> >> more and more people ask me why I am still doing GUI development in >> JavaFX instead >> of following the mainstream and use some web technology. One of the >> arguments >> I could use in the past was performance but nowadays this does not >> seem to be such >> a valid argument anymore. Web technologies are catching up quickly >and >> JavaFX currently >> has not much to offer here. Actually the general drawing performance >> is very bad compared >> to what is in principle possible with a modern GPU. I even tried to >> use a TriangleMesh >> to better exploit the graphics hardware but this approach is also >> limited by the fact that >> a TrinangleMesh has an excessive memory usage (about 60 times its >> nominal memory >> consumption). I would therefore like to ask whether there are already > >> any plans for Java 10 >> to improve this situation? >> >> Michael From chris.bensen at oracle.com Tue Apr 11 15:29:38 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 11 Apr 2017 08:29:38 -0700 Subject: [9] Review request: 8178413 Mark All Exported Java Packager APIs as Deprecated Message-ID: <874FD621-0FCB-4A1B-B3D5-AF79CF8C2E20@oracle.com> Kevin, Victor, and Mandy, Please review this change to deprecate all the existing non documented Java Packager API for JDK 9 and provide a new API for JDK 10. JIRA: https://bugs.openjdk.java.net/browse/JDK-8178413 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8178413/webrev.02/ Chris From chris.bensen at oracle.com Tue Apr 11 17:00:37 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 11 Apr 2017 10:00:37 -0700 Subject: [10] Review request: 8176825 Unwanted comment in jdk.packager.services/src/main/java/module-info.java Message-ID: <5ADF4C99-01AB-4F8A-9D7D-D70F84CE9158@oracle.com> Victor, Please review this minor change to remove and unwanted comment. JIRA: https://bugs.openjdk.java.net/browse/JDK-8176825 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8176825/webrev.00/ Chris From li.jiang at oracle.com Wed Apr 12 10:28:27 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Wed, 12 Apr 2017 18:28:27 +0800 Subject: Last message drop for JavaFX on April 27th Message-ID: <276a9dd5-8cb8-2466-a85d-4a0bdf746d62@oracle.com> Hi, Syncing with JDK9 schedule, we will run the last message drop for JDK9 and JavaFX on April 27th. If you have any l10n related commit, pls submit before this deadline. Thanks, Leo From arunprasad.rajkumar at oracle.com Wed Apr 12 11:11:35 2017 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 12 Apr 2017 16:41:35 +0530 Subject: [webkit] [10] 8178319: Build sqlite3 from source Message-ID: <09257A98-0DAE-4F34-A447-5B75D551BE86@oracle.com> Hello Kevin, Please review the fix for JDK-8178319 . http://cr.openjdk.java.net/~arajkumar/8178319/webrev Thanks, Arun From victor.drozdov at oracle.com Wed Apr 12 16:28:54 2017 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Wed, 12 Apr 2017 19:28:54 +0300 Subject: [10] Review request: JDK-8175574: Singleton App Message-ID: <5e2cd7d3-b049-d047-e84d-75e384e38a41@oracle.com> Chris, Please review the changes about single instance. JIRA: https://bugs.openjdk.java.net/browse/JDK-8175574 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8175574/webrev.04/ --Victor From chien.yang at oracle.com Wed Apr 12 20:19:18 2017 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 12 Apr 2017 13:19:18 -0700 Subject: JavaFX graphics performance In-Reply-To: <58EBE624.9050009@oracle.com> References: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> <58EBE624.9050009@oracle.com> Message-ID: <41fe263a-3d1d-7967-f3f3-36443b4b9b7e@oracle.com> BTW, it is a bug that we are unaware of if you are seeing a 60X nominal memory consumption in your program. Please file a JIRA with a test program and we will investigate it. Thanks, - Chien On 4/10/2017 1:08 PM, Kevin Rushforth wrote: > We are planning some performance improvements in JDK 10, mostly in the > areas of CSS and layout. If you have specific concerns in other areas > we could look into them. Having a specific test case that shows a > performance problem would be a good start. > > -- Kevin > > > Michael Paus wrote: >> Hi, >> >> more and more people ask me why I am still doing GUI development in >> JavaFX instead >> of following the mainstream and use some web technology. One of the >> arguments >> I could use in the past was performance but nowadays this does not >> seem to be such >> a valid argument anymore. Web technologies are catching up quickly >> and JavaFX currently >> has not much to offer here. Actually the general drawing performance >> is very bad compared >> to what is in principle possible with a modern GPU. I even tried to >> use a TriangleMesh >> to better exploit the graphics hardware but this approach is also >> limited by the fact that >> a TrinangleMesh has an excessive memory usage (about 60 times its >> nominal memory >> consumption). I would therefore like to ask whether there are already >> any plans for Java 10 >> to improve this situation? >> >> Michael From jmartine_1026 at yahoo.com Thu Apr 13 02:25:00 2017 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Thu, 13 Apr 2017 02:25:00 +0000 (UTC) Subject: PathTransition jitter In-Reply-To: <820496043.177903.1491969328161@mail.yahoo.com> References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> Message-ID: <1125214297.998674.1492050300949@mail.yahoo.com> Many moons ago I complained about jittery PathTransition animation.? A bug was?openned and I was provided a workaround.? This was with Java 7.? I revisted the old project that lead to that initial complain, this time with Java 8.? The problem seems to be back.? I could not find the old bug report, since I think the JavaFX team is not using the same bug tracking site. Below is the test code to reproduce.? I tried it using JDK 8_64?u5, u11, u25, u112, u121 and the problem occurs with all of them.? The ImageView stutters through the PathTransition.? I have a new laptop with 6th gen I7 and plenty of ram.? I do not think it is the hardware.? This used to be smooth like butter.? Anyone else experiencing this or can make any suggestions? ??? @Override ??? public void start(Stage primaryStage) {??????? String rocketImgStr = "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAgakyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pmletPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; ??????? Base64.Decoder decoder = Base64.getDecoder(); ??????? ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr));??????? ImageView iv = new ImageView(new Image(rocketInputStream)); ??????? Path path = new Path(); ??????? path.getElements().add(new MoveTo(100, 100)); ??????? path.getElements().add(new LineTo(500, 100)); ??????? path.getElements().add(new LineTo(500, 500)); ??????? path.getElements().add(new LineTo(100, 500)); ??????? path.getElements().add(new LineTo(100, 100));??????? PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); ??????? pathTransition.setCycleCount(Animation.INDEFINITE); ??????? pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); ??????? pathTransition.playFromStart();??????? Group root = new Group(); ??????? root.getChildren().add(iv); ??????? Scene scene = new Scene(root, 600, 600); ??????? primaryStage.setTitle("Hello World!"); ??????? primaryStage.setScene(scene); ??????? primaryStage.show(); ??? }? thanks, jose From mp at jugs.org Thu Apr 13 06:46:26 2017 From: mp at jugs.org (Michael Paus) Date: Thu, 13 Apr 2017 08:46:26 +0200 Subject: PathTransition jitter In-Reply-To: <1125214297.998674.1492050300949@mail.yahoo.com> References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> Message-ID: <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea. Am 13.04.17 um 04:25 schrieb Jose Martinez: > > > Many moons ago I complained about jittery PathTransition animation. A bug was openned and I was provided a workaround. This was with Java 7. I revisted the old project that lead to that initial complain, this time with Java 8. The problem seems to be back. I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite. > Below is the test code to reproduce. I tried it using JDK 8_64 u5, u11, u25, u112, u121 and the problem occurs with all of them. The ImageViewstutters through the PathTransition. I have a new laptop with 6th gen I7 and plenty of ram. I do not think it is the hardware. This used to besmooth like butter. Anyone else experiencing this or can make any suggestions? > > @Override > public void start(Stage primaryStage) { String rocketImgStr= "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAgakyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pmletPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; > Base64.Decoder decoder = Base64.getDecoder(); > ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new ImageView(new Image(rocketInputStream)); > Path path = new Path(); > path.getElements().add(new MoveTo(100, 100)); > path.getElements().add(new LineTo(500, 100)); > path.getElements().add(new LineTo(500, 500)); > path.getElements().add(new LineTo(100, 500)); > path.getElements().add(new LineTo(100, 100)); PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); > pathTransition.setCycleCount(Animation.INDEFINITE); > pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); > pathTransition.playFromStart(); Group root = new Group(); > root.getChildren().add(iv); > Scene scene = new Scene(root, 600, 600); > primaryStage.setTitle("Hello World!"); > primaryStage.setScene(scene); > primaryStage.show(); > } > > thanks, > jose > > From tbee at tbee.org Thu Apr 13 07:14:17 2017 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 13 Apr 2017 09:14:17 +0200 Subject: PathTransition jitter In-Reply-To: <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> Message-ID: I'm seeing some very small irregularities; short hesitations and then small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) Slowing the animation to 8 instead of 4 seconds, make these hiccups better visible. They're most definitely there. On 13-4-2017 08:46, Michael Paus wrote: > It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea. > > Am 13.04.17 um 04:25 schrieb Jose Martinez: >> >> >> Many moons ago I complained about jittery PathTransition animation. A bug was openned and I was provided a workaround. This was with Java 7. I revisted the old project that lead to that initial complain, this time with Java 8. The problem seems to be back. I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite. >> Below is the test code to reproduce. I tried it using JDK 8_64 u5, u11, u25, u112, u121 and the problem occurs with all of them. The ImageViewstutters through the PathTransition. I have a new laptop with 6th gen I7 and plenty of ram. I do not think it is the hardware. This used to besmooth like butter. Anyone else experiencing this or can make any suggestions? >> >> @Override >> public void start(Stage primaryStage) { String rocketImgStr= >> "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAgakyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pmletPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; >> Base64.Decoder decoder = Base64.getDecoder(); >> ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new ImageView(new Image(rocketInputStream)); >> Path path = new Path(); >> path.getElements().add(new MoveTo(100, 100)); >> path.getElements().add(new LineTo(500, 100)); >> path.getElements().add(new LineTo(500, 500)); >> path.getElements().add(new LineTo(100, 500)); >> path.getElements().add(new LineTo(100, 100)); PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); >> pathTransition.setCycleCount(Animation.INDEFINITE); >> pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); >> pathTransition.playFromStart(); Group root = new Group(); >> root.getChildren().add(iv); >> Scene scene = new Scene(root, 600, 600); >> primaryStage.setTitle("Hello World!"); >> primaryStage.setScene(scene); >> primaryStage.show(); >> } >> >> thanks, >> jose >> > > > From jmartine_1026 at yahoo.com Thu Apr 13 09:03:58 2017 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Thu, 13 Apr 2017 09:03:58 +0000 (UTC) Subject: PathTransition jitter In-Reply-To: References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> Message-ID: <1698099078.1092426.1492074238757@mail.yahoo.com> In case it helps, below is the original workaround that was provided.? This?workaround no longer has any affect. public class FixedPane extends Group {??? @Override ??? public BaseBounds impl_computeGeomBounds(BaseBounds bounds, BaseTransform tx) { ???????? if (!tx.isTranslateOrIdentity()) { ???????????? super.impl_computeGeomBounds(bounds, BaseTransform.IDENTITY_TRANSFORM); ???????? } ???????? return super.impl_computeGeomBounds(bounds, tx); ??? } } Forgot to include:? using a Windows 10 and Geforce gtx GPU. From: Tom Eugelink To: openjfx-dev at openjdk.java.net Sent: Thursday, April 13, 2017 3:15 AM Subject: Re: PathTransition jitter I'm seeing some very small irregularities; short hesitations and then small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) Slowing the animation to 8 instead of 4 seconds, make these hiccups better visible. They're most definitely there. On 13-4-2017 08:46, Michael Paus wrote: > It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea. > > Am 13.04.17 um 04:25 schrieb Jose Martinez: >> >> >> Many moons ago I complained about jittery PathTransition animation.? A bug was openned and I was provided a workaround. This was with Java 7.? I revisted the old project that lead to that initial complain, this time with Java 8.? The problem seems to be back.? I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite. >> Below is the test code to reproduce.? I tried it using JDK 8_64 u5, u11, u25, u112, u121 and the problem occurs with all of them.? The ImageViewstutters through the PathTransition.? I have a new laptop with 6th gen I7 and plenty of ram.? I do not think it is the hardware.? This used to besmooth like butter.? Anyone else experiencing this or can make any suggestions? >> >>? ? ? @Override >>? ? ? public void start(Stage primaryStage) {? ? ? ? String rocketImgStr= >> "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAgakyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pmletPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; >>? ? ? ? ? Base64.Decoder decoder = Base64.getDecoder(); >>? ? ? ? ? ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new ImageView(new Image(rocketInputStream)); >>? ? ? ? ? Path path = new Path(); >>? ? ? ? ? path.getElements().add(new MoveTo(100, 100)); >>? ? ? ? ? path.getElements().add(new LineTo(500, 100)); >>? ? ? ? ? path.getElements().add(new LineTo(500, 500)); >>? ? ? ? ? path.getElements().add(new LineTo(100, 500)); >>? ? ? ? ? path.getElements().add(new LineTo(100, 100)); PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); >>? ? ? ? ? pathTransition.setCycleCount(Animation.INDEFINITE); >> pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); >>? ? ? ? ? pathTransition.playFromStart();? ? ? ? Group root = new Group(); >>? ? ? ? ? root.getChildren().add(iv); >>? ? ? ? ? Scene scene = new Scene(root, 600, 600); >>? ? ? ? ? primaryStage.setTitle("Hello World!"); >>? ? ? ? ? primaryStage.setScene(scene); >>? ? ? ? ? primaryStage.show(); >>? ? ? } >> >> thanks, >> jose >> > > > From kevin.rushforth at oracle.com Thu Apr 13 11:42:13 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Apr 2017 04:42:13 -0700 Subject: PathTransition jitter In-Reply-To: References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> Message-ID: <58EF6415.9070306@oracle.com> This is what I see when running the program, too on Windows 7 with a 32-bit JVM. I see some occasional, brief pauses that are more noticeable if you slow down the animation. Jose: you can file a bug at http://bugreport.java.com/ if you like. -- Kevin Tom Eugelink wrote: > I'm seeing some very small irregularities; short hesitations and then > small jumps ahead. Nothing major, but it is not totally smooth. > (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) > > Slowing the animation to 8 instead of 4 seconds, make these hiccups > better visible. They're most definitely there. > > > On 13-4-2017 08:46, Michael Paus wrote: >> It runs perfectly smooth on my old MacBook Pro from 2012 with JDK >> 8u152 ea. >> >> Am 13.04.17 um 04:25 schrieb Jose Martinez: >>> >>> >>> Many moons ago I complained about jittery PathTransition animation. >>> A bug was openned and I was provided a workaround. This was with >>> Java 7. I revisted the old project that lead to that initial >>> complain, this time with Java 8. The problem seems to be back. I >>> could not find the old bugreport, since I think the JavaFX team is >>> not using the same bug trackingsite. >>> Below is the test code to reproduce. I tried it using JDK 8_64 u5, >>> u11, u25, u112, u121 and the problem occurs with all of them. The >>> ImageViewstutters through the PathTransition. I have a new laptop >>> with 6th gen I7 and plenty of ram. I do not think it is the >>> hardware. This used to besmooth like butter. Anyone else >>> experiencing this or can make any suggestions? >>> >>> @Override >>> public void start(Stage primaryStage) { String >>> rocketImgStr= >>> "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAgakyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pmletPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; >>> >>> Base64.Decoder decoder = Base64.getDecoder(); >>> ByteArrayInputStream rocketInputStream = new >>> ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = >>> new ImageView(new Image(rocketInputStream)); >>> Path path = new Path(); >>> path.getElements().add(new MoveTo(100, 100)); >>> path.getElements().add(new LineTo(500, 100)); >>> path.getElements().add(new LineTo(500, 500)); >>> path.getElements().add(new LineTo(100, 500)); >>> path.getElements().add(new LineTo(100, 100)); >>> PathTransition pathTransition = new >>> PathTransition(Duration.seconds(4), path, iv); >>> pathTransition.setCycleCount(Animation.INDEFINITE); >>> pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); >>> >>> pathTransition.playFromStart(); Group root = new >>> Group(); >>> root.getChildren().add(iv); >>> Scene scene = new Scene(root, 600, 600); >>> primaryStage.setTitle("Hello World!"); >>> primaryStage.setScene(scene); >>> primaryStage.show(); >>> } >>> >>> thanks, >>> jose >>> >> >> >> > > From kevin.rushforth at oracle.com Thu Apr 13 11:49:46 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Apr 2017 04:49:46 -0700 Subject: PathTransition jitter In-Reply-To: <1698099078.1092426.1492074238757@mail.yahoo.com> References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> <1698099078.1092426.1492074238757@mail.yahoo.com> Message-ID: <58EF65DA.7060700@oracle.com> One more thing: all bugs were transfered from the old JavaFX JIRA into JBS in June 2015. You can find the ones you filed using this query: https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx -- Kevin Jose Martinez wrote: > In case it helps, below is the original workaround that was provided. This workaround no longer has any affect. > public class FixedPane extends Group { @Override > public BaseBounds impl_computeGeomBounds(BaseBounds bounds, BaseTransform tx) { > if (!tx.isTranslateOrIdentity()) { > super.impl_computeGeomBounds(bounds, BaseTransform.IDENTITY_TRANSFORM); > } > return super.impl_computeGeomBounds(bounds, tx); > } > } > Forgot to include: using a Windows 10 and Geforce gtx GPU. > > From: Tom Eugelink > To: openjfx-dev at openjdk.java.net > Sent: Thursday, April 13, 2017 3:15 AM > Subject: Re: PathTransition jitter > > I'm seeing some very small irregularities; short hesitations and then small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) > > Slowing the animation to 8 instead of 4 seconds, make these hiccups better visible. They're most definitely there. > > > On 13-4-2017 08:46, Michael Paus wrote: > >> It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea. >> >> Am 13.04.17 um 04:25 schrieb Jose Martinez: >> >>> Many moons ago I complained about jittery PathTransition animation. A bug was openned and I was provided a workaround. This was with Java 7. I revisted the old project that lead to that initial complain, this time with Java 8. The problem seems to be back. I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite. >>> Below is the test code to reproduce. I tried it using JDK 8_64 u5, u11, u25, u112, u121 and the problem occurs with all of them. The ImageViewstutters through the PathTransition. I have a new laptop with 6th gen I7 and plenty of ram. I do not think it is the hardware. This used to besmooth like butter. Anyone else experiencing this or can make any suggestions? >>> >>> @Override >>> public void start(Stage primaryStage) { String rocketImgStr= >>> "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/phCJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAgakyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pmletPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; >>> Base64.Decoder decoder = Base64.getDecoder(); >>> ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new ImageView(new Image(rocketInputStream)); >>> Path path = new Path(); >>> path.getElements().add(new MoveTo(100, 100)); >>> path.getElements().add(new LineTo(500, 100)); >>> path.getElements().add(new LineTo(500, 500)); >>> path.getElements().add(new LineTo(100, 500)); >>> path.getElements().add(new LineTo(100, 100)); PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); >>> pathTransition.setCycleCount(Animation.INDEFINITE); >>> pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); >>> pathTransition.playFromStart(); Group root = new Group(); >>> root.getChildren().add(iv); >>> Scene scene = new Scene(root, 600, 600); >>> primaryStage.setTitle("Hello World!"); >>> primaryStage.setScene(scene); >>> primaryStage.show(); >>> } >>> >>> thanks, >>> jose >>> >>> >> >> > > > > > From mp at jugs.org Thu Apr 13 12:28:11 2017 From: mp at jugs.org (Michael Paus) Date: Thu, 13 Apr 2017 14:28:11 +0200 Subject: JavaFX graphics performance In-Reply-To: <58EBE624.9050009@oracle.com> References: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> <58EBE624.9050009@oracle.com> Message-ID: <32b08c32-5fb3-6cd4-7a7d-fc63ae24b13f@jugs.org> Hi, I have done that already here "Severe performance drop for scene graph path rendering." https://bugs.openjdk.java.net/browse/JDK-8178521 and another one for which I do not have the link yet. "Excessive memory consumption in TriangleMesh/MeshView" Internal review ID : 9048570 Michael Am 10.04.17 um 22:08 schrieb Kevin Rushforth: > We are planning some performance improvements in JDK 10, mostly in the > areas of CSS and layout. If you have specific concerns in other areas > we could look into them. Having a specific test case that shows a > performance problem would be a good start. > > -- Kevin > > > Michael Paus wrote: >> Hi, >> >> more and more people ask me why I am still doing GUI development in >> JavaFX instead >> of following the mainstream and use some web technology. One of the >> arguments >> I could use in the past was performance but nowadays this does not >> seem to be such >> a valid argument anymore. Web technologies are catching up quickly >> and JavaFX currently >> has not much to offer here. Actually the general drawing performance >> is very bad compared >> to what is in principle possible with a modern GPU. I even tried to >> use a TriangleMesh >> to better exploit the graphics hardware but this approach is also >> limited by the fact that >> a TrinangleMesh has an excessive memory usage (about 60 times its >> nominal memory >> consumption). I would therefore like to ask whether there are already >> any plans for Java 10 >> to improve this situation? >> >> Michael From kevin.rushforth at oracle.com Thu Apr 13 12:36:12 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 13 Apr 2017 05:36:12 -0700 Subject: JavaFX graphics performance In-Reply-To: <32b08c32-5fb3-6cd4-7a7d-fc63ae24b13f@jugs.org> References: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> <58EBE624.9050009@oracle.com> <32b08c32-5fb3-6cd4-7a7d-fc63ae24b13f@jugs.org> Message-ID: <58EF70BC.20607@oracle.com> Thank you. We'll take a look at them. The "Excessive memory consumption" should be transfered to the JDK project in a day or two. -- Kevin Michael Paus wrote: > Hi, > I have done that already here > > "Severe performance drop for scene graph path rendering." > https://bugs.openjdk.java.net/browse/JDK-8178521 > > and another one for which I do not have the link yet. > > "Excessive memory consumption in TriangleMesh/MeshView" > Internal review ID : 9048570 > > Michael > > > Am 10.04.17 um 22:08 schrieb Kevin Rushforth: >> We are planning some performance improvements in JDK 10, mostly in >> the areas of CSS and layout. If you have specific concerns in other >> areas we could look into them. Having a specific test case that shows >> a performance problem would be a good start. >> >> -- Kevin >> >> >> Michael Paus wrote: >>> Hi, >>> >>> more and more people ask me why I am still doing GUI development in >>> JavaFX instead >>> of following the mainstream and use some web technology. One of the >>> arguments >>> I could use in the past was performance but nowadays this does not >>> seem to be such >>> a valid argument anymore. Web technologies are catching up quickly >>> and JavaFX currently >>> has not much to offer here. Actually the general drawing performance >>> is very bad compared >>> to what is in principle possible with a modern GPU. I even tried to >>> use a TriangleMesh >>> to better exploit the graphics hardware but this approach is also >>> limited by the fact that >>> a TrinangleMesh has an excessive memory usage (about 60 times its >>> nominal memory >>> consumption). I would therefore like to ask whether there are >>> already any plans for Java 10 >>> to improve this situation? >>> >>> Michael > > From dipak.kumar at oracle.com Fri Apr 14 07:12:00 2017 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Fri, 14 Apr 2017 00:12:00 -0700 (PDT) Subject: Review Request [JDK 8] - 8087545:Line separator is broken in the clipboard of WebView Message-ID: Hi Philip, Kevin, Please review the fix for : JBS: https://bugs.openjdk.java.net/browse/JDK-8087545 Webrev: http://cr.openjdk.java.net/~asrivastava/dipak/8087545/webrev.00/ I have tested the fix on Win64 and Junit test case run was fine. Many thanks, Dipak From mp at jugs.org Fri Apr 14 12:37:52 2017 From: mp at jugs.org (Michael Paus) Date: Fri, 14 Apr 2017 14:37:52 +0200 Subject: JavaFX graphics performance In-Reply-To: <32b08c32-5fb3-6cd4-7a7d-fc63ae24b13f@jugs.org> References: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> <58EBE624.9050009@oracle.com> <32b08c32-5fb3-6cd4-7a7d-fc63ae24b13f@jugs.org> Message-ID: <16d47277-b48e-1774-1db9-0caeffea2d02@jugs.org> For those who are interested. Here is the missing link: "Excessive memory consumption in TriangleMesh/MeshView" https://bugs.openjdk.java.net/browse/JDK-8178804 Michael Am 13.04.17 um 14:28 schrieb Michael Paus: > Hi, > I have done that already here > > "Severe performance drop for scene graph path rendering." > https://bugs.openjdk.java.net/browse/JDK-8178521 > > and another one for which I do not have the link yet. > > "Excessive memory consumption in TriangleMesh/MeshView" > Internal review ID : 9048570 > > Michael > > > Am 10.04.17 um 22:08 schrieb Kevin Rushforth: >> We are planning some performance improvements in JDK 10, mostly in >> the areas of CSS and layout. If you have specific concerns in other >> areas we could look into them. Having a specific test case that shows >> a performance problem would be a good start. >> >> -- Kevin >> >> >> Michael Paus wrote: >>> Hi, >>> >>> more and more people ask me why I am still doing GUI development in >>> JavaFX instead >>> of following the mainstream and use some web technology. One of the >>> arguments >>> I could use in the past was performance but nowadays this does not >>> seem to be such >>> a valid argument anymore. Web technologies are catching up quickly >>> and JavaFX currently >>> has not much to offer here. Actually the general drawing performance >>> is very bad compared >>> to what is in principle possible with a modern GPU. I even tried to >>> use a TriangleMesh >>> to better exploit the graphics hardware but this approach is also >>> limited by the fact that >>> a TrinangleMesh has an excessive memory usage (about 60 times its >>> nominal memory >>> consumption). I would therefore like to ask whether there are >>> already any plans for Java 10 >>> to improve this situation? >>> >>> Michael > > From jmartine_1026 at yahoo.com Fri Apr 14 12:50:00 2017 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 14 Apr 2017 12:50:00 +0000 (UTC) Subject: PathTransition jitter In-Reply-To: <58EF65DA.7060700@oracle.com> References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> <1698099078.1092426.1492074238757@mail.yahoo.com> <58EF65DA.7060700@oracle.com> Message-ID: <1104912949.277882.1492174200192@mail.yahoo.com> Thank you Kevin. For those interested here is the bug report:? http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805 From: Kevin Rushforth To: Jose Martinez Cc: "openjfx-dev at openjdk.java.net" Sent: Thursday, April 13, 2017 7:49 AM Subject: Re: PathTransition jitter One more thing: all bugs were transfered from the old JavaFX JIRA intoJBS in June 2015. You can find the ones you filed using this query: https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx -- Kevin Jose Martinez wrote: In case it helps, below is the original workaround that was provided.? This?workaround no longer has any affect. public class FixedPane extends Group {??? @Override ??? public BaseBounds impl_computeGeomBounds(BaseBounds bounds, BaseTransform tx) { ???????? if (!tx.isTranslateOrIdentity()) { ???????????? super.impl_computeGeomBounds(bounds, BaseTransform.IDENTITY_TRANSFORM); ???????? } ???????? return super.impl_computeGeomBounds(bounds, tx); ??? } } Forgot to include:? using a Windows 10 and Geforce gtx GPU. From: Tom Eugelink To: openjfx-dev at openjdk.java.net Sent: Thursday, April 13, 2017 3:15 AM Subject: Re: PathTransition jitter I'm seeing some very small irregularities; short hesitations and then small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) Slowing the animation to 8 instead of 4 seconds, make these hiccups better visible. They're most definitely there. On 13-4-2017 08:46, Michael Paus wrote: It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea. Am 13.04.17 um 04:25 schrieb Jose Martinez: Many moons ago I complained about jittery PathTransition animation.? A bug was openned and I was provided a workaround. This was with Java 7.? I revisted the old project that lead to that initial complain, this time with Java 8.? The problem seems to be back.? I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite. Below is the test code to reproduce.? I tried it using JDK 8_64 u5, u11, u25, u112, u121 and the problem occurs with all of them.? The ImageViewstutters through the PathTransition.? I have a new laptop with 6th gen I7 and plenty of ram.? I do not think it is the hardware.? This used to besmooth like butter.? Anyone else experiencing this or can make any suggestions? ? ? ? @Override ? ? ? public void start(Stage primaryStage) {? ? ? ? String rocketImgStr= "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz 0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N 2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAga kyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3 NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pm letPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; ? ? ? ? ? Base64.Decoder decoder = Base64.getDecoder(); ? ? ? ? ? ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new ImageView(new Image(rocketInputStream)); ? ? ? ? ? Path path = new Path(); ? ? ? ? ? path.getElements().add(new MoveTo(100, 100)); ? ? ? ? ? path.getElements().add(new LineTo(500, 100)); ? ? ? ? ? path.getElements().add(new LineTo(500, 500)); ? ? ? ? ? path.getElements().add(new LineTo(100, 500)); ? ? ? ? ? path.getElements().add(new LineTo(100, 100)); PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); ? ? ? ? ? pathTransition.setCycleCount(Animation.INDEFINITE); pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); ? ? ? ? ? pathTransition.playFromStart();? ? ? ? Group root = new Group(); ? ? ? ? ? root.getChildren().add(iv); ? ? ? ? ? Scene scene = new Scene(root, 600, 600); ? ? ? ? ? primaryStage.setTitle("Hello World!"); ? ? ? ? ? primaryStage.setScene(scene); ? ? ? ? ? primaryStage.show(); ? ? ? } thanks, jose From mattias.eliasson at medsa.se Fri Apr 14 13:04:20 2017 From: mattias.eliasson at medsa.se (Mattias Eliasson) Date: Fri, 14 Apr 2017 15:04:20 +0200 Subject: JavaFX graphics performance In-Reply-To: References: Message-ID: <20170414150420.ee52d26a37e886ebc7f7ef6f@medsa.se> If what you want is the best performance than neither JavaFX nor web technologies will do. Qt as you mentioned will be much faster and it has native support for embedding OpenGL. In addition you can combine Qt with native optimizations for specific platforms. You can even add inline assembly in order to do very specific optimizations. Hand optimized assembly by a skilled developer will never be outperformed by anything else. The problem with these things of course is that they add a lot of work. Writing Qt code requires you to handle memory and threads and I can constantly see Qt developers failing at this. The VLC UI is written in Qt and it spits out a decent amount of Qt errors on the conseole, and that is probably one of the most well written Qt applications. We have the entire KDE ecosystem based on Qt which is infamous for it's many bugs. And assembly programming of course is a lot more problematic. In order to outperform pre-existing system libraries you sometimes need to know undocumented instructions used by system libraries. This is less of a problem today than it was 20 years ago but it still takes a lot to be good at assembly programming. However this is the JavaFX mailing list so in order to stay on topic I think the discussion should be about how to improve JavaFX performance. Some problems of course are related to the JavaFX code itself, others are rooted in the Java architecture and in JVM memory management. The fact that doing something similar to C/C++ structs and "pragma align" requires ninja level trickery is a problem. I don't know if this is a problem for OpenGL but sometimes when integrating with external systems the lack of "unsigned" is also a real problem, it's probably not a performance problem but writing correct code that deals with data containing unisgned integers can be quite a mess. I don't know OpenGL data structures well enough but in many Internet protocols there are lots of unsigened data to be processed. Also many file formats has that problem. When we are trying to interface Java with low level data such as OpenGL data structures we must recognise that we may need to take these things into consideration for upcoming versions of the JVM. One problem of course are how to deal with these kind of data structures while preserving data integrity and the Java way of doing bounds checking. This is also a big issue I have with the current hacks one have to perform in order to deal with data structures, dealing with large arrays moves the responsibility of data integrity to the application which of course is a breeding ground for bugs. On Tue, 11 Apr 2017 15:26:52 +0200 Nikos Nikolos wrote: > Here is a copy of a previous post I sent, needs are still the same on my > side and I don't see anything coming from the JavaFX side... > > > OpenGL rendering was a nice solution for performance intensive application > on the desktop. Since JavaFX doesn't offer a native OpenGL handle you can > use such a solution. > > > CSS and layout improvement are quite out of scope for the inital needs I > think. > > > Electron is becoming trendy maybe with some WebGL inside it you will be > able to outperform JavaFX rendering speed! > > > I really enjoyed desktop GUI development in Java but them came JavaFX... > > > > > Following the thread http://mail.openjdk.java.net/ > pipermail/openjfx-dev/2016-December/020025.html I would like to ask for > more information on JavaFX plan to allow a simple way to use existing > OpenGL code. > > > > I know this is not a new question and please forgive me if I?ve overlooked > some answers already posted. > > > > I work in the niche area where desktop applications are still needed and > use Swing since 2001, integrated Jogl and then Jogamp since 2006 and that > try to figure out how we can use JavaFX without a huge performance drop. I > think this bug https://bugs.openjdk.java.net/browse/JDK-8091324 is the best > summary of potential needs. And the answer gave by Kevin Rushforth was > quite disappointing. > > > > I remember Swing teams members (Kenneth Bradley Russell) working hard to > have a nice way to use OpenGL in a platform independent manner which is one > of the strength of Java. JOGAMP team also made a good work more recently. > > > > Some tricks have been used to try to provide a solution: > > ? https://github.com/SkyLandTW/JOGL-FX#jogl-on-javafx-es2 > > ? https://github.com/pepe1914/jfx-zoglpipeline > > ? https://www.youtube.com/watch?v=aYRF34UYu-E > > But they are very fragile (use of internal classes, rebundling JavaFx > jars?). > > > > Is this need too specific for a change to have it implemented in JavaFX? > > Going on with Swing is a potential solution but it won?t resist a > comparison with QT long. > > > > Thanks for any of your ideas on that. > > Regards > > > > ---------- Message transf?r? ---------- > From: Mattias Eliasson > To: openjfx-dev at openjdk.java.net > Cc: > Bcc: > Date: Tue, 11 Apr 2017 14:49:10 +0200 > Subject: Re: JavaFX graphics performance > Excessive memory usage is more of a well documented JDK problem that > impacts the performance of many applications. Especially when having a > large collection of instances of the same class. In C++ an array of objects > are in memory similar to an array of structs. In Java they are arrays of > pointers to objects on the heap. > > This could of course be worked around by storing data in arrays and using > classes to wrap those arrays. In one project I stored X and Y coordinates > in an array. I had a class with getter and setters but also with a > reference to the array and index. On top of that I had what worked > similarly to a standard object pool but in fact only had a few instances of > the object, changing index of a free object rather than allocating a new. > For simplicity I used an array for X and another for Y. > > This pattern can be refined to align data in various ways for better cache > performance. And in our case there may be alignments that gives better GPU > performance. After all it's usually the GPU that process our data. > > Of course it would be best if the JVM had better memory management > including something similar to a struct array without pointers to objects. > But there would still be need to have refinements. For example is it better > to have XXXYYY, XYXYXY, or perhaps YXYXYX? That in turn depends on cache > infrastructure, the order data is accessed and other factors. > > In order notes the main competition to JavaFX is other Java APIs such as > Swing and it's Java2D. When it comes to performance we obviously have a > clear winner. But JavaFX isn't shipped within major Linux distributions so > it is yet considered experimental by many that use Swing. There are also > competition from SWT used by Eclipse and Azureus/Vuze. Packaging is one > problem but there are also UI components missing. The SWT on JavaFX > implementation has a list of SWT components and their JavaFX counterpart. > That list illustrates that there are a lot of work to do. > > Of course once SWT on JavaFX is complete SWT will be eliminated as > competition. Especially if Eclipse use JavaFX as its SWT backend. It would > also mean that JavaFX is better equipped to compete with Swing as SWT > already is a strong competitor to Swing. > > However SWT has been held back due to stability problems which probably > will not be in the way when it's based on JavaFX which is good enterprise > code. > > As for competing with web technologies it would have helped if we had a > modern browser plugin. JavaFX as an UI may not be faster than browser > technologies. But Java bytecode is a lot faster than JavaScript. Take RPC > for example. If you use browser technology you would probably be using Json > at best. With Java you have binary protocols like Jboss Remoting which ia > easy to code and much faster than using Json in JavaScript. > > Web technologies can only compete where there is an API implemented in > something other than JavaScript. Once processing is done in JavaScript the > it becomes a lot slower than Java. > > I would suggest creating a new fully sandboxed applet technology based on > JavaFX instead of AWT/Swing. That of course would be incompatible with > classic Applets but those are dead anyway. Make it at least as good as > Flash perhaps with an IDE like the commercial flash IDE. I mean > activescript vs Hotspot will not be a very fair match. > > Another competitor is Unity and similar game engines. As unity is based on > mono and MonoDevelop we could do something similar using Java and eclipse. > > When it comes to web/client server Vaadin has been gaining a lot of ground. > It's model of having a combined client and server code base using byte > buddy or ASM to separate client and server into separate executables is > impressive. I would like more control such as specifying @client or @server > in order to control where execution take place. But more to the point I > would like a JavaFX UI. > > While web technologies are moving in on Java they do have a far way to go > before they have what java has. We have Hotspot for starters and that's way > ahead of JavaScript and Flash. What we don't have is browser integration. > > Let's take the lessons learned from both Flash and Java Applets and make > something awesome. That doesn't carry "java" in the name. Like OpenFX? Or > "Arrow" (yeah I'm a nerd). This including the creative tools that Flash has > but perhaps also with features that Unity has. > > > > Kevin Rushforth skrev: (10 april 2017 22:08:04 > CEST) > >We are planning some performance improvements in JDK 10, mostly in the > >areas of CSS and layout. If you have specific concerns in other areas > >we > >could look into them. Having a specific test case that shows a > >performance problem would be a good start. > > > >-- Kevin > > > > > >Michael Paus wrote: > >> Hi, > >> > >> more and more people ask me why I am still doing GUI development in > >> JavaFX instead > >> of following the mainstream and use some web technology. One of the > >> arguments > >> I could use in the past was performance but nowadays this does not > >> seem to be such > >> a valid argument anymore. Web technologies are catching up quickly > >and > >> JavaFX currently > >> has not much to offer here. Actually the general drawing performance > >> is very bad compared > >> to what is in principle possible with a modern GPU. I even tried to > >> use a TriangleMesh > >> to better exploit the graphics hardware but this approach is also > >> limited by the fact that > >> a TrinangleMesh has an excessive memory usage (about 60 times its > >> nominal memory > >> consumption). I would therefore like to ask whether there are already > > > >> any plans for Java 10 > >> to improve this situation? > >> > >> Michael -- Mattias Eliasson From kevin.rushforth at oracle.com Fri Apr 14 13:29:41 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Apr 2017 06:29:41 -0700 Subject: PathTransition jitter In-Reply-To: <1104912949.277882.1492174200192@mail.yahoo.com> References: <820496043.177903.1491969328161.ref@mail.yahoo.com> <820496043.177903.1491969328161@mail.yahoo.com> <1125214297.998674.1492050300949@mail.yahoo.com> <7a039764-d125-716f-399e-b1d8f496b441@jugs.org> <1698099078.1092426.1492074238757@mail.yahoo.com> <58EF65DA.7060700@oracle.com> <1104912949.277882.1492174200192@mail.yahoo.com> Message-ID: <58F0CEC5.4040401@oracle.com> And here is the direct link in JBS: https://bugs.openjdk.java.net/browse/JDK-8178805 -- Kevin Jose Martinez wrote: > Thank you Kevin. > For those interested here is the bug report: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805 > > > > > From: Kevin Rushforth > To: Jose Martinez > Cc: "openjfx-dev at openjdk.java.net" > Sent: Thursday, April 13, 2017 7:49 AM > Subject: Re: PathTransition jitter > > One more thing: all bugs were transfered from the old JavaFX JIRA intoJBS in June 2015. You can find the ones you filed using this query: > > https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx > > -- Kevin > > > Jose Martinez wrote: > In case it helps, below is the original workaround that was provided. This workaround no longer has any affect. > public class FixedPane extends Group { @Override > public BaseBounds impl_computeGeomBounds(BaseBounds bounds, BaseTransform tx) { > if (!tx.isTranslateOrIdentity()) { > super.impl_computeGeomBounds(bounds, BaseTransform.IDENTITY_TRANSFORM); > } > return super.impl_computeGeomBounds(bounds, tx); > } > } > Forgot to include: using a Windows 10 and Geforce gtx GPU. > > From: Tom Eugelink > To: openjfx-dev at openjdk.java.net > Sent: Thursday, April 13, 2017 3:15 AM > Subject: Re: PathTransition jitter > > I'm seeing some very small irregularities; short hesitations and then small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64) > > Slowing the animation to 8 instead of 4 seconds, make these hiccups better visible. They're most definitely there. > > > On 13-4-2017 08:46, Michael Paus wrote: > > It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea. > > Am 13.04.17 um 04:25 schrieb Jose Martinez: > > Many moons ago I complained about jittery PathTransition animation. A bug was openned and I was provided a workaround. This was with Java 7. I revisted the old project that lead to that initial complain, this time with Java 8. The problem seems to be back. I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite. > Below is the test code to reproduce. I tried it using JDK 8_64 u5, u11, u25, u112, u121 and the problem occurs with all of them. The ImageViewstutters through the PathTransition. I have a new laptop with 6th gen I7 and plenty of ram. I do not think it is the hardware. This used to besmooth like butter. Anyone else experiencing this or can make any suggestions? > > @Override > public void start(Stage primaryStage) { String rocketImgStr= > "iVBORw0KGgoAAAANSUhEUgAAADIAAAAdCAYAAADoxT9SAAAACXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph > CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz > 0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3ENz30T6RJZE3ptnMU85ry1KNSo+qi5qPNo3ujS6P8YuZlnM1VidWElsSxw5LiquNm5svt/87fOH4p3iC+N7F5gvyF1weaHOwvSFpxapLhIsOpZATIhOOJTwQRAqqBaMJfITdyWOCnnCHcJnIi/RNtGI2ENcKh5O8kgqTXqS7JG8NXkkxTOlLOW5hCepkLxMDUzdmzqeFpp2IG0yPTq9MYOSkZBxQqohTZO2Z+pn5mZ2y6xlhbL+xW6Lty8elQfJa7OQrAVZLQq2QqboVFoo1yoHsmdlV2a/zYnKOZarnivN7cyzytuQN5zvn//tEsIS4ZK2pYZLVy0dWOa9rGo5sjxxedsK4xUFK4ZWBqw8uIq2Km3VT6vtV5eufr0mek1rgV7ByoLBtQFr6wtVCuWFfevc1+1dT1gvWd+1YfqGnRs+FYmKrhTbF5cVf9go3HjlG4dvyr+Z3JS0qavEuWTPZtJm6ebeLZ5bDpaql+aXDm4N > 2dq0Dd9WtO319kXbL5fNKNu7g7ZDuaO/PLi8ZafJzs07P1SkVPRU+lQ27tLdtWHX+G7R7ht7vPY07NXbW7z3/T7JvttVAVVN1WbVZftJ+7P3P66Jqun4lvttXa1ObXHtxwPSA/0HIw6217nU1R3SPVRSj9Yr60cOxx++/p3vdy0NNg1VjZzG4iNwRHnk6fcJ3/ceDTradox7rOEH0x92HWcdL2pCmvKaRptTmvtbYlu6T8w+0dbq3nr8R9sfD5w0PFl5SvNUyWna6YLTk2fyz4ydlZ19fi753GDborZ752PO32oPb++6EHTh0kX/i+c7vDvOXPK4dPKy2+UTV7hXmq86X23qdOo8/pPTT8e7nLuarrlca7nuer21e2b36RueN87d9L158Rb/1tWeOT3dvfN6b/fF9/XfFt1+cif9zsu72Xcn7q28T7xf9EDtQdlD3YfVP1v+3Njv3H9qwHeg89HcR/cGhYPP/pH1jw9DBY+Zj8uGDYbrnjg+OTniP3L96fynQ89kzyaeF/6i/suuFxYvfvjV69fO0ZjRoZfyl5O/bXyl/erA6xmv28bCxh6+yXgzMV70VvvtwXfcdx3vo98PT+R8IH8o/2j5sfVT0Kf7kxmTk/8EA5jz/GMzLdsAAAAgY0hSTQAAeiUAAICDAAD5/wAAgOkAAHUwAADqYAAAOpgAABdvkl/FRgAACHRJREFUeNrMmH9s1OUdx1/fH/e9u2/vrgdtaaXt9ZDRXoeGEsAxN0EWGWwoohFnTGrqZkxMxEW00TkzFrcpuKgJJFIyzeIgGzAX4485nSmdKM2mrGUtIBMKpfWoHOXo9bi77933x7M/er3Qlh9lk+mTPMl9c8/3+X7ez/v9fJ7P85YYaQGgRoVZHoj4ITIVaqZAuR+KPeBWgAw4Q5D4DI73QbuAt4F2viKtGegAEl8DcQ+IjSB2gTgKIgVCnNNtEDEQfwXxAGQD8Aeg5ssGIQGzgXLApUJAga > kyVHhGGKmuhJo6CC0A9zfzg+VzJtgD3AMdR2EF8PmXCeRS/weBmcCCErj5u3DTQ6DNA1z5QbuBpfBMDp4AyoDpwLT87yDgBRTAGVEoZ4AYcCLfh640kPO1xdfClm1QFwb+DewFfuF2x/Sqqu5QKHT1jBkzplVVVekVFRVScXExPp8PRVGwLItUKsXQ0BADAwPi+PHjZ48cOTJw9OjRgydPntwLfAB0Asn/BxCA394iy02ltbV45s3j6oULmXfNNdSEQgSDQYLBILIsT2qiXC5HNBqlq6uL999/39q1a9cn3V1d7zhC/BH4+ErI8Brgyfr6+r0PrlmT3f7GG+Jgb68YSqWEkc2KVColEomEiMfj4vTp0yKZTArTNMXltqGhIfHmW2+J+XPmZHzwGrDsi2DEAywOBoP3Lly48PuGYfg3btxIfX09lmWRy+WwLAshxIQXhRDIsoymabjdblRVRZImL4DmpiYWvfIKHXPmOC8ODr4Ri0bXA/+40PhL8X/37bff/vbWrVt/8PTTT/vD4TC6rpNOp0mlUpimeV4QAJIkIYTAMAyGh4dJJpPYtj1pIDnbJgKsi8flv91336rGxsZWCX6ZTx6XDaR0+fLlcm1tLYlEAsMwsG37gsFfCJCmadi2zb59+2hra+PAgQNYlnXx92QZA6C/n/pNm/jdDTcU7dix46dXh8NvAXPHj1cvEYcVi8WIRqOcOXMGy7IuSx4AHo+HQ4cOsX37djKZDJqqkDMtinw+Ghsbqa2txbZtXC4XiqIU5h+zWPE4PPAAq9evZ35b27cebm5+5/VXX30I2DFZRrBtG8dx/qvsoGkan376KZs2bULXvUiqi88NC9mlobs1nnvuOQ4fPkwulyORSJBIJEilUhiWhRj/TduG5mZmbNjAzi1bpj3+1FNbJUlaM1kgWZfbjUfX0bxeZFXFU1SE7vNN6F5dH8OWJElYlsW2bdsIhULET51i6bJlfOPBtfQ23Eh3 > NEaospKdO3cWmLAsC8MwMLLZC0fU0oJ25508c++9rl+3tGyUVPVRAFWFh70j2Wm88C3gxo9bW4n19JDJZOg/cICXX3gBn883hiXbcdCDQe646y50XcdxHFRV5ciRI6TOniVn2yy95VZWfm85BlDx9ZlszZokD+3BMk0GBgaYNm0aQggkSbq0fFtbYdEiHtm8mTOPPrrh2WefTal18PydgH0eJABn33uPHKAB3wZOdnfz+Tl5WwJyQKffz9Jbby2AlGWZ06dPo7lcxA2Lw5WzSQM6sFKGvrnXsr+zjakelWQySXl5+eXp9tgxWLWKnyxeLO9U1Z+rh+ChDeC+ACPfWbZ8+cpwOIxhGHzQ0cGKFSsQQCaTKayc7TjcUVpKMM8GgOM4BAIBsrkcJbrO7o5/MX12NbcpI4VXTf9+orobK5fD7/efdx+ejxcBpPLdbxj87N137WPwpGrDpvRFstZ1S5asXLRoEUNDQ8SzWe5oakJVVbLZbOFDjhD4fT68Xm8hINu2CYfDuDSN0mAx/bvfZIfkcGJOhOpjB/mgtZXAlCm4AgEqKiowTXMCiGy+wpTyq5oGhvOVZymwDsTz8Ajwm0ulX3c2k+Hs8DDJRIJMKsVnfX2UlJQUAh7VdTAQGJMyHcfB6/WyevVqWlpamFtXx2BnG51/f5c+r5tgSQnRaJTm5maEEBPOplEgfYCZD94CpgB+4DHIvQQ/BlomlX4TiQSxWIzBwUFM05ywGWVZpqSkBF3XJwRjmiZz587l/vvvZyAWI5tJM1UBI5XCMAzWrl1LdXX1BDbGS8vKBxrOs3IPDLwEd4+CmMyBqKqqOuagGl9P6bpOUVFRAdT41TVNk/nz5xOJROjp6WF4eJiysjJmzZqFoihkL5JqRZ6JkjwTbwKPw+4+WAN0Xc7Jfqq9vd0uLi5WSktLUVUVVVULwUqSRDqd5sSJE3g8HrxeL5qm4XK5CswJITBNE6/XS0NDA7IsY9s2pm > letPYSeQnVAfuBJyC5DZ5npA9fbony+z179vR1dnY2RSKRm1VVDbrdbkpLS0mn0xiGUaiCc7kcyWQSRVFwuVwFQKPgFUXBNE1kWS6wey7YcySArutoLhc9wE6wW+C1QVgP/POLuFjVAysjkchtNy5Z0nDd4sXuSCRCSSCA7DiYeTCjJc1ocJIkFYKXZRlFUcY8jwIdLfVTqRQdnZ38at269CddXW+nYTOw60rdEF9eJUk/9NfWojU0MHPBAmbX1VE1fTo+nw+Xy1WQn+M4E4CNgnAch2w2Szwep6enh48++shsb2/f393d/RfgT3l358rd2efBlpegzgaOAgeAFrf7pF5Zua+6qmpmKBQqr6io0MvKyhS/34/H40FRFGzbLtxPTp06Zff39yd7e3ujvb29B2Ox2F7gQ2BfPjldORflKrh5Fdz0GGiVQDy/yf4M/AieMUdclKnAVee4KMVAUT6DOvlD+QwwCAzkXZQk/2M7r6+lQIUONVOhugZqZkPoenBfD1SOm+B1YA109H/JvtYYp3EmiCYQm0F8COIzELlxTmMCxGEQr4JohKzvK+Q0TvB+AxAphppiKC+CYm2kqCSb934H4PjAiOf7lfF+/zMAVaPsnAfVjSoAAAAASUVORK5CYII="; > Base64.Decoder decoder = Base64.getDecoder(); > ByteArrayInputStream rocketInputStream = new ByteArrayInputStream(decoder.decode(rocketImgStr)); ImageView iv = new ImageView(new Image(rocketInputStream)); > Path path = new Path(); > path.getElements().add(new MoveTo(100, 100)); > path.getElements().add(new LineTo(500, 100)); > path.getElements().add(new LineTo(500, 500)); > path.getElements().add(new LineTo(100, 500)); > path.getElements().add(new LineTo(100, 100)); PathTransition pathTransition = new PathTransition(Duration.seconds(4), path, iv); > pathTransition.setCycleCount(Animation.INDEFINITE); > pathTransition.setOrientation(PathTransition.OrientationType.ORTHOGONAL_TO_TANGENT); > pathTransition.playFromStart(); Group root = new Group(); > root.getChildren().add(iv); > Scene scene = new Scene(root, 600, 600); > primaryStage.setTitle("Hello World!"); > primaryStage.setScene(scene); > primaryStage.show(); > } > > thanks, > jose > > > > > > > > > From mp at jugs.org Fri Apr 14 14:36:43 2017 From: mp at jugs.org (Michael Paus) Date: Fri, 14 Apr 2017 16:36:43 +0200 Subject: Canvas Content Shift In-Reply-To: <004e439f-a6f8-1047-c50c-bfe5549dadf3@oracle.com> References: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> <004e439f-a6f8-1047-c50c-bfe5549dadf3@oracle.com> Message-ID: I think we can agree that this is kind of an expert feature but you definitely need such features for any high-level interface if you want to achieve a good performance. The root of the problems you have described is the same as the one you are already confronted with today when you want to make a clear and crisp snapshot of a canvas. A simple snapshot on a system with pixel scaling is blurry and totally unusable. In order to avoid this I use the code below. public static WritableImage renderScaleAwareCanvasSnapshot(Canvas canvas, double renderScale, WritableImage writableImage) { if (writableImage == null || (int)Math.rint(writableImage.getWidth()) != (int)Math.rint(renderScale*canvas.getWidth()) || (int)Math.rint(writableImage.getHeight()) != (int)Math.rint(renderScale*canvas.getHeight())) { writableImage = new WritableImage((int)Math.rint(renderScale*canvas.getWidth()), (int)Math.rint(renderScale*canvas.getHeight())); } SnapshotParameters spa = new SnapshotParameters(); spa.setTransform(Transform.scale(renderScale, renderScale)); return canvas.snapshot(spa, writableImage); } For my Mac (Retina) I know that the renderScale is 2.0 but how do you find that out in the general case? I am asking for such an API already for quite a while. Once you know the renderScale things become easy. In principle you can do the canvas shift already right now by using the above code, although the performance will of course be sub-optimal. That's the reason why we ask for a more specific API here so that ideally this shift could be done completely on the graphics hardware. Michael Am 10.04.17 um 20:17 schrieb Jim Graham: > Any suggestions on how to implement this when the size of pixels may > be an arbitrary non-integer number? > > Consider rendering on a 125% scaled Windows 10 screen. If you want to > scroll by 2 pixels you would want to scroll by 1.6 coordinate units. > If you want to scroll by 2 coordinate units you are out of luck > because that would attempt to "scroll by 2.5 pixels" and there is no > good definition of that type of operation. > > We could add a pixel size parameter (note that it might be different > than the window or screen render scale because the Canvas cannot > re-render and so it chooses the scale of the deepest screen). Then it > would be up to the developer to take this into account when > determining how far to scroll, but that is a bit more complicated than > what developers tend to be used to when they deal with scrolling. > > Note that the scrolling of JViewport is handled by our own code, not > developer code, so we can take these adjustments into account > ourselves internally and know if/when we can blit or if/when we need > to re-render... > > ...jim > > On 4/10/17 1:32 AM, Dirk Lemmermann wrote: >> HI there, >> >> I was wondering if there is any chance that Java 10 could implement >> some sort of ?content shifting? for the Canvas API? >> >> I would love to have this feature for supporting faster horizontal >> scrolling in my Gantt Chart framework FlexGanttFX. Currently when the >> user scrolls then the entire content of each canvas in each row of >> the chart will be redrawn. This could be optimized by only drawing >> the time range that has been moved into the ?viewport? and by >> shifting or copying the remaining time range graphics. E.g. the user >> currently looks at one week and scrolls one day to the right then the >> data / graphics of 6 days would stay the same and could just be >> reused. Only one day worth of data would need to be redrawn. >> >> I think in Swing this is comparable with the BLIT_SCROLL_MODE of >> JViewport. >> >> Dirk >> From james.graham at oracle.com Fri Apr 14 20:19:26 2017 From: james.graham at oracle.com (Jim Graham) Date: Fri, 14 Apr 2017 13:19:26 -0700 Subject: Canvas Content Shift In-Reply-To: References: <37192FD9-62E0-4DB2-A9F1-E261B43BF0D2@gmail.com> <004e439f-a6f8-1047-c50c-bfe5549dadf3@oracle.com> Message-ID: <94800cd5-5368-da5a-8fbb-e49695c2c8e1@oracle.com> On 4/14/17 7:36 AM, Michael Paus wrote: > For my Mac (Retina) I know that the renderScale is 2.0 but how do you find that out in the general case? In JDK 9 you have: Screen.getOutputScaleX/Y() Window.outputScaleX/Y (read-only double properties, based on Screen values) Window.renderScaleX/Y (get/set double properties, default to output scales) Window.forceIntegerRenderScale (get/set boolean property) In the case of Canvas, though, since we can't re-render currently (we have an outstanding wish-list item to add invalidation and repaint capabilities to it so we can make the data non-persistent) we have to choose the largest rendering scale that we might ever need - which is basically the max of all of the Screen output scales. We need to add (for 10, too late for 9): Canvas.renderScaleX/Y properties, gettable for all, settable only for non-persistent canvas objects and maybe: Canvas.repaint/validate/etc. for enabling non-persistence ...jim From james.graham at oracle.com Fri Apr 14 20:31:53 2017 From: james.graham at oracle.com (Jim Graham) Date: Fri, 14 Apr 2017 13:31:53 -0700 Subject: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer Message-ID: <1e4a7e5b-2de2-b0de-e4a3-41fa84abd2c7@oracle.com> JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ The only way to get one of the old Pisces rasterizers now is to manually disable Marlin (or use the new order option as follows). This fix also introduces a similar pattern for rasterizer selection that we use for pipeline selection: -Dprism.rasterizerorder=listof( marlin|marlinfloat|marlindouble| pisces|javapisces|nativepisces| *) (unknown values are ignored for future/backwards-proofing) Suggestions for naming of the new rasterizer identifiers and the "public name" strings are welcome... ...jim From james.graham at oracle.com Fri Apr 14 20:35:17 2017 From: james.graham at oracle.com (Jim Graham) Date: Fri, 14 Apr 2017 13:35:17 -0700 Subject: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer In-Reply-To: <1e4a7e5b-2de2-b0de-e4a3-41fa84abd2c7@oracle.com> References: <1e4a7e5b-2de2-b0de-e4a3-41fa84abd2c7@oracle.com> Message-ID: I was going to tag Kevin and Laurent on this, but forgot to amend the address lines before I hit send... ...jim On 4/14/17 1:31 PM, Jim Graham wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 > webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ > > The only way to get one of the old Pisces rasterizers now is to manually disable Marlin (or use the new order option as > follows). > > This fix also introduces a similar pattern for rasterizer selection that we use for pipeline selection: > > -Dprism.rasterizerorder=listof( > marlin|marlinfloat|marlindouble| > pisces|javapisces|nativepisces| > *) > (unknown values are ignored for future/backwards-proofing) > > Suggestions for naming of the new rasterizer identifiers and the "public name" strings are welcome... > > ...jim From mp at jugs.org Fri Apr 14 20:45:16 2017 From: mp at jugs.org (Michael Paus) Date: Fri, 14 Apr 2017 22:45:16 +0200 Subject: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer In-Reply-To: <1e4a7e5b-2de2-b0de-e4a3-41fa84abd2c7@oracle.com> References: <1e4a7e5b-2de2-b0de-e4a3-41fa84abd2c7@oracle.com> Message-ID: Will marlindouble remain the default when you say nothing or when you specify just marlin? Am 14.04.17 um 22:31 schrieb Jim Graham: > JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 > webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ > > The only way to get one of the old Pisces rasterizers now is to > manually disable Marlin (or use the new order option as follows). > > This fix also introduces a similar pattern for rasterizer selection > that we use for pipeline selection: > > -Dprism.rasterizerorder=listof( > marlin|marlinfloat|marlindouble| > pisces|javapisces|nativepisces| > *) > (unknown values are ignored for future/backwards-proofing) > > Suggestions for naming of the new rasterizer identifiers and the > "public name" strings are welcome... > > ...jim From bourges.laurent at gmail.com Fri Apr 14 22:31:28 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sat, 15 Apr 2017 00:31:28 +0200 Subject: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer In-Reply-To: <1e4a7e5b-2de2-b0de-e4a3-41fa84abd2c7@oracle.com> References: <1e4a7e5b-2de2-b0de-e4a3-41fa84abd2c7@oracle.com> Message-ID: Jim, It looks good to me (even I am not an official reviewer) and the Marlin Double-precision will be the default rasterizer. Bye, Laurent Le 14 avr. 2017 22:32, "Jim Graham" a ?crit : > JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 > webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ > > The only way to get one of the old Pisces rasterizers now is to manually > disable Marlin (or use the new order option as follows). > > This fix also introduces a similar pattern for rasterizer selection that > we use for pipeline selection: > > -Dprism.rasterizerorder=listof( > marlin|marlinfloat|marlindouble| > pisces|javapisces|nativepisces| > *) > (unknown values are ignored for future/backwards-proofing) > > Suggestions for naming of the new rasterizer identifiers and the "public > name" strings are welcome... > > ...jim > From james.graham at oracle.com Fri Apr 14 22:40:20 2017 From: james.graham at oracle.com (Jim Graham) Date: Fri, 14 Apr 2017 15:40:20 -0700 Subject: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer In-Reply-To: References: <1e4a7e5b-2de2-b0de-e4a3-41fa84abd2c7@oracle.com> Message-ID: <9bfa6d54-38dd-c1f7-1c73-62665aca74ca@oracle.com> Yes... ...jim On 4/14/17 1:45 PM, Michael Paus wrote: > Will marlindouble remain the default when you say nothing or when you specify just marlin? > > Am 14.04.17 um 22:31 schrieb Jim Graham: >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 >> webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ >> >> The only way to get one of the old Pisces rasterizers now is to manually disable Marlin (or use the new order option >> as follows). >> >> This fix also introduces a similar pattern for rasterizer selection that we use for pipeline selection: >> >> -Dprism.rasterizerorder=listof( >> marlin|marlinfloat|marlindouble| >> pisces|javapisces|nativepisces| >> *) >> (unknown values are ignored for future/backwards-proofing) >> >> Suggestions for naming of the new rasterizer identifiers and the "public name" strings are welcome... >> >> ...jim > > From kevin.rushforth at oracle.com Fri Apr 14 22:41:28 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 14 Apr 2017 15:41:28 -0700 Subject: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer In-Reply-To: References: <1e4a7e5b-2de2-b0de-e4a3-41fa84abd2c7@oracle.com> Message-ID: <58F15018.2070808@oracle.com> Looks good to me, too. -- Kevin Laurent Bourg?s wrote: > Jim, > > It looks good to me (even I am not an official reviewer) and the Marlin > Double-precision will be the default rasterizer. > > Bye, > Laurent > > Le 14 avr. 2017 22:32, "Jim Graham" a ?crit : > > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 >> webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ >> >> The only way to get one of the old Pisces rasterizers now is to manually >> disable Marlin (or use the new order option as follows). >> >> This fix also introduces a similar pattern for rasterizer selection that >> we use for pipeline selection: >> >> -Dprism.rasterizerorder=listof( >> marlin|marlinfloat|marlindouble| >> pisces|javapisces|nativepisces| >> *) >> (unknown values are ignored for future/backwards-proofing) >> >> Suggestions for naming of the new rasterizer identifiers and the "public >> name" strings are welcome... >> >> ...jim >> >> From markus at headcrashing.eu Sun Apr 16 16:36:58 2017 From: markus at headcrashing.eu (Markus KARG) Date: Sun, 16 Apr 2017 18:36:58 +0200 Subject: Subject: [8u121] Review request for JDK-8178837: Potential performance drawback due to type mismatch Message-ID: <000001d2b6cf$adf51010$09df3030$@eu> https://bugs.openjdk.java.net/browse/JDK-8178837 There is a potential performance drawback due to a type mismatch in TriangleMesh.java:548 as `points.size()` returns `int` so storing as `double` makes not much sense. I provided a patch which simply replaces double by int. From murali.billa at oracle.com Mon Apr 17 07:29:19 2017 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 17 Apr 2017 00:29:19 -0700 (PDT) Subject: [10] Review request for 8176729: com.sun.webkit.dom.NodeImpl#SelfDisposer is not called In-Reply-To: References: <5d429381-0799-e757-c070-827af4746317@oracle.com> <4816ea91-3506-4e52-84f6-86f04768d6f3@default> <9d808a20-87b9-4b9e-bcd8-a3a7a8ad2a20@default> <6d514638-a60c-4215-9b0e-f28514cdbeb9@default> <4e8a047a-3bf0-433c-94a3-b5c996421185@default> Message-ID: ? ? Hi Kevin, Arun, Guru Please review the fix for ? JDK-8176729. JIRA: https://bugs.openjdk.java.net/browse/JDK-8176729 ? Webrev: http://cr.openjdk.java.net/~mbilla/8176729/webrev.00/ ? Thanks, Murali From markus at headcrashing.eu Mon Apr 17 16:15:50 2017 From: markus at headcrashing.eu (Markus KARG) Date: Mon, 17 Apr 2017 18:15:50 +0200 Subject: [8u121] Review request for JDK-8177077: Constructing multiple Image objects using animated GIFs concurrently can fail with AIOOBE Message-ID: <001e01d2b795$e159bb10$a40d3130$@eu> https://bugs.openjdk.java.net/browse/JDK-8177077 Please review the patch attached to JDK-8177077 I simply wrapped invocations to Timeline.play() and Timeline.stop() by Platform.runLater, so it should be thread safe now. From kevin.rushforth at oracle.com Mon Apr 17 16:28:50 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Apr 2017 09:28:50 -0700 Subject: [8u121] Review request for JDK-8177077: Constructing multiple Image objects using animated GIFs concurrently can fail with AIOOBE In-Reply-To: <001e01d2b795$e159bb10$a40d3130$@eu> References: <001e01d2b795$e159bb10$a40d3130$@eu> Message-ID: <58F4ED42.8010505@oracle.com> One correction: All code reviews need to be done for JDK 10. This applies to the fix for 8178837 as well. Please resubmit the webrevs against FX 10-dev. Separately, once the fix is done, and if the fix is safe enough and important enough, we might consider it for a backport to JDK 9u (which isn't open yet, but we hope will be soon), and 8u for a future update release of JDK 9.x and 8uNN. -- Kevin Markus KARG wrote: > https://bugs.openjdk.java.net/browse/JDK-8177077 > > > > Please review the patch attached to JDK-8177077 > > > > I simply wrapped invocations to Timeline.play() and Timeline.stop() by > Platform.runLater, so it should be thread safe now. > > From kevin.rushforth at oracle.com Tue Apr 18 00:00:19 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Apr 2017 17:00:19 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules Message-ID: <58F55713.80602@oracle.com> Please review the following javadoc change: https://bugs.openjdk.java.net/browse/JDK-8178015 http://cr.openjdk.java.net/~kcr/8178015/webrev.00/ This restores the links to the Module class that had to be removed during the transition period for the move of Module and Layer from java.lang.reflect to java.lang, and makes the requirements for running an application in a named module more clear. I also fixed a couple related typos in the modified paragraphs. -- Kevin From kevin.rushforth at oracle.com Tue Apr 18 00:14:50 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 17 Apr 2017 17:14:50 -0700 Subject: HEADS-UP: Bump the minimum buildnum for the boot JDK used by FX 9 (and FX 10) to build 165 Message-ID: <58F55A7A.1090702@oracle.com> The last module system refresh that went into build 165 moved the Module and Layer class from java.lang.reflect to java.lang. This is both a source and binary incompatible change, and since we want to reference Module in our javadocs (at least) it's time to bump the minimum build number to 165. Absent any concerns regarding this, I would like to push the change some time on Wednesday or Thursday of this week. This means that all JavaFX developers should download the latest EA build of JDK 9, which is jdk-9+165. Let me know if you have questions or concerns. Thanks. -- Kevin From mandy.chung at oracle.com Tue Apr 18 01:13:06 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 17 Apr 2017 18:13:06 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58F55713.80602@oracle.com> References: <58F55713.80602@oracle.com> Message-ID: <246723BF-BD78-4F2B-9DF3-B42220B01DAE@oracle.com> > On Apr 17, 2017, at 5:00 PM, Kevin Rushforth wrote: > > Please review the following javadoc change: > > https://bugs.openjdk.java.net/browse/JDK-8178015 > http://cr.openjdk.java.net/~kcr/8178015/webrev.00/ > + *

Applications in a Module

: + * {@link Module#isOpen(String,Module) open} the containing package to the + * {@code javafx.graphics} module. to ?at least? javafx.graphics module. Otherwise looks good. Mandy From Alan.Bateman at oracle.com Tue Apr 18 07:40:34 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Apr 2017 08:40:34 +0100 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58F55713.80602@oracle.com> References: <58F55713.80602@oracle.com> Message-ID: <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> On 18/04/2017 01:00, Kevin Rushforth wrote: > Please review the following javadoc change: > > https://bugs.openjdk.java.net/browse/JDK-8178015 > http://cr.openjdk.java.net/~kcr/8178015/webrev.00/ > > This restores the links to the Module class that had to be removed > during the transition period for the move of Module and Layer from > java.lang.reflect to java.lang, and makes the requirements for running > an application in a named module more clear. I also fixed a couple > related typos in the modified paragraphs. "Applications in a module": What would you think about changing the heading to "Deploying an Applications as a module" to make it a bit clearer what the section is about? A partial code example might be useful to inline too, it could be as simple as: module foo.app { exports com.foo to javax.graphics; : } -Alan From mp at jugs.org Tue Apr 18 09:22:43 2017 From: mp at jugs.org (Michael Paus) Date: Tue, 18 Apr 2017 11:22:43 +0200 Subject: JavaFX graphics performance In-Reply-To: <41fe263a-3d1d-7967-f3f3-36443b4b9b7e@oracle.com> References: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> <58EBE624.9050009@oracle.com> <41fe263a-3d1d-7967-f3f3-36443b4b9b7e@oracle.com> Message-ID: Hi In https://bugs.openjdk.java.net/browse/JDK-8178804 "Excessive memory consumption in TriangleMesh/MeshView" you wrote: There is a missing divide (by VERTEX_SIZE_VB) when computing the growth of vertexBuffer array as needed. Hence it has the potential of creating a vertexBuffer and some cached data to 9 times as big as designed. However this bug only affect Mesh with VertexFormat.POINT_NORMAL_TEXCOORD. This somehow contradicts your last comment in https://bugs.openjdk.java.net/browse/JDK-8089605 "[3D] TriangleMesh/MeshView high memory/CPU usage" Application should use the new user-defined normals format for dynamic mesh to avoid high memory and CPU usage. I hope the bug fix will also be backported to Java 8. Michael Am 12.04.17 um 22:19 schrieb Chien Yang: > BTW, it is a bug that we are unaware of if you are seeing a 60X > nominal memory consumption in your program. Please file a JIRA with a > test program and we will investigate it. > > Thanks, > > - Chien > > > On 4/10/2017 1:08 PM, Kevin Rushforth wrote: >> We are planning some performance improvements in JDK 10, mostly in >> the areas of CSS and layout. If you have specific concerns in other >> areas we could look into them. Having a specific test case that shows >> a performance problem would be a good start. >> >> -- Kevin >> >> >> Michael Paus wrote: >>> Hi, >>> >>> more and more people ask me why I am still doing GUI development in >>> JavaFX instead >>> of following the mainstream and use some web technology. One of the >>> arguments >>> I could use in the past was performance but nowadays this does not >>> seem to be such >>> a valid argument anymore. Web technologies are catching up quickly >>> and JavaFX currently >>> has not much to offer here. Actually the general drawing performance >>> is very bad compared >>> to what is in principle possible with a modern GPU. I even tried to >>> use a TriangleMesh >>> to better exploit the graphics hardware but this approach is also >>> limited by the fact that >>> a TrinangleMesh has an excessive memory usage (about 60 times its >>> nominal memory >>> consumption). I would therefore like to ask whether there are >>> already any plans for Java 10 >>> to improve this situation? >>> >>> Michael > From nikos132 at gmail.com Tue Apr 18 13:09:34 2017 From: nikos132 at gmail.com (Nikos Nikolos) Date: Tue, 18 Apr 2017 15:09:34 +0200 Subject: JavaFX graphics performance Message-ID: Thanks Mattias for your time on the subject. I share some of your views on Qt and the complexity of data structures to ensure best performance. But the Swing team did open the API to allow JOGL first, now called JOGAMP to propose a nice binding to OpenGL. This way one can use Java Swing and all its good parts to do the non performance critical stuff and go with the low level binding of OpenGL to draw performance intensive stuff. Off course that meant direct buffers, native libraries and the risk to crash the VM, but still staying in the "java realm". I want to be able to reuse long crafted JOGL code in JavaFX but I can't since it doesn't provide OpenGL context directly and using a JOGAMP GLCanvas into a SwingNode is bit blit performance nightmare! Considering a science application displaying 2D or 3D dynamic images with a small amount of I'll rather port my OpenGL code to fully OpenGL ES 3.0 and use web technologies than try to mess with JavaFX. I'm quite disappointed by the fact that JavaFX doesn?t even consider this need as relevant, that?s why I try to argue and understand. I can image that these needs are too specific for the JavaFX team but I see it as a leave for Oracle/Java to stay in the desktop GUI technology. I am a user of Java Swing since 1999, used QT too, and was happy to go on with Java so, once again, it make me sad? Regards. ---------- Message transf?r? ---------- From: Mattias Eliasson To: openjfx-dev at openjdk.java.net Cc: Bcc: Date: Fri, 14 Apr 2017 15:04:20 +0200 Subject: Re: JavaFX graphics performance If what you want is the best performance than neither JavaFX nor web technologies will do. Qt as you mentioned will be much faster and it has native support for embedding OpenGL. In addition you can combine Qt with native optimizations for specific platforms. You can even add inline assembly in order to do very specific optimizations. Hand optimized assembly by a skilled developer will never be outperformed by anything else. The problem with these things of course is that they add a lot of work. Writing Qt code requires you to handle memory and threads and I can constantly see Qt developers failing at this. The VLC UI is written in Qt and it spits out a decent amount of Qt errors on the conseole, and that is probably one of the most well written Qt applications. We have the entire KDE ecosystem based on Qt which is infamous for it's many bugs. And assembly programming of course is a lot more problematic. In order to outperform pre-existing system libraries you sometimes need to know undocumented instructions used by system libraries. This is less of a problem today than it was 20 years ago but it still takes a lot to be good at assembly programming. However this is the JavaFX mailing list so in order to stay on topic I think the discussion should be about how to improve JavaFX performance. Some problems of course are related to the JavaFX code itself, others are rooted in the Java architecture and in JVM memory management. The fact that doing something similar to C/C++ structs and "pragma align" requires ninja level trickery is a problem. I don't know if this is a problem for OpenGL but sometimes when integrating with external systems the lack of "unsigned" is also a real problem, it's probably not a performance problem but writing correct code that deals with data containing unisgned integers can be quite a mess. I don't know OpenGL data structures well enough but in many Internet protocols there are lots of unsigened data to be processed. Also many file formats has that problem. When we are trying to interface Java with low level data such as OpenGL data structures we must recognise that we may need to take these things into consideration for upcoming versions of the JVM. One problem of course are how to deal with these kind of data structures while preserving data integrity and the Java way of doing bounds checking. This is also a big issue I have with the current hacks one have to perform in order to deal with data structures, dealing with large arrays moves the responsibility of data integrity to the application which of course is a breeding ground for bugs. From chien.yang at oracle.com Tue Apr 18 15:44:06 2017 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 18 Apr 2017 08:44:06 -0700 Subject: JavaFX graphics performance In-Reply-To: References: <16702052-4950-b8c2-dc68-d5d9d1e19b3e@jugs.org> <58EBE624.9050009@oracle.com> <41fe263a-3d1d-7967-f3f3-36443b4b9b7e@oracle.com> Message-ID: <58F63446.4020100@oracle.com> Hi Michael, Yes, this is a server bug and a backport to 8u and 9 is also being consider at this moment. Thanks for bringing it to our attention. Thanks, - Chien On 4/18/17, 2:22 AM, Michael Paus wrote: > Hi > > In > https://bugs.openjdk.java.net/browse/JDK-8178804 > "Excessive memory consumption in TriangleMesh/MeshView" > you wrote: > There is a missing divide (by VERTEX_SIZE_VB) when computing the > growth of vertexBuffer array as needed. Hence it has the potential of > creating a vertexBuffer and some cached data to 9 times as big as > designed. However this bug only affect Mesh with > VertexFormat.POINT_NORMAL_TEXCOORD. > > This somehow contradicts your last comment in > https://bugs.openjdk.java.net/browse/JDK-8089605 > "[3D] TriangleMesh/MeshView high memory/CPU usage" > Application should use the new user-defined normals format for dynamic > mesh to avoid high memory and CPU usage. > > I hope the bug fix will also be backported to Java 8. > Michael > > Am 12.04.17 um 22:19 schrieb Chien Yang: >> BTW, it is a bug that we are unaware of if you are seeing a 60X >> nominal memory consumption in your program. Please file a JIRA with >> a test program and we will investigate it. >> >> Thanks, >> >> - Chien >> >> >> On 4/10/2017 1:08 PM, Kevin Rushforth wrote: >>> We are planning some performance improvements in JDK 10, mostly in >>> the areas of CSS and layout. If you have specific concerns in other >>> areas we could look into them. Having a specific test case that >>> shows a performance problem would be a good start. >>> >>> -- Kevin >>> >>> >>> Michael Paus wrote: >>>> Hi, >>>> >>>> more and more people ask me why I am still doing GUI development in >>>> JavaFX instead >>>> of following the mainstream and use some web technology. One of >>>> the arguments >>>> I could use in the past was performance but nowadays this does not >>>> seem to be such >>>> a valid argument anymore. Web technologies are catching up quickly >>>> and JavaFX currently >>>> has not much to offer here. Actually the general drawing >>>> performance is very bad compared >>>> to what is in principle possible with a modern GPU. I even tried to >>>> use a TriangleMesh >>>> to better exploit the graphics hardware but this approach is also >>>> limited by the fact that >>>> a TrinangleMesh has an excessive memory usage (about 60 times its >>>> nominal memory >>>> consumption). I would therefore like to ask whether there are >>>> already any plans for Java 10 >>>> to improve this situation? >>>> >>>> Michael >> > From kevin.rushforth at oracle.com Tue Apr 18 18:19:24 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Apr 2017 11:19:24 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> Message-ID: <58F658AC.5050307@oracle.com> Good suggestion. Here is an updated webrev with Mandy's suggestion and yours: http://cr.openjdk.java.net/~kcr/8178015/webrev.01/ -- Kevin Alan Bateman wrote: > On 18/04/2017 01:00, Kevin Rushforth wrote: > >> Please review the following javadoc change: >> >> https://bugs.openjdk.java.net/browse/JDK-8178015 >> http://cr.openjdk.java.net/~kcr/8178015/webrev.00/ >> >> This restores the links to the Module class that had to be removed >> during the transition period for the move of Module and Layer from >> java.lang.reflect to java.lang, and makes the requirements for >> running an application in a named module more clear. I also fixed a >> couple related typos in the modified paragraphs. > "Applications in a module": What would you think about changing the > heading to "Deploying an Applications as a module" to make it a bit > clearer what the section is about? A partial code example might be > useful to inline too, it could be as simple as: > > module foo.app { > exports com.foo to javax.graphics; > : > } > > -Alan From bourges.laurent at gmail.com Tue Apr 18 19:04:06 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 18 Apr 2017 21:04:06 +0200 Subject: [10] RFR 8170024: PiscesRenderer.pr.emitAndClearAlphaRow cannot accept a pix_x_from parameter greater than clip.xmin Message-ID: Please review this performance enhancement for OpenJFX 10 / Marlin: JBS: https://bugs.openjdk.java.net/browse/JDK-8170024 webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-8170024.0/ The performance impact is small but may be more important for large shapes (left-side is 'empty) but anyway this patch only impacts the SW pipeline. Changes: - added a new method parameter pix_x_off to PiscesRenderer.emitAndClearAlphaRow() giving the offset (in pixels) within the alpha row + bound checks (for consistency) - *modified JPiscesRenderer to alter the initial alpha buffer pointer; the C blit functions seems to support well the 'trick'* *- use the new parameter in SWContext to make MarlinFX only process the alphaRow in the range [pix_from; pix_to[ (as initially made for)* Cheers, Laurent From Alan.Bateman at oracle.com Tue Apr 18 19:45:33 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 18 Apr 2017 20:45:33 +0100 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58F658AC.5050307@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> Message-ID: <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> On 18/04/2017 19:19, Kevin Rushforth wrote: > Good suggestion. Here is an updated webrev with Mandy's suggestion and > yours: > > http://cr.openjdk.java.net/~kcr/8178015/webrev.01/ > > -- Kevin This looks mostly okay. I guess for FXML then I assume that the annotated member could be public, in which case the package just needs to be exported (no need to open). -Alan From kevin.rushforth at oracle.com Tue Apr 18 19:48:22 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Apr 2017 12:48:22 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> Message-ID: <58F66D86.3050103@oracle.com> Alan Bateman wrote: > > > On 18/04/2017 19:19, Kevin Rushforth wrote: >> Good suggestion. Here is an updated webrev with Mandy's suggestion >> and yours: >> >> http://cr.openjdk.java.net/~kcr/8178015/webrev.01/ >> >> -- Kevin > This looks mostly okay. > > I guess for FXML then I assume that the annotated member could be > public, in which case the package just needs to be exported (no need > to open). Yes, it could be, but the more typical use of the annotation is on non-public members, so that was why I chose that as the example. -- Kevin > > -Alan From kevin.rushforth at oracle.com Tue Apr 18 19:51:16 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Apr 2017 12:51:16 -0700 Subject: Changes for April 2017 CPU release (8u131) synced into FX 8u-dev and 9-dev Message-ID: <58F66E34.9000705@oracle.com> I have synced the OpenJFX changes from the just-released April 2017 CPU release (8u131) into 8u and into 9. I have further synced all changes from 9 into 10. Here is a webrev of the FX 8u131 changes for those who are interested in the changes, but don't want to wade through the separate changesets I just pushed (most of which are tag or merge changesets). http://cr.openjdk.java.net/~kcr/8u131-8u-sync/webrev/ The webrev for 9 is similar except for the .hgtags (which are unmodified in 9), but here it is if anyone is interested: http://cr.openjdk.java.net/~kcr/9-cpu-1702-sync/webrev/ -- Kevin From mandy.chung at oracle.com Tue Apr 18 20:07:51 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 18 Apr 2017 13:07:51 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58F66D86.3050103@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> Message-ID: <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> > On Apr 18, 2017, at 12:48 PM, Kevin Rushforth wrote: > > > > Alan Bateman wrote: >> >> >> On 18/04/2017 19:19, Kevin Rushforth wrote: >>> Good suggestion. Here is an updated webrev with Mandy's suggestion and yours: >>> >>> http://cr.openjdk.java.net/~kcr/8178015/webrev.01/ >>> >>> -- Kevin >> This looks mostly okay. >> >> I guess for FXML then I assume that the annotated member could be public, in which case the package just needs to be exported (no need to open). > > Yes, it could be, but the more typical use of the annotation is on non-public members, so that was why I chose that as the example. I have the same comment as Alan. The example in the javadoc may be perceived as a recommendation. We should probably recommend the annotated member be moved to public and encapsulated in its module, just exports it to javafx.fxml to use. Mandy From kevin.rushforth at oracle.com Tue Apr 18 20:25:46 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Apr 2017 13:25:46 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> Message-ID: <58F6764A.8020106@oracle.com> Mandy Chung wrote: >> On Apr 18, 2017, at 12:48 PM, Kevin Rushforth wrote: >> >> >> >> Alan Bateman wrote: >> >>> On 18/04/2017 19:19, Kevin Rushforth wrote: >>> >>>> Good suggestion. Here is an updated webrev with Mandy's suggestion and yours: >>>> >>>> http://cr.openjdk.java.net/~kcr/8178015/webrev.01/ >>>> >>>> -- Kevin >>>> >>> This looks mostly okay. >>> >>> I guess for FXML then I assume that the annotated member could be public, in which case the package just needs to be exported (no need to open). >>> >> Yes, it could be, but the more typical use of the annotation is on non-public members, so that was why I chose that as the example. >> > > I have the same comment as Alan. The example in the javadoc may be perceived as a recommendation. We should probably recommend the annotated member be moved to public and encapsulated in its module, just exports it to javafx.fxml to use. > For the use of the FXML annotation, that is exactly the recommendation. If you want the FXMLLoader to modify a public member in a public class, you don't need the annotation at all (although I guess it can still be used as useful documentation). In the longer "Introduction to FXML" doc, which is included with the API docs and linked from the javafx.fxml package description, the only examples we give of using the @FXML annotation are for non-public members. See: http://download.java.net/java/jdk9/jfxdocs/javafx/fxml/doc-files/introduction_to_fxml.html#fxml_annotation Specifically, the description of the FXML annotation says: However, for developers who prefer more restricted visibility for controller fields or handler methods, the javafx.fxml.FXML annotation can be used. This annotation marks a protected or private class member as accessible to FXML. For consistency, it seems best to show the example in the FXML javadocs as an example of using "opens" since that is what would be needed for the typical use case, such as those we document elsewhere. -- Kevin > Mandy From David.Hill at Oracle.com Tue Apr 18 20:47:02 2017 From: David.Hill at Oracle.com (David Hill) Date: Tue, 18 Apr 2017 16:47:02 -0400 Subject: Review: Remove Lens code (finally) Message-ID: <58F67B46.7040602@Oracle.com> Here is the change to remove the Lens code. caviots: There were some minor gradle fixes required to cross build. I removed all of the arm*gradle files except for armv6hf. Arm is not a supported platform anymore and by reducing to the most likely to be used (because of the Pi), I can concentrate what few resources I can to checking that platform still builds. Armv6hf builds cleanly. I don't have a working Pi configuration to test it, and need to figure out building the JDK for ARM before I really can test it even then. We have not been using Lens for JDK 8,9 so this should be safe. https://bugs.openjdk.java.net/browse/JDK-8090969 webrev: http://cr.openjdk.java.net/~ddhill/8090969 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From james.graham at oracle.com Tue Apr 18 21:07:40 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 18 Apr 2017 14:07:40 -0700 Subject: [10] Review request: 8178521 Severe performance drop for path rendering Message-ID: <3c8cbf31-3d7a-60eb-d74f-62d319818b96@oracle.com> Review history already in JBS: https://bugs.openjdk.java.net/browse/JDK-8178521 final webrev: http://cr.openjdk.java.net/~flar/JDK-8178521/webrev.02/ This should be considered for a backport to 9 as well... ...jim From kevin.rushforth at oracle.com Tue Apr 18 23:00:29 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 18 Apr 2017 16:00:29 -0700 Subject: [9] Review request: 8178329: Update minimum boot JDK to jdk-9+165 Message-ID: <58F69A8D.4070602@oracle.com> Please review the following to bump the minimum build number of the boot JDK used to build FX 9 to 165 [1]. https://bugs.openjdk.java.net/browse/JDK-8178329 http://cr.openjdk.java.net/~kcr/8178329/webrev.00/ I'll wait until tomorrow afternoon to push this, if the review is done by then. Thanks. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-April/020444.html From johan at lodgon.com Wed Apr 19 07:55:18 2017 From: johan at lodgon.com (Johan Vos) Date: Wed, 19 Apr 2017 07:55:18 +0000 Subject: Review: Remove Lens code (finally) In-Reply-To: <58F67B46.7040602@Oracle.com> References: <58F67B46.7040602@Oracle.com> Message-ID: Hi David, The JavaFX for embedded Armv6hf we build with Gluon uses Monocle. I have a version built with X11 ready as well. But I agree Lens can safely be removed. - Johan Op di 18 apr. 2017 om 22:48 schreef David Hill : > > Here is the change to remove the Lens code. > > caviots: > There were some minor gradle fixes required to cross build. > > I removed all of the arm*gradle files except for armv6hf. Arm is not a > supported platform anymore and by reducing to the most likely to be used > (because of the Pi), I can concentrate what few resources I can to checking > that platform still builds. > > Armv6hf builds cleanly. I don't have a working Pi configuration to > test it, and need to figure out building the JDK for ARM before I really > can test it even then. > > We have not been using Lens for JDK 8,9 so this should be safe. > > https://bugs.openjdk.java.net/browse/JDK-8090969 > webrev: http://cr.openjdk.java.net/~ddhill/8090969 > > -- > David Hill > Java Embedded Development > > "A man's feet should be planted in his country, but his eyes should survey > the world." > -- George Santayana (1863 - 1952) > > From cnewland at chrisnewland.com Wed Apr 19 08:56:37 2017 From: cnewland at chrisnewland.com (Chris Newland) Date: Wed, 19 Apr 2017 09:56:37 +0100 Subject: Review: Remove Lens code (finally) In-Reply-To: <58F67B46.7040602@Oracle.com> References: <58F67B46.7040602@Oracle.com> Message-ID: <4db065182c21cc233beb378f7435618d.squirrel@excalibur.xssl.net> Thanks for the heads-up David. I've checked my chriswhocodes.com web server logs and around 90 unique IPs per week are still downloading the ARM OpenJFX overlay builds so before this patch is merged I'll take a snapshot of the last working ARM build and keep that available. Kind regards, Chris On Tue, April 18, 2017 21:47, David Hill wrote: > > Here is the change to remove the Lens code. > > > caviots: > There were some minor gradle fixes required to cross build. > > > I removed all of the arm*gradle files except for armv6hf. Arm is not a > supported platform anymore and by reducing to the most likely to be used > (because of the Pi), I can concentrate what few resources I can to > checking that platform still builds. > > Armv6hf builds cleanly. I don't have a working Pi configuration to test > it, and need to figure out building the JDK for ARM before I really can > test it even then. > > We have not been using Lens for JDK 8,9 so this should be safe. > > > https://bugs.openjdk.java.net/browse/JDK-8090969 > webrev: http://cr.openjdk.java.net/~ddhill/8090969 > > > -- > David Hill > Java Embedded Development > > > "A man's feet should be planted in his country, but his eyes should > survey the world." -- George Santayana (1863 - 1952) > > > From kevin.rushforth at oracle.com Wed Apr 19 11:59:44 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Apr 2017 04:59:44 -0700 Subject: Review: Remove Lens code (finally) In-Reply-To: <4db065182c21cc233beb378f7435618d.squirrel@excalibur.xssl.net> References: <58F67B46.7040602@Oracle.com> <4db065182c21cc233beb378f7435618d.squirrel@excalibur.xssl.net> Message-ID: <58F75130.1040308@oracle.com> As a note, once the review is completed this will only go into OpenJFX 10. It will not be backported to 9 or 8. -- Kevin Chris Newland wrote: > Thanks for the heads-up David. > > I've checked my chriswhocodes.com web server logs and around 90 unique IPs > per week are still downloading the ARM OpenJFX overlay builds so before > this patch is merged I'll take a snapshot of the last working ARM build > and keep that available. > > Kind regards, > > Chris > > On Tue, April 18, 2017 21:47, David Hill wrote: > > > >> Here is the change to remove the Lens code. >> >> >> caviots: >> There were some minor gradle fixes required to cross build. >> >> >> I removed all of the arm*gradle files except for armv6hf. Arm is not a >> supported platform anymore and by reducing to the most likely to be used >> (because of the Pi), I can concentrate what few resources I can to >> checking that platform still builds. >> >> Armv6hf builds cleanly. I don't have a working Pi configuration to test >> it, and need to figure out building the JDK for ARM before I really can >> test it even then. >> >> We have not been using Lens for JDK 8,9 so this should be safe. >> >> >> https://bugs.openjdk.java.net/browse/JDK-8090969 >> webrev: http://cr.openjdk.java.net/~ddhill/8090969 >> >> >> -- >> David Hill >> Java Embedded Development >> >> >> "A man's feet should be planted in his country, but his eyes should >> survey the world." -- George Santayana (1863 - 1952) >> >> >> >> > > From chien.yang at oracle.com Wed Apr 19 16:16:01 2017 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 19 Apr 2017 09:16:01 -0700 Subject: [9] Code Review Request For 8178804: Excessive memory consumption in TriangleMesh/MeshView Message-ID: <58F78D41.70700@oracle.com> Hi Kevin, Please review the proposed fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8178804 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8178804/webrev.00/ Thanks, - Chien From kevin.rushforth at oracle.com Wed Apr 19 18:43:36 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 19 Apr 2017 11:43:36 -0700 Subject: [9] Review request: 8091730: Enable -Xdoclint:all to treat all javadoc warnings as errors Message-ID: <58F7AFD8.7040206@oracle.com> Please review the following to enable building the FX docs with "javadoc -Xdoclint:all". https://bugs.openjdk.java.net/browse/JDK-8091730 http://cr.openjdk.java.net/~kcr/8091730/webrev.00/ This will allow to catch doc warnings early before delivering them to the JDK 9 build, and will allow the unified JDK javadoc build to use -Xdoclint for javafx.* modules. -- Kevin From chien.yang at oracle.com Thu Apr 20 01:35:23 2017 From: chien.yang at oracle.com (Chien Yang) Date: Wed, 19 Apr 2017 18:35:23 -0700 Subject: [10] Code Review Request For 8178837: Potential performance drawback due to type mismatch Message-ID: <58F8105B.2080901@oracle.com> Hi Kevin, Please review the proposed fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8178837 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8178837/webrev.00/ Thanks, - Chien From bourges.laurent at gmail.com Thu Apr 20 06:35:09 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 20 Apr 2017 08:35:09 +0200 Subject: MarlinFX upgrade 0.7.5 Message-ID: Hi, Please review this MarlinFX upgrade to Marlin 0.7.5: JBS: no bug yet for OpenJFX 10 webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.0/ Changes: - Renderers: fixed block processing - dead code & few comment removals in Strokers - fixed all floating-point number literals to be x.0f or x.0d to simplify the conversion between float & double variants PS: I plan to run later FindBugs, Netbeans & IntelliJ code analysis tools to fix any warning Cheers, Laurent From kevin.rushforth at oracle.com Thu Apr 20 18:06:04 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Apr 2017 11:06:04 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58F6764A.8020106@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> <58F6764A.8020106@oracle.com> Message-ID: <58F8F88C.7000303@oracle.com> Here is an updated webrev with a few suggested wording changes (e.g., removed the reference to ModuleDescriptor, changed "accessible by" back to "accessible to"). http://cr.openjdk.java.net/~kcr/8178015/webrev.02/ Additionally, I removed the example in the FXML annotation showing the use of "opens to" in module-info.java (but left the example in Application). -- Kevin Kevin Rushforth wrote: > > > Mandy Chung wrote: >>> On Apr 18, 2017, at 12:48 PM, Kevin Rushforth >>> wrote: >>> >>> >>> >>> Alan Bateman wrote: >>> >>>> On 18/04/2017 19:19, Kevin Rushforth wrote: >>>> >>>>> Good suggestion. Here is an updated webrev with Mandy's suggestion >>>>> and yours: >>>>> >>>>> http://cr.openjdk.java.net/~kcr/8178015/webrev.01/ >>>>> >>>>> -- Kevin >>>>> >>>> This looks mostly okay. >>>> >>>> I guess for FXML then I assume that the annotated member could be >>>> public, in which case the package just needs to be exported (no >>>> need to open). >>>> >>> Yes, it could be, but the more typical use of the annotation is on >>> non-public members, so that was why I chose that as the example. >>> >> >> I have the same comment as Alan. The example in the javadoc may be >> perceived as a recommendation. We should probably recommend the >> annotated member be moved to public and encapsulated in its module, >> just exports it to javafx.fxml to use. > > For the use of the FXML annotation, that is exactly the > recommendation. If you want the FXMLLoader to modify a public member > in a public class, you don't need the annotation at all (although I > guess it can still be used as useful documentation). > > In the longer "Introduction to FXML" doc, which is included with the > API docs and linked from the javafx.fxml package description, the only > examples we give of using the @FXML annotation are for non-public > members. See: > > http://download.java.net/java/jdk9/jfxdocs/javafx/fxml/doc-files/introduction_to_fxml.html#fxml_annotation > > > Specifically, the description of the FXML annotation says: > > However, for developers who prefer more restricted visibility for > controller fields or handler methods, the javafx.fxml.FXML > annotation can be used. This annotation marks a protected or private > class member as accessible to FXML. > > > For consistency, it seems best to show the example in the FXML > javadocs as an example of using "opens" since that is what would be > needed for the typical use case, such as those we document elsewhere. > > -- Kevin > > >> Mandy From mandy.chung at oracle.com Thu Apr 20 19:00:15 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Apr 2017 12:00:15 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58F8F88C.7000303@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> <58F6764A.8020106@oracle.com> <58F8F88C.7000303@oracle.com> Message-ID: <644458CA-87A6-4C8C-A23C-D6467DBFD94A@oracle.com> +1 Mandy > On Apr 20, 2017, at 11:06 AM, Kevin Rushforth wrote: > > Here is an updated webrev with a few suggested wording changes (e.g., removed the reference to ModuleDescriptor, changed "accessible by" back to "accessible to"). > > http://cr.openjdk.java.net/~kcr/8178015/webrev.02/ > > Additionally, I removed the example in the FXML annotation showing the use of "opens to" in module-info.java (but left the example in Application). > > -- Kevin > > > Kevin Rushforth wrote: >> >> >> Mandy Chung wrote: >>>> On Apr 18, 2017, at 12:48 PM, Kevin Rushforth wrote: >>>> >>>> >>>> >>>> Alan Bateman wrote: >>>> >>>>> On 18/04/2017 19:19, Kevin Rushforth wrote: >>>>> >>>>>> Good suggestion. Here is an updated webrev with Mandy's suggestion and yours: >>>>>> >>>>>> http://cr.openjdk.java.net/~kcr/8178015/webrev.01/ >>>>>> >>>>>> -- Kevin >>>>>> >>>>> This looks mostly okay. >>>>> >>>>> I guess for FXML then I assume that the annotated member could be public, in which case the package just needs to be exported (no need to open). >>>>> >>>> Yes, it could be, but the more typical use of the annotation is on non-public members, so that was why I chose that as the example. >>>> >>> >>> I have the same comment as Alan. The example in the javadoc may be perceived as a recommendation. We should probably recommend the annotated member be moved to public and encapsulated in its module, just exports it to javafx.fxml to use. >> >> For the use of the FXML annotation, that is exactly the recommendation. If you want the FXMLLoader to modify a public member in a public class, you don't need the annotation at all (although I guess it can still be used as useful documentation). >> >> In the longer "Introduction to FXML" doc, which is included with the API docs and linked from the javafx.fxml package description, the only examples we give of using the @FXML annotation are for non-public members. See: >> >> http://download.java.net/java/jdk9/jfxdocs/javafx/fxml/doc-files/introduction_to_fxml.html#fxml_annotation >> >> Specifically, the description of the FXML annotation says: >> >> However, for developers who prefer more restricted visibility for >> controller fields or handler methods, the javafx.fxml.FXML >> annotation can be used. This annotation marks a protected or private >> class member as accessible to FXML. >> >> >> For consistency, it seems best to show the example in the FXML javadocs as an example of using "opens" since that is what would be needed for the typical use case, such as those we document elsewhere. >> >> -- Kevin >> >> >>> Mandy From adam at adamish.com Fri Apr 21 06:19:16 2017 From: adam at adamish.com (adam at adamish.com) Date: Thu, 20 Apr 2017 23:19:16 -0700 Subject: Exceptions silently swallowed in DnD listeners, windows only Message-ID: <878e5e0988f7aaa5ef272b2358aa65dc85fc94e5@webmail.adamish.com> Exceptions silently swallowed in DnD listeners... but only on Windows, and even in latest 1.8u121 release... This appears to be a bug?? I've written up here http://stackoverflow.com/questions/43488321/javafx-silently-swallowing-exception-raised-in-drag-listeners/43535229#43535229 Short version.... if you have a handler that throws an exception, then this is silently swallowed, nothing seen in console... destination . setOnDragOver ( new EventHandler < DragEvent >() { public void handle ( DragEvent event ) { event . acceptTransferModes ( TransferMode . LINK ); String nullReference = null ; nullReference . toCharArray (); // cause an exception event . consume (); } }); My investigation so far.... It appears that native method WinDnDClipboard.push(Object[], int) - backed by GlassClipboard.cpp [1] swallows the exception silently. A call back to Throwable.getMessage() can be seen in the debugger but no exception is printed to the console. The Java 9 version of this file (http://hg.openjdk.java.net/openjfx/9-dev/rt/file/1a3f128518cd/modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp [2]) has an additional call to CheckAndClearException(env); as defined in Utils.cpp, however this is against RT-35400 which appears unrelated. This has not been backported to Java 8. Thanks, Adam Links: ------ [1] http://hg.openjdk.java.net/openjfx/8/master/rt/file/tip/modules/graphics/src/main/native-glass/win/GlassClipboard.cpp [2] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/1a3f128518cd/modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp From dipak.kumar at oracle.com Fri Apr 21 06:33:27 2017 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Thu, 20 Apr 2017 23:33:27 -0700 (PDT) Subject: [10] Code Review Request For 8133337: [Linux] Pasting HTML from Firefox does not work Message-ID: Hi Kevin, Please review the proposed fix. JBS: https://bugs.openjdk.java.net/browse/JDK-8133337 Webrev: http://cr.openjdk.java.net/~asrivastava/dipak/8133337/webrev.00/ Root cause and solution updated in JBS. Thanks, Dipak From Alan.Bateman at oracle.com Fri Apr 21 08:09:01 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Apr 2017 09:09:01 +0100 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58F8F88C.7000303@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> <58F6764A.8020106@oracle.com> <58F8F88C.7000303@oracle.com> Message-ID: On 20/04/2017 19:06, Kevin Rushforth wrote: > Here is an updated webrev with a few suggested wording changes (e.g., > removed the reference to ModuleDescriptor, changed "accessible by" > back to "accessible to"). > > http://cr.openjdk.java.net/~kcr/8178015/webrev.02/ > > Additionally, I removed the example in the FXML annotation showing the > use of "opens to" in module-info.java (but left the example in > Application). > What would you think about dropping the "Alternative the module can open ...." from the Application javadoc. I say this because it could confuse the reader. An advanced developer may follow the link to isExported and read more but it seems a bit much to try to put in the Application javadoc. FXML looks good. -Alan From kevin.rushforth at oracle.com Fri Apr 21 12:06:30 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Apr 2017 05:06:30 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> <58F6764A.8020106@oracle.com> <58F8F88C.7000303@oracle.com> Message-ID: <58F9F5C6.8070501@oracle.com> Alan Bateman wrote: > > > On 20/04/2017 19:06, Kevin Rushforth wrote: >> Here is an updated webrev with a few suggested wording changes (e.g., >> removed the reference to ModuleDescriptor, changed "accessible by" >> back to "accessible to"). >> >> http://cr.openjdk.java.net/~kcr/8178015/webrev.02/ >> >> Additionally, I removed the example in the FXML annotation showing >> the use of "opens to" in module-info.java (but left the example in >> Application). >> > What would you think about dropping the "Alternative the module can > open ...." from the Application javadoc. I say this because it could > confuse the reader. An advanced developer may follow the link to > isExported and read more but it seems a bit much to try to put in the > Application javadoc. That seems good to me. I will remove it before pushing. -- Kevin > > FXML looks good. > > -Alan From jmartine_1026 at yahoo.com Fri Apr 21 12:13:31 2017 From: jmartine_1026 at yahoo.com (Jose Martinez) Date: Fri, 21 Apr 2017 12:13:31 +0000 (UTC) Subject: consider setInput/getInput as method in Effect References: <1609612972.5814367.1492776811208.ref@mail.yahoo.com> Message-ID: <1609612972.5814367.1492776811208@mail.yahoo.com> Hello, Shouldn't the setInput/getInput method be part of the Effect abstract class?? Even if its just there as an abstract method with no default implementation. I cannot do simple things like this (not that this is simple, but simpler than the alternative): private void addNewEffect(Node node, Effect myNewEffect) {????Effect effect =?node.getEffect();????if (effect != null) {????????while (effect.getInput() != null) {????????????effect = effect.getInput();????????}????????effect.setInput(myNewEffect);????} else {??????? node.setEffect(myNewEffect);????}} Instead I find myself write code like this (and this would not scale well): ??? //this works because the two Effects below have been declared as DropShadow and ColorAdjust ??? private void refreshEffects() { ??????? if (destroyed && selected) { ??????????? selectedEffect.setInput(destroyedEffect); ??????????? imageView.setEffect(selectedEffect); ??????? } else if (!destroyed && selected) { ??????????? selectedEffect.setInput(null); ??????????? imageView.setEffect(selectedEffect); ??????? } else if (destroyed && !selected) { ??????????? destroyedEffect.setInput(null); ??????????? imageView.setEffect(destroyedEffect); ??????? } else if (!destroyed && !selected) { ??????????? imageView.setEffect(null); ??????? } ??? } Case in point:? http://stackoverflow.com/a/32020458/1490322 Maybe there is a good reason for not having setInput/getInput in Effect, as I suspect there is, in that case, sorry for the email (I tried searching for the reason).? One concern might be that some Effects just cannot play well with others.? In that case may I suggest another method in Effect called isChainable().? No matter what is done I can definitely see that this is not easy and can appreciate that some compromises have been made that lead to setInput/getInput not being in Effect. thanksjose From james.graham at oracle.com Fri Apr 21 18:05:34 2017 From: james.graham at oracle.com (Jim Graham) Date: Fri, 21 Apr 2017 11:05:34 -0700 Subject: consider setInput/getInput as method in Effect In-Reply-To: <1609612972.5814367.1492776811208@mail.yahoo.com> References: <1609612972.5814367.1492776811208.ref@mail.yahoo.com> <1609612972.5814367.1492776811208@mail.yahoo.com> Message-ID: <78998bdb-be38-494c-12aa-90d4669a7671@oracle.com> Some effects have multiple inputs and have no single bare getInput/setInput methods and ColorInput has no input at all... ...jim On 4/21/17 5:13 AM, Jose Martinez wrote: > Hello, > Shouldn't the setInput/getInput method be part of the Effect abstract class? Even if its just there as an abstract method with no default implementation. > I cannot do simple things like this (not that this is simple, but simpler than the alternative): > private void addNewEffect(Node node, Effect myNewEffect) { Effect effect = node.getEffect(); if (effect != null) { while (effect.getInput() != null) { effect = effect.getInput(); } effect.setInput(myNewEffect); } else { node.setEffect(myNewEffect); }} > > Instead I find myself write code like this (and this would not scale well): > //this works because the two Effects below have been declared as DropShadow and ColorAdjust > private void refreshEffects() { > if (destroyed && selected) { > selectedEffect.setInput(destroyedEffect); > imageView.setEffect(selectedEffect); > } else if (!destroyed && selected) { > selectedEffect.setInput(null); > imageView.setEffect(selectedEffect); > } else if (destroyed && !selected) { > destroyedEffect.setInput(null); > imageView.setEffect(destroyedEffect); > } else if (!destroyed && !selected) { > imageView.setEffect(null); > } > } > > Case in point: http://stackoverflow.com/a/32020458/1490322 > Maybe there is a good reason for not having setInput/getInput in Effect, as I suspect there is, in that case, sorry for the email (I tried searching for the reason). One concern might be that some Effects just cannot play well with others. In that case may I suggest another method in Effect called isChainable(). No matter what is done I can definitely see that this is not easy and can appreciate that some compromises have been made that lead to setInput/getInput not being in Effect. > thanksjose > From kevin.rushforth at oracle.com Fri Apr 21 22:58:28 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Apr 2017 15:58:28 -0700 Subject: [9] Review request: 8178989: Missing copyright headers for some files Message-ID: <58FA8E94.4020906@oracle.com> Hi Chien, Please review this simple fix to add missing copyright headers to 7 files: https://bugs.openjdk.java.net/browse/JDK-8178989 http://cr.openjdk.java.net/~kcr/8178989/webrev.00/ Thanks. -- Kevin From kevin.rushforth at oracle.com Fri Apr 21 23:08:51 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Apr 2017 16:08:51 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58FA8F7D.7040001@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> <58F6764A.8020106@oracle.com> <58F8F88C.7000303@oracle.com> <58FA8F7D.7040001@oracle.com> Message-ID: <58FA9103.6090500@oracle.com> OK, so you recommend changing module-info.class to module-info.java and removing the reference to Module#addExports entirely, right? I can fix this as part of a general cleanup JBS issue [1] that is left open to pick up various typos, etc. Would you recommend the same for the FXML annotation, and not refer them to Module#addOpens? -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8177341 Alex Buckley wrote: > On 4/20/2017 11:06 AM, Kevin Rushforth wrote: >> Additionally, I removed the example in the FXML annotation showing the >> use of "opens to" in module-info.java (but left the example in >> Application). > > Similar to my private comments to you on a related matter: > > Recommend straightforwardness: "... the module must export (or open) > the containing package to at least the javafx.graphics module. [NEW > PARAGRAPH] For example, ..." > > I don't get the desire to always rotate towards module-info._class_ > and Module#addExports when the focus should be on ordinary source code. > > Alex From alex.buckley at oracle.com Fri Apr 21 23:02:21 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 21 Apr 2017 16:02:21 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58F8F88C.7000303@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> <58F6764A.8020106@oracle.com> <58F8F88C.7000303@oracle.com> Message-ID: <58FA8F7D.7040001@oracle.com> On 4/20/2017 11:06 AM, Kevin Rushforth wrote: > Additionally, I removed the example in the FXML annotation showing the > use of "opens to" in module-info.java (but left the example in > Application). Similar to my private comments to you on a related matter: Recommend straightforwardness: "... the module must export (or open) the containing package to at least the javafx.graphics module. [NEW PARAGRAPH] For example, ..." I don't get the desire to always rotate towards module-info._class_ and Module#addExports when the focus should be on ordinary source code. Alex From alex.buckley at oracle.com Fri Apr 21 23:11:01 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Fri, 21 Apr 2017 16:11:01 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58FA9103.6090500@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> <58F6764A.8020106@oracle.com> <58F8F88C.7000303@oracle.com> <58FA8F7D.7040001@oracle.com> <58FA9103.6090500@oracle.com> Message-ID: <58FA9185.1040307@oracle.com> Yes, I recommend not pointing ordinary consumers of JavaFX to java.lang.reflect.Module::add* methods. If open-ness is ever mentioned (and as you know, I do like it to be acknowledged), then it can be parenthetical. Alex On 4/21/2017 4:08 PM, Kevin Rushforth wrote: > OK, so you recommend changing module-info.class to module-info.java and > removing the reference to Module#addExports entirely, right? I can fix > this as part of a general cleanup JBS issue [1] that is left open to > pick up various typos, etc. > > Would you recommend the same for the FXML annotation, and not refer them > to Module#addOpens? > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8177341 > > > Alex Buckley wrote: >> On 4/20/2017 11:06 AM, Kevin Rushforth wrote: >>> Additionally, I removed the example in the FXML annotation showing the >>> use of "opens to" in module-info.java (but left the example in >>> Application). >> >> Similar to my private comments to you on a related matter: >> >> Recommend straightforwardness: "... the module must export (or open) >> the containing package to at least the javafx.graphics module. [NEW >> PARAGRAPH] For example, ..." >> >> I don't get the desire to always rotate towards module-info._class_ >> and Module#addExports when the focus should be on ordinary source code. >> >> Alex From kevin.rushforth at oracle.com Fri Apr 21 23:14:37 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 21 Apr 2017 16:14:37 -0700 Subject: [9] Review request: 8178015: Clarify requirement for app modules to export/open packages to javafx modules In-Reply-To: <58FA9185.1040307@oracle.com> References: <58F55713.80602@oracle.com> <3e7f468b-f03f-d196-8a2e-c32a9a4ad59d@oracle.com> <58F658AC.5050307@oracle.com> <90b3b21a-aa52-fd1a-7409-084dfd20c20c@oracle.com> <58F66D86.3050103@oracle.com> <87069E77-768A-4030-8F2B-36B79C2A2CEC@oracle.com> <58F6764A.8020106@oracle.com> <58F8F88C.7000303@oracle.com> <58FA8F7D.7040001@oracle.com> <58FA9103.6090500@oracle.com> <58FA9185.1040307@oracle.com> Message-ID: <58FA925D.2060903@oracle.com> OK. I'll make that change as part of JDK-8177341. -- Kevin Alex Buckley wrote: > Yes, I recommend not pointing ordinary consumers of JavaFX to > java.lang.reflect.Module::add* methods. If open-ness is ever mentioned > (and as you know, I do like it to be acknowledged), then it can be > parenthetical. > > Alex > > On 4/21/2017 4:08 PM, Kevin Rushforth wrote: >> OK, so you recommend changing module-info.class to module-info.java and >> removing the reference to Module#addExports entirely, right? I can fix >> this as part of a general cleanup JBS issue [1] that is left open to >> pick up various typos, etc. >> >> Would you recommend the same for the FXML annotation, and not refer them >> to Module#addOpens? >> >> -- Kevin >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8177341 >> >> >> Alex Buckley wrote: >>> On 4/20/2017 11:06 AM, Kevin Rushforth wrote: >>>> Additionally, I removed the example in the FXML annotation showing the >>>> use of "opens to" in module-info.java (but left the example in >>>> Application). >>> >>> Similar to my private comments to you on a related matter: >>> >>> Recommend straightforwardness: "... the module must export (or open) >>> the containing package to at least the javafx.graphics module. [NEW >>> PARAGRAPH] For example, ..." >>> >>> I don't get the desire to always rotate towards module-info._class_ >>> and Module#addExports when the focus should be on ordinary source code. >>> >>> Alex From javalists at cbfiddle.com Tue Apr 11 17:43:38 2017 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 11 Apr 2017 10:43:38 -0700 Subject: javapackager - partially self-contained apps in JDK 9 Message-ID: <7D269037-9A1F-40C1-9F9C-0E72D5CAC1DE@cbfiddle.com> I have run into a problem in moving my macOS apps from JDK 8 to 9. The issue relates to using MySQL via JDBC. The connector class name is fixed. The class is loaded using Class.forName(). However, there can be different versions of the connector in different JAR files, and the proper version might need to be synced with the currently installed version of MySQL. In JDK 8, I used the extension mechanism to load the MySQL connector JAR rather than building this JAR into the bundled app. My thinking was that the connector might need to be updated in sync with the database and I should not have to rebuild apps to do that. In JDK 9, the extension mechanism is gone. I have not found any way to achieve the equivalent effect. It seems that javapackager controls the setting of the CLASSPATH. I have not found an option that would allow me to extend the CLASSPATH with a directory where the connector JAR could be found. Is there a way to do this? Alan From swpalmer at gmail.com Tue Apr 25 17:55:48 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 25 Apr 2017 13:55:48 -0400 Subject: javapackager - partially self-contained apps in JDK 9 In-Reply-To: <7D269037-9A1F-40C1-9F9C-0E72D5CAC1DE@cbfiddle.com> References: <7D269037-9A1F-40C1-9F9C-0E72D5CAC1DE@cbfiddle.com> Message-ID: <4EBD5914-3B1F-4790-96D6-A72AB0872439@gmail.com> > On Apr 11, 2017, at 1:43 PM, Alan Snyder wrote: > > I have run into a problem in moving my macOS apps from JDK 8 to 9. The issue relates to using MySQL via JDBC. > The connector class name is fixed. The class is loaded using Class.forName(). However, there can be different versions > of the connector in different JAR files, and the proper version might need to be synced with the currently installed version > of MySQL. > > In JDK 8, I used the extension mechanism to load the MySQL connector JAR rather than building this JAR into the bundled app. > My thinking was that the connector might need to be updated in sync with the database and I should not have to rebuild apps to do that. > > In JDK 9, the extension mechanism is gone. I have not found any way to achieve the equivalent effect. It seems that javapackager > controls the setting of the CLASSPATH. I have not found an option that would allow me to extend the CLASSPATH with a directory > where the connector JAR could be found. Is there a way to do this? My application ran into classpath issues because it tried to dynamically add plugins to the classpath and that broke on Java 9. To work around it I created an agent so I could get access to the java.lang.Instrumentation interface to add to the classpath. You might try that approach. It?s ugly, but better than reflectively accessing private fields of URLClassLoader, which doesn?t work for Java 9 :-) Scott From chris.bensen at oracle.com Tue Apr 25 18:32:26 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 25 Apr 2017 11:32:26 -0700 Subject: javapackager - partially self-contained apps in JDK 9 In-Reply-To: <7D269037-9A1F-40C1-9F9C-0E72D5CAC1DE@cbfiddle.com> References: <7D269037-9A1F-40C1-9F9C-0E72D5CAC1DE@cbfiddle.com> Message-ID: <6BED262A-AB73-4703-88D5-A4C6AA19443C@oracle.com> > On Apr 11, 2017, at 10:43 AM, Alan Snyder wrote: > > I have run into a problem in moving my macOS apps from JDK 8 to 9. The issue relates to using MySQL via JDBC. > The connector class name is fixed. The class is loaded using Class.forName(). However, there can be different versions > of the connector in different JAR files, and the proper version might need to be synced with the currently installed version > of MySQL. > > In JDK 8, I used the extension mechanism to load the MySQL connector JAR rather than building this JAR into the bundled app. > My thinking was that the connector might need to be updated in sync with the database and I should not have to rebuild apps to do that. > > In JDK 9, the extension mechanism is gone. I have not found any way to achieve the equivalent effect. It seems that javapackager > controls the setting of the CLASSPATH. I have not found an option that would allow me to extend the CLASSPATH with a directory > where the connector JAR could be found. Is there a way to do this? > > Alan > Are you including the connector JAR in the app image? I think you could set the classpath if you us ant-javafx.jar: but honestly I?ve never tried it with JDK 9. A JDK 9 way of dynamically loading this would be to create a Layer. Here?s some semi working code you could use: public Plugin loadPlugin(String module, String classname) { Plugin result = null; Configuration cf = resolve(file.getAbsoluteFile().getParentFile().toPath(), name); ClassLoader scl = ClassLoader.getSystemClassLoader(); Layer layer = Layer.boot().defineModulesWithOneLoader(cf, scl); ClassLoader cl = layer.findLoader(name); try { result = createPlugin(layer, name, classname); result.load(); plugins.add(result); } catch (Exception e) { System.out.println("oh no!" + e.toString()); } return result; } private static Configuration resolve(Path modulepath, String... roots) { ModuleFinder finder = ModuleFinder.of(modulepath); return Layer.boot() .configuration() .resolve(finder, ModuleFinder.of(), Set.of(roots)); } private static Plugin createPlugin(Layer layer, String mn, String mc) throws Exception { ClassLoader loader = layer.findLoader(mn); Class c = loader.loadClass(mc); Plugin p = (Plugin)c.getConstructor().newInstance(); return p; } Chris From chris.bensen at oracle.com Tue Apr 25 21:04:57 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 25 Apr 2017 14:04:57 -0700 Subject: javapackager - partially self-contained apps in JDK 9 In-Reply-To: <8293BDE6-3C2D-4CF1-9D17-307BA0AECACE@cbfiddle.com> References: <7D269037-9A1F-40C1-9F9C-0E72D5CAC1DE@cbfiddle.com> <6BED262A-AB73-4703-88D5-A4C6AA19443C@oracle.com> <8293BDE6-3C2D-4CF1-9D17-307BA0AECACE@cbfiddle.com> Message-ID: The code that I included below will do what you want with modular JARs. I hope to get this as a feature of the Java Packager which would be called Pugins, but there?s only so much time, which is why I provided you with a portion of my prototype code. Chris > On Apr 25, 2017, at 12:11 PM, Alan Snyder wrote: > > The whole point is not to include the connector JAR in the bundled app, so that it can upgraded independently. > > I tried setting -classpath using fx:jvmuserarg, the app crashed (exit 1) on startup. > > I really wonder why this case is not handled in some convenient way. > > > > >> On Apr 25, 2017, at 11:32 AM, Chris Bensen wrote: >> >> >>> On Apr 11, 2017, at 10:43 AM, Alan Snyder wrote: >>> >>> I have run into a problem in moving my macOS apps from JDK 8 to 9. The issue relates to using MySQL via JDBC. >>> The connector class name is fixed. The class is loaded using Class.forName(). However, there can be different versions >>> of the connector in different JAR files, and the proper version might need to be synced with the currently installed version >>> of MySQL. >>> >>> In JDK 8, I used the extension mechanism to load the MySQL connector JAR rather than building this JAR into the bundled app. >>> My thinking was that the connector might need to be updated in sync with the database and I should not have to rebuild apps to do that. >>> >>> In JDK 9, the extension mechanism is gone. I have not found any way to achieve the equivalent effect. It seems that javapackager >>> controls the setting of the CLASSPATH. I have not found an option that would allow me to extend the CLASSPATH with a directory >>> where the connector JAR could be found. Is there a way to do this? >>> >>> Alan >>> >> >> >> Are you including the connector JAR in the app image? >> >> I think you could set the classpath if you us ant-javafx.jar: >> >> >> >> but honestly I?ve never tried it with JDK 9. >> >> A JDK 9 way of dynamically loading this would be to create a Layer. Here?s some semi working code you could use: >> >> >> public Plugin loadPlugin(String module, String classname) { >> Plugin result = null; >> Configuration cf = resolve(file.getAbsoluteFile().getParentFile().toPath(), name); >> ClassLoader scl = ClassLoader.getSystemClassLoader(); >> Layer layer = Layer.boot().defineModulesWithOneLoader(cf, scl); >> ClassLoader cl = layer.findLoader(name); >> >> try { >> result = createPlugin(layer, name, classname); >> result.load(); >> plugins.add(result); >> } >> catch (Exception e) { >> System.out.println("oh no!" + e.toString()); >> } >> >> return result; >> } >> >> private static Configuration resolve(Path modulepath, String... roots) { >> ModuleFinder finder = ModuleFinder.of(modulepath); >> return Layer.boot() >> .configuration() >> .resolve(finder, ModuleFinder.of(), Set.of(roots)); >> } >> >> private static Plugin createPlugin(Layer layer, String mn, String mc) throws Exception { >> ClassLoader loader = layer.findLoader(mn); >> Class c = loader.loadClass(mc); >> Plugin p = (Plugin)c.getConstructor().newInstance(); >> return p; >> } >> >> Chris > From james.graham at oracle.com Wed Apr 26 05:06:08 2017 From: james.graham at oracle.com (Jim Graham) Date: Tue, 25 Apr 2017 22:06:08 -0700 Subject: MarlinFX upgrade 0.7.5 In-Reply-To: References: Message-ID: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> I've reviewed the code and run a number of tests. Things look fine. I spotted at least one thing that I brought up in the 2D Marlin review, but since the 2 source bases are moving towards synchronizing with each other I didn't look too closely since many of the changes in the 2D Marlin update are things that are already "fixed" in this FX Marlin code, so I thought I would focus my scrutiny more on the 2D review instead. Would this code base be affected by the review comments I made there? Did you want to hold both until they both are ready to go in and then push them at the same time (to keep them in sync)? Minimally, it is time to file a bug against FX for this... ...jim On 4/19/17 11:35 PM, Laurent Bourg?s wrote: > Hi, > > Please review this MarlinFX upgrade to Marlin 0.7.5: > > JBS: no bug yet for OpenJFX 10 > webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.0/ > > Changes: > - Renderers: fixed block processing > - dead code & few comment removals in Strokers > - fixed all floating-point number literals to be x.0f or x.0d to simplify > the conversion between float & double variants > > PS: I plan to run later FindBugs, Netbeans & IntelliJ code analysis tools > to fix any warning > > Cheers, > Laurent > From chris.bensen at oracle.com Wed Apr 26 18:32:49 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 26 Apr 2017 11:32:49 -0700 Subject: [9] Review request: 8179363 Errors in Redistributable Module List Message-ID: <66E090D7-4810-4E5B-869A-E63C36AACFEE@oracle.com> Kevin, Victor, Please review this change to fix the redistributable file list. JIRA: https://bugs.openjdk.java.net/browse/JDK-8179363 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8179363/webrev.00/ Chris From arunprasad.rajkumar at oracle.com Wed Apr 26 18:52:31 2017 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Thu, 27 Apr 2017 00:22:31 +0530 Subject: [9] Code Review Request For 8179321: WebEngine.getDocument().getDocumentURI() no longer returns null for loading a String of HTML Message-ID: <7AFE61E1-DB37-45D6-AFCA-97047606B459@oracle.com> Hi Kevin, Guru, Please review the following fix, JIRA: https://bugs.openjdk.java.net/browse/JDK-8179321 Webrev: http://cr.openjdk.java.net/~arajkumar/8179321/webrev/ Thanks, Arun From bourges.laurent at gmail.com Wed Apr 26 21:37:19 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 26 Apr 2017 23:37:19 +0200 Subject: MarlinFX upgrade 0.7.5 In-Reply-To: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> References: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> Message-ID: Jim, 2017-04-26 7:06 GMT+02:00 Jim Graham : > I've reviewed the code and run a number of tests. Things look fine. > Thanks, but as I made some syntax changes in Marlin2D, I would like to postpone the review and synchronize again the code with Marlin2D. > > I spotted at least one thing that I brought up in the 2D Marlin review, > but since the 2 source bases are moving towards synchronizing with each > other I didn't look too closely since many of the changes in the 2D Marlin > update are things that are already "fixed" in this FX Marlin code, so I > thought I would focus my scrutiny more on the 2D review instead. Would this > code base be affected by the review comments I made there? Did you want to > hold both until they both are ready to go in and then push them at the same > time (to keep them in sync)? > I really do not know how to push both patches at the same time as it points to different forrests ... (I only have commit rights in graphics repo ?) Probably I let you push the final patches once ready and I will also maintain my github branches in sync. > > Minimally, it is time to file a bug against FX for this... > > ...jim > > > On 4/19/17 11:35 PM, Laurent Bourg?s wrote: > >> Hi, >> >> Please review this MarlinFX upgrade to Marlin 0.7.5: >> >> JBS: no bug yet for OpenJFX 10 >> webrev: http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.0/ >> >> Changes: >> - Renderers: fixed block processing >> - dead code & few comment removals in Strokers >> - fixed all floating-point number literals to be x.0f or x.0d to simplify >> the conversion between float & double variants >> >> PS: I plan to run later FindBugs, Netbeans & IntelliJ code analysis tools >> to fix any warning >> >> Cheers, >> Laurent >> >> -- -- Laurent Bourg?s From james.graham at oracle.com Wed Apr 26 23:08:54 2017 From: james.graham at oracle.com (Jim Graham) Date: Wed, 26 Apr 2017 16:08:54 -0700 Subject: MarlinFX upgrade 0.7.5 In-Reply-To: References: <039bb21d-aeec-437c-4005-c0b7862bee93@oracle.com> Message-ID: <3c7cbc1c-dddf-237d-f907-a05975646398@oracle.com> Hi Laurent, On 4/26/17 2:37 PM, Laurent Bourg?s wrote: > I spotted at least one thing that I brought up in the 2D Marlin review, but since the 2 source bases are moving > towards synchronizing with each other I didn't look too closely since many of the changes in the 2D Marlin update > are things that are already "fixed" in this FX Marlin code, so I thought I would focus my scrutiny more on the 2D > review instead. Would this code base be affected by the review comments I made there? Did you want to hold both > until they both are ready to go in and then push them at the same time (to keep them in sync)? > > I really do not know how to push both patches at the same time as it points to different forrests ... (I only have > commit rights in graphics repo ?) Probably I let you push the final patches once ready and I will also maintain my > github branches in sync. I wasn't talking about literally simultaneously, I was referring to waiting to push either until both have been reviewed and approved... ...jim From kevin.rushforth at oracle.com Thu Apr 27 11:57:56 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 27 Apr 2017 04:57:56 -0700 Subject: [9] Review request: 8179395: Duplicate entry in javafxsdk.tbom file Message-ID: <5901DCC4.4080703@oracle.com> Leo & Chris, Please review the following fix to remove a duplicate entry from the javafxsdk.tbom file: https://bugs.openjdk.java.net/browse/JDK-8179395 http://cr.openjdk.java.net/~kcr/8179395/webrev/ Thanks. -- Kevin From semyon.sadetsky at oracle.com Thu Apr 27 15:43:04 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 27 Apr 2017 08:43:04 -0700 Subject: [10] Review request for 8179102: Shift + Mouse wheel ScrollPane horizontal scrolling doesn't work on Linux but works on Mac. Message-ID: <6b1c38e2-fb06-f1e8-5cff-722d9584612e@oracle.com> Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8179102 webrev: http://cr.openjdk.java.net/~ssadetsky/8179102/webrev.00/ --Semyon From chris.bensen at oracle.com Thu Apr 27 17:23:13 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 27 Apr 2017 10:23:13 -0700 Subject: [10] Review request: 8177696 contents of javapackager -help needs to be updated Message-ID: <5A76D35C-ADEC-412E-8B60-AC6D865039E2@oracle.com> Victor, Please review this change to fix the Java Packager help screen. JIRA: https://bugs.openjdk.java.net/browse/JDK-8177696 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8177696/webrev.00/ Chris From li.jiang at oracle.com Fri Apr 28 02:17:03 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Fri, 28 Apr 2017 10:17:03 +0800 Subject: [9] Review request: 8179395: Duplicate entry in javafxsdk.tbom file In-Reply-To: <5901DCC4.4080703@oracle.com> References: <5901DCC4.4080703@oracle.com> Message-ID: Looks good. Thank you Kevin! Regards, Leo On 04/27/2017 07:57 PM, Kevin Rushforth wrote: > Leo & Chris, > > Please review the following fix to remove a duplicate entry from the javafxsdk.tbom file: > > https://bugs.openjdk.java.net/browse/JDK-8179395 > http://cr.openjdk.java.net/~kcr/8179395/webrev/ > > Thanks. > > -- Kevin > From kevin.rushforth at oracle.com Fri Apr 28 20:22:05 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 28 Apr 2017 13:22:05 -0700 Subject: [9] Review request: 8179454: Build FX docs for HTML 5 Message-ID: <5903A46D.3000206@oracle.com> Chien or Dave, Please review this simple request to enable running javadoc with the '-html5' option. This will match what the JDK does when building the docs bundle (which now also includes javafx.* modules). https://bugs.openjdk.java.net/browse/JDK-8179454 the one-line diff is in the JBS bug, and repeated here: diff --git a/build.gradle b/build.gradle --- a/build.gradle +++ b/build.gradle @@ -3564,6 +3564,7 @@ } options.addBooleanOption("XDignore.symbol.file").setValue(true); options.addBooleanOption("Xdoclint:${DOC_LINT}").setValue(IS_DOC_LINT); + options.addBooleanOption("html5").setValue(true); options.addBooleanOption("javafx").setValue(true); options.addBooleanOption("use").setValue(true); -- Kevin From kevin.rushforth at oracle.com Sat Apr 29 19:24:24 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 29 Apr 2017 12:24:24 -0700 Subject: [10] Review request: 8179463: Cleanup whitespace after fix for JDK-8170024 Message-ID: <5904E868.2080508@oracle.com> Jim or Laurent, The fix for JDK-8170024 has introduced a white space problem that causes jcheck to fail. Please review the following fix: https://bugs.openjdk.java.net/browse/JDK-8179463 The patch is attached, which just removes trailing whitespace from one line. -- Kevin From chien.yang at oracle.com Sun Apr 30 00:09:22 2017 From: chien.yang at oracle.com (Chien Yang) Date: Sat, 29 Apr 2017 17:09:22 -0700 Subject: [10] Code Review Request For 8179405: [Windows] [prism-d3d] Fix GetVersion and GetVersionEx deprecation warnings Message-ID: <7db268a5-1916-8f99-3063-3ee9d05ae3dd@oracle.com> Hi Kevin, Please review the proposed fix as part of the effort to make prism-d3d build warning free. JIRA: https://bugs.openjdk.java.net/browse/JDK-8179405 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8179405/webrev.00/ Thanks, - Chien From chien.yang at oracle.com Sun Apr 30 04:38:15 2017 From: chien.yang at oracle.com (Chien Yang) Date: Sat, 29 Apr 2017 21:38:15 -0700 Subject: [10] Code Review Request For 8179464: [Windows][prism-d3d] Fix compiler _CRT_SECURE_ warnings Message-ID: Hi Kevin, Please review the proposed fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8179464 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8179464/webrev.00/ Thanks, - Chien