From arunprasad.rajkumar at oracle.com Mon Jan 2 11:20:54 2017 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Mon, 2 Jan 2017 16:50:54 +0530 Subject: [webkit] [9] Review request for 8165909: JavaScript to Java String conversion is not correct Message-ID: <8D3F3EFB-7E96-4E0A-9201-37D0CBCA51EE@oracle.com> Hello Kevin, Guru, Murali, Please review the fix for JDK-8165909 . http://cr.openjdk.java.net/~arajkumar/8165909/webrev Analysis is updated in JBS. Thanks, Arun From kevin.rushforth at oracle.com Tue Jan 3 14:30:43 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 03 Jan 2017 06:30:43 -0800 Subject: AnimationTimer and actual frame rate In-Reply-To: <000c01d25ecb$2ba4ac30$82ee0490$@eu> References: <001b01d25cf4$aaf479d0$00dd6d70$@eu> <67592b6a-38f9-80dc-8b5f-c067f034c0cb@jugs.org> <002f01d25d40$a327f280$e977d780$@eu> <14ab35c1-97ee-dbfd-2205-5c1ea0f8cbc6@jugs.org> <000c01d25ecb$2ba4ac30$82ee0490$@eu> Message-ID: <586BB593.3040308@oracle.com> A running AnimationTimer class will cause pulses to be scheduled continuously, but they should still be limited to no more often than 1/60 sec (unless you are overriding it with system properties). -- Kevin Markus KARG wrote: > Merry Christmas, > > my personal observation when performaning an EU-fundet power consumption study was that once an (even no-op implementation!) AnimationTimer was registered, the CPU load increased by several percent _permanently_ on our lab machine. In contrast, with key frame animation, the CPU load stayed at zero percent but showed scattered peaks. Unfortunately I cannot tell you the actual JavaFX-internal reason for sure, but I assume that AnimationTimer is called at maximum possible CPU speed (i. e. more or less an endless loop) while the animation classes update only once per _pulse_ (i e. more or less 60 FPS). > > It feels like (but this might be a false detection of mine; I did not check the source code) as the pure _registering_ of an AnimationTimer would enable JavaFX to actually run some JavaFX-internal code "undelayed", while _just_ using animation classes do not run that same code before the next _pulse_ (possible by using timer interrupts set to the next 1/60s). > > It would be great if the JavaFX team could confirm this difference between AnimationTimer and animation classes? > > -Markus > > -----Original Message----- > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Michael Paus > Sent: Samstag, 24. Dezember 2016 10:21 > To: openjfx-dev at openjdk.java.net > Subject: Re: AnimationTimer and actual frame rate > > Many thanks again. > > Am 23.12.16 um 18:18 schrieb Markus KARG: > >> I assume it is OK for you to use internal APIs? >> > Of course it is :-) > >> Then you could go with: >> >> com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene) >> >> and let a timer fire one per second to request tracker.getAverageFPS(). >> > I'll give that a try as soon as my family lets me. > >> Beware not to use any AnimationTimer handlers, as it will reduce FPS, even if the handler method is short. >> > Is the AnimationTimer handler more critical in this respect than any of the built-in animations? > >> -Markus >> >> -----Original Message----- >> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >> Behalf Of Michael Paus >> Sent: Freitag, 23. Dezember 2016 17:04 >> To: openjfx-dev at openjdk.java.net >> Subject: Re: AnimationTimer and actual frame rate >> >> Thank you. That explains a lot of what I am observing but it also makes me wonder how you could effectively measure the actual frame rate because that's what you are normally interested in. >> Michael >> >> Am 23.12.16 um 09:15 schrieb Markus KARG: >> >>> AnimationTimer is fired once per "planned" frame (i. e. running at maximum possible FPS), not per "actually rendered" frame. JavaFX contains a lot of optimizations. For example, a boolean property animated over time to switch from false to true will only imply a single modification, hence only one frame is actually rendered. >>> -Markus >>> >>> -----Original Message----- >>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>> Behalf Of Michael Paus >>> Sent: Donnerstag, 22. Dezember 2016 17:29 >>> To: openjfx-dev at openjdk.java.net >>> Subject: AnimationTimer and actual frame rate >>> >>> Hi all, >>> >>> for quite a while now I am observing a strange behavior when running >>> some >>> >>> JavaFX graphics tests. The scenario is very simple. I am running some >>> animation >>> >>> which puts some load onto the graphics engine and I am trying to >>> measure the >>> >>> frame rate via an instance of an AnimationTimer. When I increase the >>> load high >>> >>> enough I reach a point where the indicated frame rate is just 60FPS >>> or even a bit >>> >>> lower but the observed frame rate on screen has already dropped to >>> something >>> >>> like 1-2 FPS. So what I observe is that the AnimationTimer is running >>> much faster >>> >>> than the updates of the graphics. How can that be? Does anybody have >>> an explanation >>> >>> under which circumstances this can happen? Or is this behavior a bug which I should report? >>> >>> Just some puzzle for the boring Christmas holidays :-) >>> >>> Merry Christmas to all of you >>> >>> Michael >>> >>> PS: My system is a MacBook Pro with NVidia graphic card. >>> >>> >>> > > > From mp at jugs.org Tue Jan 3 15:03:59 2017 From: mp at jugs.org (Michael Paus) Date: Tue, 3 Jan 2017 16:03:59 +0100 Subject: AnimationTimer and actual frame rate In-Reply-To: <586BB593.3040308@oracle.com> References: <001b01d25cf4$aaf479d0$00dd6d70$@eu> <67592b6a-38f9-80dc-8b5f-c067f034c0cb@jugs.org> <002f01d25d40$a327f280$e977d780$@eu> <14ab35c1-97ee-dbfd-2205-5c1ea0f8cbc6@jugs.org> <000c01d25ecb$2ba4ac30$82ee0490$@eu> <586BB593.3040308@oracle.com> Message-ID: <1d0a0648-d69c-b610-f463-9502c904326e@jugs.org> Yes, that's what I normally observe and when you increase the load on the graphics pipeline this is eventually slowed down when a frame rate of 60FPS cannot be maintained anymore. Now on my Mac I observe a very strange behavior under certain conditions where the visible frame updates drop to something like 1FPS but the AnimationTimer is still running with something like 30FPS. So, what I would like to know is whether such a behavior is normal according to the design or whether this is a potential bug. I have not yet observed this behavior on Windows. Michael Am 03.01.17 um 15:30 schrieb Kevin Rushforth: > A running AnimationTimer class will cause pulses to be scheduled > continuously, but they should still be limited to no more often than > 1/60 sec (unless you are overriding it with system properties). > > -- Kevin > > > Markus KARG wrote: >> Merry Christmas, >> >> my personal observation when performaning an EU-fundet power consumption study was that once an (even no-op implementation!) AnimationTimer was registered, the CPU load increased by several percent _permanently_ on our lab machine. In contrast, with key frame animation, the CPU load stayed at zero percent but showed scattered peaks. Unfortunately I cannot tell you the actual JavaFX-internal reason for sure, but I assume that AnimationTimer is called at maximum possible CPU speed (i. e. more or less an endless loop) while the animation classes update only once per _pulse_ (i e. more or less 60 FPS). >> >> It feels like (but this might be a false detection of mine; I did not check the source code) as the pure _registering_ of an AnimationTimer would enable JavaFX to actually run some JavaFX-internal code "undelayed", while _just_ using animation classes do not run that same code before the next _pulse_ (possible by using timer interrupts set to the next 1/60s). >> >> It would be great if the JavaFX team could confirm this difference between AnimationTimer and animation classes? >> >> -Markus >> >> -----Original Message----- >> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Michael Paus >> Sent: Samstag, 24. Dezember 2016 10:21 >> To:openjfx-dev at openjdk.java.net >> Subject: Re: AnimationTimer and actual frame rate >> >> Many thanks again. >> >> Am 23.12.16 um 18:18 schrieb Markus KARG: >> >>> I assume it is OK for you to use internal APIs? >>> >> Of course it is :-) >> >>> Then you could go with: >>> >>> com.sun.javafx.perf.PerformanceTracker.getSceneTracker(scene) >>> >>> and let a timer fire one per second to request tracker.getAverageFPS(). >>> >> I'll give that a try as soon as my family lets me. >> >>> Beware not to use any AnimationTimer handlers, as it will reduce FPS, even if the handler method is short. >>> >> Is the AnimationTimer handler more critical in this respect than any of the built-in animations? >> >>> -Markus >>> >>> -----Original Message----- >>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>> Behalf Of Michael Paus >>> Sent: Freitag, 23. Dezember 2016 17:04 >>> To:openjfx-dev at openjdk.java.net >>> Subject: Re: AnimationTimer and actual frame rate >>> >>> Thank you. That explains a lot of what I am observing but it also makes me wonder how you could effectively measure the actual frame rate because that's what you are normally interested in. >>> Michael >>> >>> Am 23.12.16 um 09:15 schrieb Markus KARG: >>> >>>> AnimationTimer is fired once per "planned" frame (i. e. running at maximum possible FPS), not per "actually rendered" frame. JavaFX contains a lot of optimizations. For example, a boolean property animated over time to switch from false to true will only imply a single modification, hence only one frame is actually rendered. >>>> -Markus >>>> >>>> -----Original Message----- >>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>>> Behalf Of Michael Paus >>>> Sent: Donnerstag, 22. Dezember 2016 17:29 >>>> To:openjfx-dev at openjdk.java.net >>>> Subject: AnimationTimer and actual frame rate >>>> >>>> Hi all, >>>> >>>> for quite a while now I am observing a strange behavior when running >>>> some >>>> >>>> JavaFX graphics tests. The scenario is very simple. I am running some >>>> animation >>>> >>>> which puts some load onto the graphics engine and I am trying to >>>> measure the >>>> >>>> frame rate via an instance of an AnimationTimer. When I increase the >>>> load high >>>> >>>> enough I reach a point where the indicated frame rate is just 60FPS >>>> or even a bit >>>> >>>> lower but the observed frame rate on screen has already dropped to >>>> something >>>> >>>> like 1-2 FPS. So what I observe is that the AnimationTimer is running >>>> much faster >>>> >>>> than the updates of the graphics. How can that be? Does anybody have >>>> an explanation >>>> >>>> under which circumstances this can happen? Or is this behavior a bug which I should report? >>>> >>>> Just some puzzle for the boring Christmas holidays :-) >>>> >>>> Merry Christmas to all of you >>>> >>>> Michael >>>> >>>> PS: My system is a MacBook Pro with NVidia graphic card. >>>> >>>> >>>> >> >> >> From David.Hill at Oracle.com Wed Jan 4 15:59:35 2017 From: David.Hill at Oracle.com (David Hill) Date: Wed, 04 Jan 2017 10:59:35 -0500 Subject: Correct warning in linux build Message-ID: <586D1BE7.3010306@Oracle.com> Chris, Kevin, Please review the fix for a problem that Chris stumbled on. The one line diff is in the JBS. This will teach me to test the side branches when I change the logging level :-) (actually, I think I switched from a print) https://bugs.openjdk.java.net/browse/JDK-8172219 -- 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 chris.bensen at oracle.com Wed Jan 4 17:15:01 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 4 Jan 2017 09:15:01 -0800 Subject: Result: New OpenJFX Committer: Victor Drozdov Message-ID: <68D5684D-3343-4FE5-9B82-C7FFE7CE8CB2@oracle.com> Voting for Victor Drozdov [1] to OpenJFX Committer [2] is now closed. Yes: 7 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Chris [1] http://openjdk.java.net/census#vdrozdov [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-December/020082.html From itaisha at gmail.com Wed Jan 4 17:19:41 2017 From: itaisha at gmail.com (Itai) Date: Wed, 4 Jan 2017 19:19:41 +0200 Subject: Question/discussion about JDK-8129582 Message-ID: Recently JDK-8129582 [1] started really affecting me, with startup speed and overall responsiveness becoming really bad. Digging into it, I have found most time is wasted in com.sun.javafx.text.GlyphLayout.layout (as represented by PangoGlyphLayout on my Linux machine), which in turn is called by com.sun.javafx.text.PrismTextLayout.shape, which has: if (run.isComplex()) { /* Use GlyphLayout to shape complex text */ layout.layout(run, font, strike, chars); } else { ... if (layoutCache == null) { ... } else { ... } } which to my very naive reading seems as if while non-complex (with all BiDi text considered complex) glyph runs are cached, complex runs are never cached, which forces re-calculation every time. I'm trying to read and understand this part better, but could it be possible that this is the issue? How feasible would it be to have a layout cache for complex runs, or at least non-complex BiDi runs? Thanks, Itai. [1]: https://bugs.openjdk.java.net/browse/JDK-8129582 From philip.race at oracle.com Wed Jan 4 17:26:43 2017 From: philip.race at oracle.com (Philip Race) Date: Wed, 04 Jan 2017 09:26:43 -0800 Subject: Question/discussion about JDK-8129582 In-Reply-To: References: Message-ID: <586D3053.3020308@oracle.com> The cache is a heuristic optimisation and whether it helps depends on how well that cache is used. It is a time-space trade-off and I'd expect it to show up as helping more in micro-benchmarks or text-intensive benchmarks which use the same text broken in the same way. Complex text layout is inherently slower and if you are doing a lot of it .. it will be slow .. and unless it is repeated a cache won't help. During start-up I'd *expect* that there isn't a lot of re-use going on. You would need to profile how often the same text (and attributes) are passed through this code. If you could provide us a test case we could examine it too. If it were a real use case, then we'd move on to examine the feasibility of caching ... -phil. On 1/4/17, 9:19 AM, Itai wrote: > Recently JDK-8129582 [1] started really affecting me, with startup speed > and overall responsiveness becoming really bad. > > Digging into it, I have found most time is wasted in > com.sun.javafx.text.GlyphLayout.layout (as represented by PangoGlyphLayout > on my Linux machine), which in turn is called > by com.sun.javafx.text.PrismTextLayout.shape, which has: > > if (run.isComplex()) { > /* Use GlyphLayout to shape complex text */ > layout.layout(run, font, strike, chars); > } else { > ... > if (layoutCache == null) { > ... > } else { > ... > } > } > > which to my very naive reading seems as if while non-complex (with all BiDi > text considered complex) glyph runs are cached, complex runs are never > cached, which forces re-calculation every time. > > I'm trying to read and understand this part better, but could it be > possible that this is the issue? How feasible would it be to have a layout > cache for complex runs, or at least non-complex BiDi runs? > > Thanks, > Itai. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8129582 From itaisha at gmail.com Wed Jan 4 17:48:36 2017 From: itaisha at gmail.com (Itai) Date: Wed, 4 Jan 2017 19:48:36 +0200 Subject: Question/discussion about JDK-8129582 In-Reply-To: <586D3053.3020308@oracle.com> References: <586D3053.3020308@oracle.com> Message-ID: Thanks for replying. I think I understand what you're saying about the cache. As for complexity - I'm mostly working with text which is only in Hebrew, which isn't complex as far as I understand the definition (no glyph "fusing" as in Arabic or Farsi). I can work with minor performance drops, but when the same window takes more than 10 times to show if it has Hebrew labels is a lot more than minor - and this is exclusive to JavaFX, so it's not like this problem is unsolvable. Perhaps the caching is indeed not the correct solution, but maybe there can be a way to simplify the layout in non-complex BiDi cases? Or optimize PangoGlyphLayout.layout? Thank you again for replying, I really hope this issue can see some improvement. On Wed, Jan 4, 2017 at 7:26 PM, Philip Race wrote: > The cache is a heuristic optimisation and whether it helps depends on how > well that cache is used. > It is a time-space trade-off and I'd expect it to show up as helping more > in micro-benchmarks or > text-intensive benchmarks which use the same text broken in the same way. > Complex text layout is inherently slower and if you are doing a lot of it > .. it will be slow .. and > unless it is repeated a cache won't help. > During start-up I'd *expect* that there isn't a lot of re-use going on. > > You would need to profile how often the same text (and attributes) are > passed through this code. > If you could provide us a test case we could examine it too. > > If it were a real use case, then we'd move on to examine the feasibility > of caching ... > > -phil. > > > > On 1/4/17, 9:19 AM, Itai wrote: > >> Recently JDK-8129582 [1] started really affecting me, with startup speed >> and overall responsiveness becoming really bad. >> >> Digging into it, I have found most time is wasted in >> com.sun.javafx.text.GlyphLayout.layout (as represented by >> PangoGlyphLayout >> on my Linux machine), which in turn is called >> by com.sun.javafx.text.PrismTextLayout.shape, which has: >> >> if (run.isComplex()) { >> /* Use GlyphLayout to shape complex text */ >> layout.layout(run, font, strike, chars); >> } else { >> ... >> if (layoutCache == null) { >> ... >> } else { >> ... >> } >> } >> >> which to my very naive reading seems as if while non-complex (with all >> BiDi >> text considered complex) glyph runs are cached, complex runs are never >> cached, which forces re-calculation every time. >> >> I'm trying to read and understand this part better, but could it be >> possible that this is the issue? How feasible would it be to have a layout >> cache for complex runs, or at least non-complex BiDi runs? >> >> Thanks, >> Itai. >> >> [1]: https://bugs.openjdk.java.net/browse/JDK-8129582 >> > From itaisha at gmail.com Wed Jan 4 18:32:51 2017 From: itaisha at gmail.com (Itai) Date: Wed, 4 Jan 2017 20:32:51 +0200 Subject: Question/discussion about JDK-8129582 In-Reply-To: References: <586D3053.3020308@oracle.com> Message-ID: Some quick-and-dirty thing I hacked now and seems to improve the performance drastically is something like: if (complex but not bidi) { use GlyphLayout. } else if (bidi) { use java.text.Bidi.reorderVisually to get visual glyph order, then use same implementation as non-bidi non-complex layout } else { ... } Very minimal tests show it working correctly, and performance is 8-10 times faster (on par with non-bidi text). Do you think this solution makes sense? Can you see any obvious pitfalls? If it seems OK I'll try some more tests and then work it into something clean enough to submit as a patch suggestion. On Wed, Jan 4, 2017 at 7:48 PM, Itai wrote: > Thanks for replying. > I think I understand what you're saying about the cache. As for complexity > - I'm mostly working with text which is only in Hebrew, which isn't complex > as far as I understand the definition (no glyph "fusing" as in Arabic or > Farsi). I can work with minor performance drops, but when the same window > takes more than 10 times to show if it has Hebrew labels is a lot more than > minor - and this is exclusive to JavaFX, so it's not like this problem is > unsolvable. > > Perhaps the caching is indeed not the correct solution, but maybe there > can be a way to simplify the layout in non-complex BiDi cases? Or optimize > PangoGlyphLayout.layout? > > Thank you again for replying, I really hope this issue can see some > improvement. > > On Wed, Jan 4, 2017 at 7:26 PM, Philip Race > wrote: > >> The cache is a heuristic optimisation and whether it helps depends on how >> well that cache is used. >> It is a time-space trade-off and I'd expect it to show up as helping more >> in micro-benchmarks or >> text-intensive benchmarks which use the same text broken in the same way. >> Complex text layout is inherently slower and if you are doing a lot of it >> .. it will be slow .. and >> unless it is repeated a cache won't help. >> During start-up I'd *expect* that there isn't a lot of re-use going on. >> >> You would need to profile how often the same text (and attributes) are >> passed through this code. >> If you could provide us a test case we could examine it too. >> >> If it were a real use case, then we'd move on to examine the feasibility >> of caching ... >> >> -phil. >> >> >> >> On 1/4/17, 9:19 AM, Itai wrote: >> >>> Recently JDK-8129582 [1] started really affecting me, with startup speed >>> and overall responsiveness becoming really bad. >>> >>> Digging into it, I have found most time is wasted in >>> com.sun.javafx.text.GlyphLayout.layout (as represented by >>> PangoGlyphLayout >>> on my Linux machine), which in turn is called >>> by com.sun.javafx.text.PrismTextLayout.shape, which has: >>> >>> if (run.isComplex()) { >>> /* Use GlyphLayout to shape complex text */ >>> layout.layout(run, font, strike, chars); >>> } else { >>> ... >>> if (layoutCache == null) { >>> ... >>> } else { >>> ... >>> } >>> } >>> >>> which to my very naive reading seems as if while non-complex (with all >>> BiDi >>> text considered complex) glyph runs are cached, complex runs are never >>> cached, which forces re-calculation every time. >>> >>> I'm trying to read and understand this part better, but could it be >>> possible that this is the issue? How feasible would it be to have a >>> layout >>> cache for complex runs, or at least non-complex BiDi runs? >>> >>> Thanks, >>> Itai. >>> >>> [1]: https://bugs.openjdk.java.net/browse/JDK-8129582 >>> >> > From philip.race at oracle.com Wed Jan 4 18:44:48 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 4 Jan 2017 10:44:48 -0800 Subject: Question/discussion about JDK-8129582 In-Reply-To: References: <586D3053.3020308@oracle.com> Message-ID: <827bf5c3-1e12-c4b4-5bad-aeb5c28e6864@oracle.com> You can't skip layout just because it is bidi .. where here you are apparently implicitly meaning Hebrew. This might be apparently working but may not always work even for Hebrew and will be a disaster for Arabic. Here is a web page which talks about OTL (OpenType Layout) for Hebrew : https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm I can't say offhand why this might be exclusive to FX. That test case would be handy. So this needs more analysis even if you found a way to limit this to specifically Latin+Hebrew. -phil. On 01/04/2017 10:32 AM, Itai wrote: > Some quick-and-dirty thing I hacked now and seems to improve the > performance drastically is something like: > > if (complex but not bidi) { > use GlyphLayout. > } else if (bidi) { > use java.text.Bidi.reorderVisually to get visual glyph order, then > use same implementation as non-bidi non-complex layout > } else { > ... > } > > Very minimal tests show it working correctly, and performance is 8-10 > times faster (on par with non-bidi text). > Do you think this solution makes sense? Can you see any obvious pitfalls? > If it seems OK I'll try some more tests and then work it into > something clean enough to submit as a patch suggestion. > > > On Wed, Jan 4, 2017 at 7:48 PM, Itai > wrote: > > Thanks for replying. > I think I understand what you're saying about the cache. As for > complexity - I'm mostly working with text which is only in Hebrew, > which isn't complex as far as I understand the definition (no > glyph "fusing" as in Arabic or Farsi). I can work with minor > performance drops, but when the same window takes more than 10 > times to show if it has Hebrew labels is a lot more than minor - > and this is exclusive to JavaFX, so it's not like this problem is > unsolvable. > > Perhaps the caching is indeed not the correct solution, but maybe > there can be a way to simplify the layout in non-complex BiDi > cases? Or optimize PangoGlyphLayout.layout? > > Thank you again for replying, I really hope this issue can see > some improvement. > > On Wed, Jan 4, 2017 at 7:26 PM, Philip Race > > wrote: > > The cache is a heuristic optimisation and whether it helps > depends on how well that cache is used. > It is a time-space trade-off and I'd expect it to show up as > helping more in micro-benchmarks or > text-intensive benchmarks which use the same text broken in > the same way. > Complex text layout is inherently slower and if you are doing > a lot of it .. it will be slow .. and > unless it is repeated a cache won't help. > During start-up I'd *expect* that there isn't a lot of re-use > going on. > > You would need to profile how often the same text (and > attributes) are passed through this code. > If you could provide us a test case we could examine it too. > > If it were a real use case, then we'd move on to examine the > feasibility of caching ... > > -phil. > > > > On 1/4/17, 9:19 AM, Itai wrote: > > Recently JDK-8129582 [1] started really affecting me, with > startup speed > and overall responsiveness becoming really bad. > > Digging into it, I have found most time is wasted in > com.sun.javafx.text.GlyphLayout.layout (as represented by > PangoGlyphLayout > on my Linux machine), which in turn is called > by com.sun.javafx.text.PrismTextLayout.shape, which has: > > if (run.isComplex()) { > /* Use GlyphLayout to shape complex text */ > layout.layout(run, font, strike, chars); > } else { > ... > if (layoutCache == null) { > ... > } else { > ... > } > } > > which to my very naive reading seems as if while > non-complex (with all BiDi > text considered complex) glyph runs are cached, complex > runs are never > cached, which forces re-calculation every time. > > I'm trying to read and understand this part better, but > could it be > possible that this is the issue? How feasible would it be > to have a layout > cache for complex runs, or at least non-complex BiDi runs? > > Thanks, > Itai. > > [1]: https://bugs.openjdk.java.net/browse/JDK-8129582 > > > > From David.Hill at Oracle.com Wed Jan 4 19:32:04 2017 From: David.Hill at Oracle.com (David Hill) Date: Wed, 04 Jan 2017 14:32:04 -0500 Subject: Review: create a run.java.policy file Message-ID: <586D4DB4.2050705@Oracle.com> Kevin, if you could review: https://bugs.openjdk.java.net/browse/JDK-8172243 webrev: http://cr.openjdk.java.net/~ddhill/8172243 thanks, 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 kevin.rushforth at oracle.com Wed Jan 4 21:00:55 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 04 Jan 2017 13:00:55 -0800 Subject: [9] Review request: JDK-8172216: Remove unused, obsolete iOS code Message-ID: <586D6287.8080902@oracle.com> Hi, Please review the following simple cleanup fix: https://bugs.openjdk.java.net/browse/JDK-8172216 http://cr.openjdk.java.net/~kcr/8172216/webrev.00/ Thanks. -- Kevin From kevin.rushforth at oracle.com Thu Jan 5 18:20:40 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Jan 2017 10:20:40 -0800 Subject: [9] Review request: 8171674: Remove JavaFX .so files from the lib/$ARCH directory on Linux Message-ID: <586E8E78.9070506@oracle.com> Hi Dave, Please review the following to remove all .so files from lib/$ARCH on Linux (as a follow-up to JDK-8171450) : https://bugs.openjdk.java.net/browse/JDK-8171674 http://cr.openjdk.java.net/~kcr/8171674/webrev.00/ Thanks. -- Kevin From kevin.rushforth at oracle.com Thu Jan 5 19:05:14 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Jan 2017 11:05:14 -0800 Subject: Weekly sanity testing moving from Mondays to Fridays Message-ID: <586E98EA.1070208@oracle.com> In order to better line up with the JDK build promotion schedule, we are moving our weekly OpenJFX pre-integration sanity testing from Mondays to Fridays. Starting this week, here is the new schedule: 1. The *testing* period will be from *Thursday evening Pacific through Friday 11:59am Pacific*. 2. The "*lockout*" period will be much shorter: *1am to 2am Pacific on Friday*s. No more "no push Mondays" (and we won't replace it with a "no push Friday"). The existing 12 hour lockout was intended to solve a problem we don't have in practice. The only reason we need a lockout at all is due to the way our build systems are configured and the fact that pushing to multiple repos in the forest is not atomic. 3. In exchange for #2, and to better reflect what we really needed the lockout for in the first place, developers are strongly encouraged to *avoid pushing intrusive changes* (e.g., large scale refactoring, WebKit upgrades, etc.) or risky fixes from *Thursday 5pm Pacific through Friday 5pm Pacific*. Intrusive changes and risky fixes should go prior to Thursday afternoon (or over the weekend as long as you don't break the build). See the Wiki for details: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Please let me know if you have any concerns or questions. Thanks! -- Kevin From murali.billa at oracle.com Thu Jan 5 20:26:25 2017 From: murali.billa at oracle.com (Murali Billa) Date: Thu, 5 Jan 2017 12:26:25 -0800 (PST) Subject: [9] Review request for 8170610: Validation of JSObject Memory leak 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> Message-ID: <4e8a047a-3bf0-433c-94a3-b5c996421185@default> ? ? Hi Kevin, Arun, Guru Please review the fix for JDK-8170610. JIRA: https://bugs.openjdk.java.net/browse/JDK-8170610 ? ? Webrev: http://cr.openjdk.java.net/~mbilla/8170610/webrev.00/ ? Thanks, Murali From james.graham at oracle.com Fri Jan 6 01:16:52 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 5 Jan 2017 17:16:52 -0800 Subject: [8u] Review request for 8169777: MenuBar unoperable after moving Application to second monitor Message-ID: This is essentially a backport request for the fix for JDK-8160073, but a modification of the fix was needed as the code changed between 8u and 9. JBS: https://bugs.openjdk.java.net/browse/JDK-8169777 webrev: http://cr.openjdk.java.net/~flar/JDK-8169777/webrev.00/ I tested on Win10 and it works fine, though the platform support for DPI scaling on Win8 (pre-8.1) and Win7 was different than their handling on Win10 so a test run of the test case on Win7 and/or Win8.0 would be helpful for sanity. Unfortunately my Win7 boot partition is buried in a cesspool of permission issues trying to run the test build... :( ...jim From ajit.ghaisas at oracle.com Fri Jan 6 09:36:11 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 6 Jan 2017 01:36:11 -0800 (PST) Subject: [9] Review request : JDK-8171228 : StackOverflowError on MenuBarSkin when handling key-events and only menu is disabled Message-ID: Hi Jonathan, Request you to review a fix where I have replaced an erroneous recursion (that caused StackOverflow) with a loop. Bug : https://bugs.openjdk.java.net/browse/JDK-8171228 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8171228/webrev.0/ Regards, Ajit From chien.yang at oracle.com Fri Jan 6 23:27:50 2017 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 06 Jan 2017 15:27:50 -0800 Subject: [9] Code Review Request For 8171852: JavaFX Stage flickers on resize on Windows platforms Message-ID: <587027F6.4030109@oracle.com> Hi Kevin, Please review the proposed fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8171852 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8171852/webrev.00/ Thanks, - Chien From itaisha at gmail.com Sun Jan 8 18:08:54 2017 From: itaisha at gmail.com (Itai) Date: Sun, 8 Jan 2017 20:08:54 +0200 Subject: Question/discussion about JDK-8129582 In-Reply-To: <827bf5c3-1e12-c4b4-5bad-aeb5c28e6864@oracle.com> References: <586D3053.3020308@oracle.com> <827bf5c3-1e12-c4b4-5bad-aeb5c28e6864@oracle.com> Message-ID: Thank you for the link, it's an interesting read indeed! I wasn't really skipping layout, just using the much simpler layout used by Latin scripts, but you are correct that this will break for anything more complex - this has nothing to do with BiDi though, more to do with complex layout elements (like diacritic or cantillation marks for Hebrew, or general Arabic/Farsi text). Indeed, this can't be a general solution, but I guess I was driven by frustration. I have tried some more configurations though, and found that on Windows the loss of performance is much less noticeable, which seems to mean that the problem is either: 1. Pango is inherently slow / inherently slow when laying out BiDi text. 2. JavaFX uses Pango in a sub-optimal / redundant way. 3. The JNI / native calls to Pango are done in a sub-optimal way. Option 1 can be easily debunked, as general Gnome/GTK applications run as smoothly with BiDi text as with Latin / LTR text. For options 2 and 3 I guess some more digging into the code must be done. My understanding is that JNI calls are not likely to incur performance loss to such a degree, unless very large amounts of memory are copied back and forth between Java and native code, so I'll start by reading into the Pango documentation and understanding the logic of PangoGlyphLayout. If you have any input on this or believe my assumptions or conclusions are wrong I'd be glad to hear. I realize you are all busy with the upcoming 9 release, so I'll try to get as detailed a result as I can. Regards, Itai. On Wed, Jan 4, 2017 at 8:44 PM, Phil Race wrote: > You can't skip layout just because it is bidi .. > where here you are apparently implicitly meaning Hebrew. > This might be apparently working but may not always work even > for Hebrew and will be a disaster for Arabic. > > Here is a web page which talks about OTL (OpenType Layout) for Hebrew : > https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm > I can't say offhand why this might be exclusive to FX. > That test case would be handy. > So this needs more analysis even if you found a way to limit this to > specifically Latin+Hebrew. > > -phil. > > > On 01/04/2017 10:32 AM, Itai wrote: > > Some quick-and-dirty thing I hacked now and seems to improve the > performance drastically is something like: > > if (complex but not bidi) { > use GlyphLayout. > } else if (bidi) { > use java.text.Bidi.reorderVisually to get visual glyph order, then use > same implementation as non-bidi non-complex layout > } else { > ... > } > > Very minimal tests show it working correctly, and performance is 8-10 > times faster (on par with non-bidi text). > Do you think this solution makes sense? Can you see any obvious pitfalls? > If it seems OK I'll try some more tests and then work it into something > clean enough to submit as a patch suggestion. > > > On Wed, Jan 4, 2017 at 7:48 PM, Itai wrote: > >> Thanks for replying. >> I think I understand what you're saying about the cache. As for >> complexity - I'm mostly working with text which is only in Hebrew, which >> isn't complex as far as I understand the definition (no glyph "fusing" as >> in Arabic or Farsi). I can work with minor performance drops, but when the >> same window takes more than 10 times to show if it has Hebrew labels is a >> lot more than minor - and this is exclusive to JavaFX, so it's not like >> this problem is unsolvable. >> >> Perhaps the caching is indeed not the correct solution, but maybe there >> can be a way to simplify the layout in non-complex BiDi cases? Or optimize >> PangoGlyphLayout.layout? >> >> Thank you again for replying, I really hope this issue can see some >> improvement. >> >> On Wed, Jan 4, 2017 at 7:26 PM, Philip Race < >> philip.race at oracle.com> wrote: >> >>> The cache is a heuristic optimisation and whether it helps depends on >>> how well that cache is used. >>> It is a time-space trade-off and I'd expect it to show up as helping >>> more in micro-benchmarks or >>> text-intensive benchmarks which use the same text broken in the same way. >>> Complex text layout is inherently slower and if you are doing a lot of >>> it .. it will be slow .. and >>> unless it is repeated a cache won't help. >>> During start-up I'd *expect* that there isn't a lot of re-use going on. >>> >>> You would need to profile how often the same text (and attributes) are >>> passed through this code. >>> If you could provide us a test case we could examine it too. >>> >>> If it were a real use case, then we'd move on to examine the feasibility >>> of caching ... >>> >>> -phil. >>> >>> >>> >>> On 1/4/17, 9:19 AM, Itai wrote: >>> >>>> Recently JDK-8129582 [1] started really affecting me, with startup speed >>>> and overall responsiveness becoming really bad. >>>> >>>> Digging into it, I have found most time is wasted in >>>> com.sun.javafx.text.GlyphLayout.layout (as represented by >>>> PangoGlyphLayout >>>> on my Linux machine), which in turn is called >>>> by com.sun.javafx.text.PrismTextLayout.shape, which has: >>>> >>>> if (run.isComplex()) { >>>> /* Use GlyphLayout to shape complex text */ >>>> layout.layout(run, font, strike, chars); >>>> } else { >>>> ... >>>> if (layoutCache == null) { >>>> ... >>>> } else { >>>> ... >>>> } >>>> } >>>> >>>> which to my very naive reading seems as if while non-complex (with all >>>> BiDi >>>> text considered complex) glyph runs are cached, complex runs are never >>>> cached, which forces re-calculation every time. >>>> >>>> I'm trying to read and understand this part better, but could it be >>>> possible that this is the issue? How feasible would it be to have a >>>> layout >>>> cache for complex runs, or at least non-complex BiDi runs? >>>> >>>> Thanks, >>>> Itai. >>>> >>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8129582 >>>> >>> >> > > From itaisha at gmail.com Sun Jan 8 21:39:04 2017 From: itaisha at gmail.com (Itai) Date: Sun, 8 Jan 2017 23:39:04 +0200 Subject: Question/discussion about JDK-8129582 In-Reply-To: References: <586D3053.3020308@oracle.com> <827bf5c3-1e12-c4b4-5bad-aeb5c28e6864@oracle.com> Message-ID: I think I have found two problems. The first, and probably most critical one, is that a new PangoFontMap is created for every call of PangoGlyphLayout#layout. It is not entirely clear from the Pango documentation what the lifetime or intended usage of a PangoFontMap is, but I have found this comment in [1]: "But note that a PangoFontMap is a big expensive object. So, you *really* want to be using only one for your entire program. Frequently calling pango_ft2_font_map_new() is going kill the performance of your application." This seems to imply PangoFontMap is intended as a global (per display?) font cache. Indeed, creating only one PangoFontMap seems to improve performance drastically, although I'm not sure what is the best way to handle this object (i.e. when and how it should be re-used and freed), as it should probably (?) be held for the entire lifetime of the JavaFX application. The second problem is probably less significant, but could still theoretically hurt performance - it has to do with the usage of g_list_nth_data, which as per [2] has O(N) complexity, and is called once per item in the list, which yields O(N^2) complexity. Replacing it with linked-list traversal with g_list_next should reduce this back to O(N). I hope this information is clear enough. As I said I lack the overall understanding of the JavaFX platform to know where and how to manage a global object, such as PangoFontMap should apparently be, so I refrain from posting any patch that I know would be wrong. Regards, Itai. [1]: https://mail.gnome.org/archives/gtk-list/2005-April/msg00105.html [2]: https://developer.gnome.org/programming-guidelines/stable/glist.html.en On Sun, Jan 8, 2017 at 8:08 PM, Itai wrote: > Thank you for the link, it's an interesting read indeed! > > I wasn't really skipping layout, just using the much simpler layout used > by Latin scripts, but you are correct that this will break for anything > more complex - this has nothing to do with BiDi though, more to do with > complex layout elements (like diacritic or cantillation marks for Hebrew, > or general Arabic/Farsi text). > Indeed, this can't be a general solution, but I guess I was driven by > frustration. > > I have tried some more configurations though, and found that on Windows > the loss of performance is much less noticeable, which seems to mean that > the problem is either: > 1. Pango is inherently slow / inherently slow when laying out BiDi text. > 2. JavaFX uses Pango in a sub-optimal / redundant way. > 3. The JNI / native calls to Pango are done in a sub-optimal way. > > Option 1 can be easily debunked, as general Gnome/GTK applications run as > smoothly with BiDi text as with Latin / LTR text. > For options 2 and 3 I guess some more digging into the code must be done. > My understanding is that JNI calls are not likely to incur performance loss > to such a degree, unless very large amounts of memory are copied back and > forth between Java and native code, so I'll start by reading into the Pango > documentation and understanding the logic of PangoGlyphLayout. > > If you have any input on this or believe my assumptions or conclusions are > wrong I'd be glad to hear. I realize you are all busy with the upcoming 9 > release, so I'll try to get as detailed a result as I can. > > Regards, > Itai. > > On Wed, Jan 4, 2017 at 8:44 PM, Phil Race wrote: > >> You can't skip layout just because it is bidi .. >> where here you are apparently implicitly meaning Hebrew. >> This might be apparently working but may not always work even >> for Hebrew and will be a disaster for Arabic. >> >> Here is a web page which talks about OTL (OpenType Layout) for Hebrew : >> https://www.microsoft.com/typography/OpenTypeDev/hebrew/intro.htm >> I can't say offhand why this might be exclusive to FX. >> That test case would be handy. >> So this needs more analysis even if you found a way to limit this to >> specifically Latin+Hebrew. >> >> -phil. >> >> >> On 01/04/2017 10:32 AM, Itai wrote: >> >> Some quick-and-dirty thing I hacked now and seems to improve the >> performance drastically is something like: >> >> if (complex but not bidi) { >> use GlyphLayout. >> } else if (bidi) { >> use java.text.Bidi.reorderVisually to get visual glyph order, then use >> same implementation as non-bidi non-complex layout >> } else { >> ... >> } >> >> Very minimal tests show it working correctly, and performance is 8-10 >> times faster (on par with non-bidi text). >> Do you think this solution makes sense? Can you see any obvious pitfalls? >> If it seems OK I'll try some more tests and then work it into something >> clean enough to submit as a patch suggestion. >> >> >> On Wed, Jan 4, 2017 at 7:48 PM, Itai wrote: >> >>> Thanks for replying. >>> I think I understand what you're saying about the cache. As for >>> complexity - I'm mostly working with text which is only in Hebrew, which >>> isn't complex as far as I understand the definition (no glyph "fusing" as >>> in Arabic or Farsi). I can work with minor performance drops, but when the >>> same window takes more than 10 times to show if it has Hebrew labels is a >>> lot more than minor - and this is exclusive to JavaFX, so it's not like >>> this problem is unsolvable. >>> >>> Perhaps the caching is indeed not the correct solution, but maybe there >>> can be a way to simplify the layout in non-complex BiDi cases? Or optimize >>> PangoGlyphLayout.layout? >>> >>> Thank you again for replying, I really hope this issue can see some >>> improvement. >>> >>> On Wed, Jan 4, 2017 at 7:26 PM, Philip Race < >>> philip.race at oracle.com> wrote: >>> >>>> The cache is a heuristic optimisation and whether it helps depends on >>>> how well that cache is used. >>>> It is a time-space trade-off and I'd expect it to show up as helping >>>> more in micro-benchmarks or >>>> text-intensive benchmarks which use the same text broken in the same >>>> way. >>>> Complex text layout is inherently slower and if you are doing a lot of >>>> it .. it will be slow .. and >>>> unless it is repeated a cache won't help. >>>> During start-up I'd *expect* that there isn't a lot of re-use going on. >>>> >>>> You would need to profile how often the same text (and attributes) are >>>> passed through this code. >>>> If you could provide us a test case we could examine it too. >>>> >>>> If it were a real use case, then we'd move on to examine the >>>> feasibility of caching ... >>>> >>>> -phil. >>>> >>>> >>>> >>>> On 1/4/17, 9:19 AM, Itai wrote: >>>> >>>>> Recently JDK-8129582 [1] started really affecting me, with startup >>>>> speed >>>>> and overall responsiveness becoming really bad. >>>>> >>>>> Digging into it, I have found most time is wasted in >>>>> com.sun.javafx.text.GlyphLayout.layout (as represented by >>>>> PangoGlyphLayout >>>>> on my Linux machine), which in turn is called >>>>> by com.sun.javafx.text.PrismTextLayout.shape, which has: >>>>> >>>>> if (run.isComplex()) { >>>>> /* Use GlyphLayout to shape complex text */ >>>>> layout.layout(run, font, strike, chars); >>>>> } else { >>>>> ... >>>>> if (layoutCache == null) { >>>>> ... >>>>> } else { >>>>> ... >>>>> } >>>>> } >>>>> >>>>> which to my very naive reading seems as if while non-complex (with all >>>>> BiDi >>>>> text considered complex) glyph runs are cached, complex runs are never >>>>> cached, which forces re-calculation every time. >>>>> >>>>> I'm trying to read and understand this part better, but could it be >>>>> possible that this is the issue? How feasible would it be to have a >>>>> layout >>>>> cache for complex runs, or at least non-complex BiDi runs? >>>>> >>>>> Thanks, >>>>> Itai. >>>>> >>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8129582 >>>>> >>>> >>> >> >> > From jonathan.giles at oracle.com Mon Jan 9 04:12:41 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 9 Jan 2017 17:12:41 +1300 Subject: [Review request] 8171983: Add javadoc comments to module-info.java for javafx.* modules Message-ID: <081bf6b7-2090-6244-788c-2d076bfb0167@oracle.com> Kevin, Please review the webrev for adding module-level javadoc comments to all JavaFX modules defined in JDK 9: https://bugs.openjdk.java.net/browse/JDK-8171983 http://cr.openjdk.java.net/~jgiles/8171983/index.html Thanks, -- Jonathan From jonathan.giles at oracle.com Mon Jan 9 22:37:09 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 10 Jan 2017 11:37:09 +1300 Subject: [Review request] 8171926: Minor cleanup of API docs in controls Message-ID: Kevin, Could you please review the documentation cleanups done here: https://bugs.openjdk.java.net/browse/JDK-8171926 http://cr.openjdk.java.net/~jgiles/8171926/ Thanks, -- Jonathan From kevin.rushforth at oracle.com Tue Jan 10 19:42:17 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 10 Jan 2017 11:42:17 -0800 Subject: [9] Review request: 8172522: Doc resources for javafx.* modules are missing from modules_src Message-ID: <58753919.4080903@oracle.com> Hi Dave, Please review the following to copy the needed files for the javadoc build to modules_src: https://bugs.openjdk.java.net/browse/JDK-8172522 http://cr.openjdk.java.net/~kcr/8172522/webrev.00/ Thanks. -- Kevin From semyon.sadetsky at oracle.com Wed Jan 11 14:23:10 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 11 Jan 2017 17:23:10 +0300 Subject: [9] Review request for 8172096: SwingNode, Linux: certain mnemonics don't work on Unity Message-ID: <0df26627-752b-549c-2ad9-099b38085ba4@oracle.com> Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8172096 webrev: http://cr.openjdk.java.net/~ssadetsky/8172096/webrev.00/ The details are in the bug. --Semyon From kevin.rushforth at oracle.com Wed Jan 11 19:14:23 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 11 Jan 2017 11:14:23 -0800 Subject: Testing your JavaFX applications on JDK 9 Message-ID: <5876840F.40508@oracle.com> As you may know JDK 9 has hit the feature extension complete milestone [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need to know about them in order to fix them. Our focus will be on bugs that are new in JDK 9 (regressions). I ask all JavaFX developers to please download JDK 9 early access [2] and test your application. You can report any bugs via bugs.java.com [3]. If you have any questions about whether a behavior is a bug or is expected, please ask on this alias or on the jigsaw-dev alias [4]. Thank you. -- Kevin [1] http://openjdk.java.net/projects/jdk9/ [2] https://jdk9.java.net/download/ [3] http://bugreport.java.com/ [4] jigsaw-dev at openjdk.java.net From David.Hill at Oracle.com Wed Jan 11 21:54:14 2017 From: David.Hill at Oracle.com (David Hill) Date: Wed, 11 Jan 2017 16:54:14 -0500 Subject: Review request: Fx applet fails to get loaded on Ubuntu with jre9-b150 Message-ID: <5876A986.8000600@Oracle.com> Kevin, Jim, please review: https://bugs.openjdk.java.net/browse/JDK-8171985 webrev: http://cr.openjdk.java.net/~ddhill/8171985.1 -- 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 Wed Jan 11 21:56:02 2017 From: james.graham at oracle.com (Jim Graham) Date: Wed, 11 Jan 2017 13:56:02 -0800 Subject: Review request: Fx applet fails to get loaded on Ubuntu with jre9-b150 In-Reply-To: <5876A986.8000600@Oracle.com> References: <5876A986.8000600@Oracle.com> Message-ID: <34426643-3311-52b0-6b08-14b02db797dc@oracle.com> This fails if the coordinate is not on any screen (screen will remain null). Also, spacing on the if statement at line 315... ...jim On 1/11/17 1:54 PM, David Hill wrote: > > > Kevin, Jim, > please review: > > https://bugs.openjdk.java.net/browse/JDK-8171985 > webrev: http://cr.openjdk.java.net/~ddhill/8171985.1 > > -- > 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 jonathan.giles at oracle.com Wed Jan 11 23:51:16 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 12 Jan 2017 12:51:16 +1300 Subject: [Review request] 8140504:TreeView/TreeTableView show "index exceeds maxCellCount" warning after scrolling Message-ID: <2530cb29-30af-e2bd-52ed-781b8ab244b7@oracle.com> Ajit, Ambarish, Please can you review the webrev and discussion at the following links: https://bugs.openjdk.java.net/browse/JDK-8140504 http://cr.openjdk.java.net/~jgiles/8140504/ Thanks! -- -- Jonathan From chris.bensen at oracle.com Thu Jan 12 01:36:57 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 11 Jan 2017 17:36:57 -0800 Subject: [9] Review request: 8171979 Missing/Renamed Modules in Redistributable list Message-ID: Victor, Please review this change to the redistributable module list. JIRA: https://bugs.openjdk.java.net/browse/JDK-8171979 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8171979/webrev.00/ Thanks, Chris From ambarish.rapte at oracle.com Thu Jan 12 12:28:19 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 12 Jan 2017 04:28:19 -0800 (PST) Subject: Review Request for: JDK-8171229: StringIndexOutOfBoundsException when programmatically replace text in TextArea Message-ID: <8e9db443-7dea-4a89-8c50-5dccf0bd61f0@default> Hi Jonathan, Can you please review the fix related to TextArea: Webrev: http://cr.openjdk.java.net/~arapte/fx/8171229/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8171229 Regards, Ambarish From kevin.rushforth at oracle.com Thu Jan 12 15:42:32 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Jan 2017 07:42:32 -0800 Subject: [9] Review request: 8172719: Build failure on Windows platform after fix for JDK-8172372 Message-ID: <5877A3E8.3060302@oracle.com> Need a quick review for: https://bugs.openjdk.java.net/browse/JDK-8172719 to fix the build on Windows. Diff is in the bug report. -- Kevin From james.graham at oracle.com Thu Jan 12 23:08:53 2017 From: james.graham at oracle.com (Jim Graham) Date: Thu, 12 Jan 2017 15:08:53 -0800 Subject: [8u] Review request for 8169777: MenuBar unoperable after moving Application to second monitor In-Reply-To: References: Message-ID: <466665d9-8181-b255-bd85-0683db724b4a@oracle.com> I was able to fix my Win7 permission problems and verify the fix on Windows 7 as well now... ...jim On 1/5/2017 5:16 PM, Jim Graham wrote: > This is essentially a backport request for the fix for JDK-8160073, but > a modification of the fix was needed as the code changed between 8u and 9. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8169777 > webrev: http://cr.openjdk.java.net/~flar/JDK-8169777/webrev.00/ > > I tested on Win10 and it works fine, though the platform support for DPI > scaling on Win8 (pre-8.1) and Win7 was different than their handling on > Win10 so a test run of the test case on Win7 and/or Win8.0 would be > helpful for sanity. Unfortunately my Win7 boot partition is buried in a > cesspool of permission issues trying to run the test build... :( > > ...jim From daniel.gloeckner at 360t.com Fri Jan 13 09:00:50 2017 From: daniel.gloeckner at 360t.com (=?iso-8859-1?Q?Daniel_Gl=F6ckner?=) Date: Fri, 13 Jan 2017 09:00:50 +0000 Subject: Bugs in TreeTableViewSkin. resizeColumnToFitContent() - labels always ellipsized Message-ID: <6D5AA6A29F1039459FDD3C00A9F5DE9801167ED0A5@eoffice-ex02.360t.com> Hi, we recently came across some limitations (you might call them bugs) in the tree table implementation. We were unhappy with the default behavior of the tree table implementation. Some columns were always ellipsized and the user would need to manually resize the column to fit the contests. After analysis it turned out that there are various bugs inTreeTableViewSkin. resizeColumnToFitContent(). We subclassed inTreeTableViewSkin and fixed that method (fortunately it's protected ;)). I'l explain the bugs below. Is anyone aware of an existing bug report for this issue? If we have a tree table where the first column contains long text (>80px) and is auto-resizable, then TreeTableViewSkin#resizeColumnToFitContent calculates the preferred width incorrectly and the label is ellipsized (because during layout phase, the calculations are performed in other way). We've found two reasons for that: 1. This method creates mocked cell and row. However for row: * TreeTableRow implementation is used and any custom factories are ignored * Cell is not added to row children. As a result if we have some padding in a cell, based on a row class (e.g..row-class > .cell { -fx-padding: 20px }), then this padding won't be considered while resizeColumnToFitContent 2. When width is calculated for a cell, there is a special method TreeTableCellSkin#leftLabelPadding, which makes offset for a label based on indentation and disclosure node size. However, at the time of calling resizeColumnToFitContent, disclosure size is considered 0 (it's stored in TableRowSkinBase#maxDisclosureWidthMap, which is filled only when row is layouting). One more note - during preferred width calculation, only expanded nodes are considered. This could be expected behaviour, however in some cases it makes sense to have it configurable and make the column suit even collapsed rows I'm keen to hear feedback from the community. We can also share our "fixed" skin which is a subclass of inTreeTableViewSkin. Kind regards, Daniel From ajit.ghaisas at oracle.com Fri Jan 13 11:55:12 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Fri, 13 Jan 2017 03:55:12 -0800 (PST) Subject: [9] Review request : JDK-8171071 : SplitPane is not visible after visible property changes Message-ID: <9dd7ed9a-f96d-42fe-9d1a-391973fdcdb5@default> Hi Jonathan, Request you to review following fix : In SplitPaneSkin class, layoutChildren logic is ignored in case visibility property is set to false. I have corrected this. Bug : https://bugs.openjdk.java.net/browse/JDK-8171071 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8171071/webrev.0/ Regards, Ajit From rahman.usta.88 at gmail.com Sat Jan 14 16:19:27 2017 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Sat, 14 Jan 2017 19:19:27 +0300 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <5876840F.40508@oracle.com> References: <5876840F.40508@oracle.com> Message-ID: Hello Kevin, I try to run AsciidocFX with latest JDK 9 EA. AsciidocFX uses FXForm2 project and while building I get the following error. Exception in thread "JavaFX Application Thread" java.lang.NoClassDefFoundError: javafx/scene/layout/GridPaneBuilder at com.dooapp.fxform.view.skin.InlineSkin.createRootNode(InlineSkin.java:69) at com.dooapp.fxform.view.FXFormSkin.buildNode(FXFormSkin.java:101) at com.dooapp.fxform.view.FXFormSkin.(FXFormSkin.java:96) at com.dooapp.fxform.view.skin.InlineSkin.(InlineSkin.java:44) at com.dooapp.fxform.builder.FXFormBuilder.handleDefaultSkin(FXFormBuilder.java:123) at com.dooapp.fxform.builder.FXFormBuilder.build(FXFormBuilder.java:82) at com.kodcu.config.EditorConfigBean.createForm(EditorConfigBean.java:354) Was the GridPaneBuilder removed from JDK 9 ? Thanks. 2017-01-11 22:14 GMT+03:00 Kevin Rushforth : > As you may know JDK 9 has hit the feature extension complete milestone > [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need > to know about them in order to fix them. Our focus will be on bugs that are > new in JDK 9 (regressions). > > I ask all JavaFX developers to please download JDK 9 early access [2] and > test your application. You can report any bugs via bugs.java.com [3]. If > you have any questions about whether a behavior is a bug or is expected, > please ask on this alias or on the jigsaw-dev alias [4]. > > Thank you. > > -- Kevin > > [1] http://openjdk.java.net/projects/jdk9/ > [2] https://jdk9.java.net/download/ > [3] http://bugreport.java.com/ > [4] jigsaw-dev at openjdk.java.net > > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From kevin.rushforth at oracle.com Sat Jan 14 16:33:52 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 14 Jan 2017 08:33:52 -0800 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: References: <5876840F.40508@oracle.com> Message-ID: <587A52F0.5020401@oracle.com> The deprecated builders were removed from 9 early in the JDK 9 development cycle [1][2]. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8092861 [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-January/016496.html Rahman USTA wrote: > Hello Kevin, > > I try to run AsciidocFX with latest JDK 9 EA. AsciidocFX uses FXForm2 > project and while building I get the following error. > > Exception in thread "JavaFX Application Thread" > java.lang.NoClassDefFoundError: javafx/scene/layout/GridPaneBuilder > at > com.dooapp.fxform.view.skin.InlineSkin.createRootNode(InlineSkin.java:69) > at > com.dooapp.fxform.view.FXFormSkin.buildNode(FXFormSkin.java:101) > at com.dooapp.fxform.view.FXFormSkin.(FXFormSkin.java:96) > at > com.dooapp.fxform.view.skin.InlineSkin.(InlineSkin.java:44) > at > com.dooapp.fxform.builder.FXFormBuilder.handleDefaultSkin(FXFormBuilder.java:123) > at > com.dooapp.fxform.builder.FXFormBuilder.build(FXFormBuilder.java:82) > at > com.kodcu.config.EditorConfigBean.createForm(EditorConfigBean.java:354) > > Was the GridPaneBuilder removed from JDK 9 ? > > Thanks. > > 2017-01-11 22:14 GMT+03:00 Kevin Rushforth >: > > As you may know JDK 9 has hit the feature extension complete > milestone [1]. We still have a small number of weeks to fix P1-P3 > bugs, but we need to know about them in order to fix them. Our > focus will be on bugs that are new in JDK 9 (regressions). > > I ask all JavaFX developers to please download JDK 9 early access > [2] and test your application. You can report any bugs via > bugs.java.com [3]. If you have any > questions about whether a behavior is a bug or is expected, please > ask on this alias or on the jigsaw-dev alias [4]. > > Thank you. > > -- Kevin > > [1] http://openjdk.java.net/projects/jdk9/ > > [2] https://jdk9.java.net/download/ > [3] http://bugreport.java.com/ > [4] jigsaw-dev at openjdk.java.net > > > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta From rahman.usta.88 at gmail.com Sat Jan 14 16:34:54 2017 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Sat, 14 Jan 2017 19:34:54 +0300 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <587A52F0.5020401@oracle.com> References: <5876840F.40508@oracle.com> <587A52F0.5020401@oracle.com> Message-ID: Thank you Kevin, after looking inside I see it. Right now, I will do a pull request for it. -- Rahman 2017-01-14 19:33 GMT+03:00 Kevin Rushforth : > The deprecated builders were removed from 9 early in the JDK 9 development > cycle [1][2]. > > -- Kevin > > [1] https://bugs.openjdk.java.net/browse/JDK-8092861 > [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015- > January/016496.html > > > > Rahman USTA wrote: > > Hello Kevin, > > I try to run AsciidocFX with latest JDK 9 EA. AsciidocFX uses FXForm2 > project and while building I get the following error. > > Exception in thread "JavaFX Application Thread" java.lang.NoClassDefFoundError: > javafx/scene/layout/GridPaneBuilder > at com.dooapp.fxform.view.skin.InlineSkin.createRootNode( > InlineSkin.java:69) > at com.dooapp.fxform.view.FXFormSkin.buildNode( > FXFormSkin.java:101) > at com.dooapp.fxform.view.FXFormSkin.(FXFormSkin.java:96) > at com.dooapp.fxform.view.skin.InlineSkin.(InlineSkin. > java:44) > at com.dooapp.fxform.builder.FXFormBuilder.handleDefaultSkin( > FXFormBuilder.java:123) > at com.dooapp.fxform.builder.FXFormBuilder.build( > FXFormBuilder.java:82) > at com.kodcu.config.EditorConfigBean.createForm( > EditorConfigBean.java:354) > > Was the GridPaneBuilder removed from JDK 9 ? > > Thanks. > > 2017-01-11 22:14 GMT+03:00 Kevin Rushforth : > >> As you may know JDK 9 has hit the feature extension complete milestone >> [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need >> to know about them in order to fix them. Our focus will be on bugs that are >> new in JDK 9 (regressions). >> >> I ask all JavaFX developers to please download JDK 9 early access [2] and >> test your application. You can report any bugs via bugs.java.com [3]. If >> you have any questions about whether a behavior is a bug or is expected, >> please ask on this alias or on the jigsaw-dev alias [4]. >> >> Thank you. >> >> -- Kevin >> >> [1] http://openjdk.java.net/projects/jdk9/ >> [2] https://jdk9.java.net/download/ >> [3] http://bugreport.java.com/ >> [4] jigsaw-dev at openjdk.java.net >> >> > > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta > > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From tbee at tbee.org Sat Jan 14 20:26:42 2017 From: tbee at tbee.org (Tom Eugelink) Date: Sat, 14 Jan 2017 21:26:42 +0100 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <5876840F.40508@oracle.com> References: <5876840F.40508@oracle.com> Message-ID: <87d2c955-2b0d-19d9-83d0-a1a30aca3488@tbee.org> On 11-1-2017 20:14, Kevin Rushforth wrote: > As you may know JDK 9 has hit the feature extension complete milestone [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need to know about them in order to fix them. Our focus will be on bugs that are new in JDK 9 (regressions). > > I ask all JavaFX developers to please download JDK 9 early access [2] and test your application. You can report any bugs via bugs.java.com [3]. If you have any questions about whether a behavior is a bug or is expected, please ask on this alias or on the jigsaw-dev alias [4]. Not sure if I'm allowed to ask here because it is a Gradle problem, but since JavaFX is also build using Gradle: I'm not even getting JFXtras to start compiling with Gradle 3.3 because of: /"java.lang.reflect.InaccessibleObjectException: Unable to make protected java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module java.base does not "opens java.lang" to unnamed module @aa1f72z" /Probably related to: https://issues.gradle.org/browse/GRADLE-3565 Having a basic understand on jigsaw and decent google skills I've gathered that this is a module configuration problem, and that it should be solvable by adding to gradle.properties: /org.gradle.jvmargs=//--add-opens java.base/java.lang=ALL-UNNAMED /But alas... Any pointers? Tom From vadim.pakhnushev at oracle.com Sat Jan 14 20:37:07 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sat, 14 Jan 2017 23:37:07 +0300 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <87d2c955-2b0d-19d9-83d0-a1a30aca3488@tbee.org> References: <5876840F.40508@oracle.com> <87d2c955-2b0d-19d9-83d0-a1a30aca3488@tbee.org> Message-ID: Tom, In JavaFX we use _JAVA_OPTIONS environment variable to workaround this: http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-December/020077.html Note that if you are building on Windows without Cygwin, you need to remove quotes. Vadim On 14.01.2017 23:26, Tom Eugelink wrote: > On 11-1-2017 20:14, Kevin Rushforth wrote: >> As you may know JDK 9 has hit the feature extension complete >> milestone [1]. We still have a small number of weeks to fix P1-P3 >> bugs, but we need to know about them in order to fix them. Our focus >> will be on bugs that are new in JDK 9 (regressions). >> >> I ask all JavaFX developers to please download JDK 9 early access [2] >> and test your application. You can report any bugs via bugs.java.com >> [3]. If you have any questions about whether a behavior is a bug or >> is expected, please ask on this alias or on the jigsaw-dev alias [4]. > > Not sure if I'm allowed to ask here because it is a Gradle problem, > but since JavaFX is also build using Gradle: I'm not even getting > JFXtras to start compiling with Gradle 3.3 because of: > /"java.lang.reflect.InaccessibleObjectException: Unable to make > protected java.lang.Package[] java.lang.ClassLoader.getPackages() > accessible: module java.base does not "opens java.lang" to unnamed > module @aa1f72z" > /Probably related to: https://issues.gradle.org/browse/GRADLE-3565 > > Having a basic understand on jigsaw and decent google skills I've > gathered that this is a module configuration problem, and that it > should be solvable by adding to gradle.properties: > /org.gradle.jvmargs=//--add-opens java.base/java.lang=ALL-UNNAMED > > /But alas... > > Any pointers? > > Tom From tbee at tbee.org Sun Jan 15 09:04:03 2017 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 15 Jan 2017 10:04:03 +0100 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: References: <5876840F.40508@oracle.com> <87d2c955-2b0d-19d9-83d0-a1a30aca3488@tbee.org> Message-ID: <11af5014-22f1-a203-818c-b799e32b23d7@tbee.org> That indeed works, thanks Vadim. And of course my approach does not work because the gradle.properties are read after its JVM has already started. Onwards. Tom On 14-1-2017 21:37, Vadim Pakhnushev wrote: > Tom, > > In JavaFX we use _JAVA_OPTIONS environment variable to workaround this: > http://mail.openjdk.java.net/pipermail/openjfx-dev/2016-December/020077.html > Note that if you are building on Windows without Cygwin, you need to remove quotes. > > Vadim > > On 14.01.2017 23:26, Tom Eugelink wrote: >> On 11-1-2017 20:14, Kevin Rushforth wrote: >>> As you may know JDK 9 has hit the feature extension complete milestone [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need to know about them in order to fix them. Our focus will be on bugs that are new in JDK 9 (regressions). >>> >>> I ask all JavaFX developers to please download JDK 9 early access [2] and test your application. You can report any bugs via bugs.java.com [3]. If you have any questions about whether a behavior is a bug or is expected, please ask on this alias or on the jigsaw-dev alias [4]. >> >> Not sure if I'm allowed to ask here because it is a Gradle problem, but since JavaFX is also build using Gradle: I'm not even getting JFXtras to start compiling with Gradle 3.3 because of: >> /"java.lang.reflect.InaccessibleObjectException: Unable to make protected java.lang.Package[] java.lang.ClassLoader.getPackages() accessible: module java.base does not "opens java.lang" to unnamed module @aa1f72z" >> /Probably related to: https://issues.gradle.org/browse/GRADLE-3565 >> >> Having a basic understand on jigsaw and decent google skills I've gathered that this is a module configuration problem, and that it should be solvable by adding to gradle.properties: >> /org.gradle.jvmargs=//--add-opens java.base/java.lang=ALL-UNNAMED >> >> /But alas... >> >> Any pointers? >> >> Tom > From murali.billa at oracle.com Mon Jan 16 09:28:57 2017 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 16 Jan 2017 01:28:57 -0800 (PST) Subject: [9] Review request for 8164914: Validation of WebSQL Support in Webkit In-Reply-To: <4e8a047a-3bf0-433c-94a3-b5c996421185@default> 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-8164914 JIRA: https://bugs.openjdk.java.net/browse/JDK-8164914 ? Webrev: http://cr.openjdk.java.net/~mbilla/8164914/webrev.02/ ? Thanks, Murali From murali.billa at oracle.com Mon Jan 16 16:37:18 2017 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 16 Jan 2017 08:37:18 -0800 (PST) Subject: [9] Review request for 8172694: JSCallbackMemoryTest fails intermittently 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-8172694 JIRA: https://bugs.openjdk.java.net/browse/JDK-8172694 ? Webrev: http://cr.openjdk.java.net/~mbilla/8172694/webrev.00/ ? Thanks, Murali From tbee at tbee.org Mon Jan 16 21:00:21 2017 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 16 Jan 2017 22:00:21 +0100 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <5876840F.40508@oracle.com> References: <5876840F.40508@oracle.com> Message-ID: <523663eb-b101-ecd1-d8bc-646732b44da1@tbee.org> One of the methods I use a lot in Tests, to make sure something has happened, is: runAndWait( () -> Platform.firePulse() ); firePulse no longer exists. Is there a replacement? The rest seems to compile ok. But I cannot run the tests ATM. On 11-1-2017 20:14, Kevin Rushforth wrote: > As you may know JDK 9 has hit the feature extension complete milestone [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need to know about them in order to fix them. Our focus will be on bugs that are new in JDK 9 (regressions). > > I ask all JavaFX developers to please download JDK 9 early access [2] and test your application. You can report any bugs via bugs.java.com [3]. If you have any questions about whether a behavior is a bug or is expected, please ask on this alias or on the jigsaw-dev alias [4]. > > Thank you. > > -- Kevin > > [1] http://openjdk.java.net/projects/jdk9/ > [2] https://jdk9.java.net/download/ > [3] http://bugreport.java.com/ > [4] jigsaw-dev at openjdk.java.net > From jonathan.giles at oracle.com Mon Jan 16 21:10:47 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 17 Jan 2017 10:10:47 +1300 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <523663eb-b101-ecd1-d8bc-646732b44da1@tbee.org> References: <5876840F.40508@oracle.com> <523663eb-b101-ecd1-d8bc-646732b44da1@tbee.org> Message-ID: <4ccbd394-4335-0809-27a1-9af95f1bf3fa@oracle.com> Platform.firePulse() never existed, you're probably thinking of Toolkit.firePulse() (which is not public API)? A close replacement is Platform.requestNextPulse(). -- Jonathan On 17/01/17 10:00 AM, Tom Eugelink wrote: > One of the methods I use a lot in Tests, to make sure something has > happened, is: > runAndWait( () -> Platform.firePulse() ); > > firePulse no longer exists. Is there a replacement? > > The rest seems to compile ok. But I cannot run the tests ATM. > > > > > > On 11-1-2017 20:14, Kevin Rushforth wrote: >> As you may know JDK 9 has hit the feature extension complete >> milestone [1]. We still have a small number of weeks to fix P1-P3 >> bugs, but we need to know about them in order to fix them. Our focus >> will be on bugs that are new in JDK 9 (regressions). >> >> I ask all JavaFX developers to please download JDK 9 early access [2] >> and test your application. You can report any bugs via bugs.java.com >> [3]. If you have any questions about whether a behavior is a bug or >> is expected, please ask on this alias or on the jigsaw-dev alias [4]. >> >> Thank you. >> >> -- Kevin >> >> [1] http://openjdk.java.net/projects/jdk9/ >> [2] https://jdk9.java.net/download/ >> [3] http://bugreport.java.com/ >> [4] jigsaw-dev at openjdk.java.net >> > From jonathan.giles at oracle.com Mon Jan 16 21:15:04 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 17 Jan 2017 10:15:04 +1300 Subject: Bugs in TreeTableViewSkin. resizeColumnToFitContent() - labels always ellipsized In-Reply-To: <6D5AA6A29F1039459FDD3C00A9F5DE9801167ED0A5@eoffice-ex02.360t.com> References: <6D5AA6A29F1039459FDD3C00A9F5DE9801167ED0A5@eoffice-ex02.360t.com> Message-ID: <1fe21878-40bc-815c-a0ad-63de6412e93a@oracle.com> As far as I can recall there are no bug reports on this issue. Please do file them so that TreeTableView can be improved. Thanks. -- Jonathan On 13/01/17 10:00 PM, Daniel Gl?ckner wrote: > Hi, > > we recently came across some limitations (you might call them bugs) in the tree table implementation. > > We were unhappy with the default behavior of the tree table implementation. Some columns were always ellipsized and the user would need to manually resize the column to fit the contests. > > After analysis it turned out that there are various bugs inTreeTableViewSkin. resizeColumnToFitContent(). We subclassed inTreeTableViewSkin and fixed that method (fortunately it's protected ;)). > > I'l explain the bugs below. Is anyone aware of an existing bug report for this issue? > > If we have a tree table where the first column contains long text (>80px) and is auto-resizable, then TreeTableViewSkin#resizeColumnToFitContent calculates the preferred width incorrectly and the label is ellipsized (because during layout phase, the calculations are performed in other way). We've found two reasons for that: > 1. This method creates mocked cell and row. However for row: > * TreeTableRow implementation is used and any custom factories are ignored > * Cell is not added to row children. As a result if we have some padding in a cell, based on a row class (e.g..row-class > .cell { -fx-padding: 20px }), then this padding won't be considered while resizeColumnToFitContent > 2. When width is calculated for a cell, there is a special method TreeTableCellSkin#leftLabelPadding, which makes offset for a label based on indentation and disclosure node size. However, at the time of calling resizeColumnToFitContent, disclosure size is considered 0 (it's stored in TableRowSkinBase#maxDisclosureWidthMap, which is filled only when row is layouting). > > One more note - during preferred width calculation, only expanded nodes are considered. This could be expected behaviour, however in some cases it makes sense to have it configurable and make the column suit even collapsed rows > > I'm keen to hear feedback from the community. We can also share our "fixed" skin which is a subclass of inTreeTableViewSkin. > > Kind regards, > Daniel From kevin.rushforth at oracle.com Tue Jan 17 13:41:49 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Jan 2017 05:41:49 -0800 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <4ccbd394-4335-0809-27a1-9af95f1bf3fa@oracle.com> References: <5876840F.40508@oracle.com> <523663eb-b101-ecd1-d8bc-646732b44da1@tbee.org> <4ccbd394-4335-0809-27a1-9af95f1bf3fa@oracle.com> Message-ID: <587E1F1D.9010804@oracle.com> Exactly. I would add that any tests that need Robot or PerformanceTracker will need to use "--add-exports" to add the necessary qualified exports on the command line as there is no public API for those. -- Kevin Jonathan Giles wrote: > Platform.firePulse() never existed, you're probably thinking of > Toolkit.firePulse() (which is not public API)? > > A close replacement is Platform.requestNextPulse(). > > -- Jonathan > > On 17/01/17 10:00 AM, Tom Eugelink wrote: >> One of the methods I use a lot in Tests, to make sure something has >> happened, is: >> runAndWait( () -> Platform.firePulse() ); >> >> firePulse no longer exists. Is there a replacement? >> >> The rest seems to compile ok. But I cannot run the tests ATM. >> >> >> >> >> >> On 11-1-2017 20:14, Kevin Rushforth wrote: >>> As you may know JDK 9 has hit the feature extension complete >>> milestone [1]. We still have a small number of weeks to fix P1-P3 >>> bugs, but we need to know about them in order to fix them. Our focus >>> will be on bugs that are new in JDK 9 (regressions). >>> >>> I ask all JavaFX developers to please download JDK 9 early access >>> [2] and test your application. You can report any bugs via >>> bugs.java.com [3]. If you have any questions about whether a >>> behavior is a bug or is expected, please ask on this alias or on the >>> jigsaw-dev alias [4]. >>> >>> Thank you. >>> >>> -- Kevin >>> >>> [1] http://openjdk.java.net/projects/jdk9/ >>> [2] https://jdk9.java.net/download/ >>> [3] http://bugreport.java.com/ >>> [4] jigsaw-dev at openjdk.java.net >>> >> > From alexander.zvegintsev at oracle.com Tue Jan 17 15:39:58 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Tue, 17 Jan 2017 18:39:58 +0300 Subject: [9] Review request for 8166106: JVM crash on resizing JavaFX application with title and icon Message-ID: <0a387bf6-6fa1-2ee1-11e8-a4b1f7497945@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8166106/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8166106 -- Thanks, Alexander. From murali.billa at oracle.com Tue Jan 17 19:01:48 2017 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 17 Jan 2017 11:01:48 -0800 (PST) Subject: [9] Review request for 8162922: JavaFx WebView canvas doesn't support dash within strokeRec 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: <23511577-a460-4df1-9b40-d9caf00760db@default> ? Hi Kevin, Arun, Guru, Please review the fix for ? JDK-8162922. JIRA: https://bugs.openjdk.java.net/browse/JDK-8162922 ? Webrev: http://cr.openjdk.java.net/~mbilla/8162922/webrev.00/ ? Thanks, Murali From kevin.rushforth at oracle.com Tue Jan 17 20:48:10 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Jan 2017 12:48:10 -0800 Subject: Changes for January 2017 CPU release (8u121) synced into FX 8u-dev and 9-dev Message-ID: <587E830A.5030703@oracle.com> I have synced the OpenJFX changes from the just-released January 2017 CPU release (8u121) into 8u and into 9. Here is a webrev of the FX 8u121 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/8u121-8u-sync/webrev/ The webrev for 9 is similar except for the .hgtags (which are unmodified in 9) and a couple Makefile changes, but here it is if anyone is interested: http://cr.openjdk.java.net/~kcr/9-cpu-1701-sync/webrev/ -- Kevin From chris.bensen at oracle.com Tue Jan 17 23:51:00 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 17 Jan 2017 15:51:00 -0800 Subject: [9] Review request: 8172925 Mac App Store Message-ID: Victor, Please review the first pass at the Mac App Store changes. JIRA: https://bugs.openjdk.java.net/browse/JDK-8172925 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8172925/webrev.00/ Thanks, Chris From victor.drozdov at oracle.com Wed Jan 18 15:09:31 2017 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Wed, 18 Jan 2017 18:09:31 +0300 Subject: [9] Review request: JDK-8172906: Remove closed modules from Redistributable List Message-ID: <367873a4-1f29-b064-52c7-20b8c91743aa@oracle.com> Chris, Please review the changes about removing closed modules from redistributable.list JIRA: https://bugs.openjdk.java.net/browse/JDK-8172906 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8172906/webrev.00/ --Victor From chris.bensen at oracle.com Wed Jan 18 18:53:57 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 18 Jan 2017 10:53:57 -0800 Subject: [9] Review request: 8172985 Executable files in repo after JDK-8172925 Message-ID: <89E1AF0A-0228-4BED-BB4A-D2C82FF69B30@oracle.com> Kevin, Please review my fixing my mistake. JIRA: https://bugs.openjdk.java.net/browse/JDK-8172985 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8172985/webrev.00/ Chris From kevin.rushforth at oracle.com Wed Jan 18 20:49:42 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Jan 2017 12:49:42 -0800 Subject: [9] Review request: 8172988: gradle :web:test should run in headless mode Message-ID: <587FD4E6.6080406@oracle.com> Hi Dave & Chien, Please review the following test fix: https://bugs.openjdk.java.net/browse/JDK-8172988 It fixes a regression in the build script so we will once again run web tests in headless mode. The patch is in the JBS issue. -- Kevin From kevin.rushforth at oracle.com Wed Jan 18 21:53:58 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Jan 2017 13:53:58 -0800 Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar Message-ID: <587FE3F6.2050000@oracle.com> I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. Ramesh is a member of JavaFX SQE team at Oracle working on test development for the Java packager, who has contributed 20 changesets to OpenJFX, at least 8 of which [5] are significant. Votes are due by February 1, 2017. Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. Thanks, -- Kevin [1] http://openjdk.java.net/census#rgangadhar [2] http://openjdk.java.net/census#openjfx [3] http://openjdk.java.net/bylaws#lazy-consensus [4] http://openjdk.java.net/projects#project-committer [5] List of significant changesets: http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 From kevin.rushforth at oracle.com Wed Jan 18 21:55:07 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Jan 2017 13:55:07 -0800 Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <587FE3F6.2050000@oracle.com> References: <587FE3F6.2050000@oracle.com> Message-ID: <587FE43B.5090608@oracle.com> Vote: YES Kevin Rushforth wrote: > I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. > > Ramesh is a member of JavaFX SQE team at Oracle working on test > development for the Java packager, who has contributed 20 changesets > to OpenJFX, at least 8 of which [5] are significant. > > Votes are due by February 1, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks, > > -- Kevin > > > [1] http://openjdk.java.net/census#rgangadhar > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of significant changesets: > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 > From chris.bensen at oracle.com Wed Jan 18 22:10:34 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 18 Jan 2017 14:10:34 -0800 Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <587FE3F6.2050000@oracle.com> References: <587FE3F6.2050000@oracle.com> Message-ID: <47E75143-B2F6-4F52-A22E-65E42554C43A@oracle.com> Not: YES > On Jan 18, 2017, at 1:53 PM, Kevin Rushforth wrote: > > I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. > > Ramesh is a member of JavaFX SQE team at Oracle working on test development for the Java packager, who has contributed 20 changesets to OpenJFX, at least 8 of which [5] are significant. > > Votes are due by February 1, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. > > Thanks, > > -- Kevin > > > [1] http://openjdk.java.net/census#rgangadhar > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of significant changesets: > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 > From chris.bensen at oracle.com Wed Jan 18 22:22:08 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 18 Jan 2017 14:22:08 -0800 Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <47E75143-B2F6-4F52-A22E-65E42554C43A@oracle.com> References: <587FE3F6.2050000@oracle.com> <47E75143-B2F6-4F52-A22E-65E42554C43A@oracle.com> Message-ID: <252E6EA5-CB0A-4870-A2C5-025423833276@oracle.com> Correct: Vote: YES > On Jan 18, 2017, at 2:10 PM, Chris Bensen wrote: > > Not: YES > > >> On Jan 18, 2017, at 1:53 PM, Kevin Rushforth wrote: >> >> I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. >> >> Ramesh is a member of JavaFX SQE team at Oracle working on test development for the Java packager, who has contributed 20 changesets to OpenJFX, at least 8 of which [5] are significant. >> >> Votes are due by February 1, 2017. >> >> Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. >> >> Thanks, >> >> -- Kevin >> >> >> [1] http://openjdk.java.net/census#rgangadhar >> >> [2] http://openjdk.java.net/census#openjfx >> >> [3] http://openjdk.java.net/bylaws#lazy-consensus >> >> [4] http://openjdk.java.net/projects#project-committer >> >> [5] List of significant changesets: >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 >> http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 >> > From david.dehaven at oracle.com Wed Jan 18 22:36:04 2017 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 18 Jan 2017 14:36:04 -0800 Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <587FE3F6.2050000@oracle.com> References: <587FE3F6.2050000@oracle.com> Message-ID: Vote: Yes -DrD- > On Jan 18, 2017, at 1:53 PM, Kevin Rushforth wrote: > > I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. > > Ramesh is a member of JavaFX SQE team at Oracle working on test development for the Java packager, who has contributed 20 changesets to OpenJFX, at least 8 of which [5] are significant. > > Votes are due by February 1, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. > > Thanks, > > -- Kevin > > > [1] http://openjdk.java.net/census#rgangadhar > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of significant changesets: > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 > From tom.schindl at bestsolution.at Wed Jan 18 23:00:39 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 19 Jan 2017 00:00:39 +0100 Subject: Impossible to implement custom control with a StyleableObjectProperty on JavaFX9 Message-ID: Hi, As JavaFX9 has removed impl_reapplyCss() it is impossible for custom controls to deal with a styleable Font-Property. To correctly implement a Font-Property the code needs to look similar to the one in Labeled#fontProperty. The only possibility I see implementing such a property without providing reapplyCss() to the public is to provide a correct implementation as part of StyleablePropertyFactory. Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From jonathan.giles at oracle.com Wed Jan 18 23:09:50 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 19 Jan 2017 12:09:50 +1300 Subject: Impossible to implement custom control with a StyleableObjectProperty on JavaFX9 In-Reply-To: References: Message-ID: This sounds like a reasonable issue to discuss a resolution for. Can you please file a Jira issue and we can look into our options (either making a reapplyCss() method available, or following something along the lines of your suggestion)? Also, thanks for taking the time to test JDK 9 - this is exactly the kind of feedback we need. -- Jonathan On 19/01/17 12:00 PM, Tom Schindl wrote: > Hi, > > As JavaFX9 has removed impl_reapplyCss() it is impossible for custom > controls to deal with a styleable Font-Property. > > To correctly implement a Font-Property the code needs to look similar to > the one in Labeled#fontProperty. The only possibility I see implementing > such a property without providing reapplyCss() to the public is to > provide a correct implementation as part of StyleablePropertyFactory. > > Tom > From arunprasad.rajkumar at oracle.com Thu Jan 19 06:32:15 2017 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Thu, 19 Jan 2017 12:02:15 +0530 Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <587FE3F6.2050000@oracle.com> References: <587FE3F6.2050000@oracle.com> Message-ID: <0DD0B5E9-3481-40D2-A6DA-18BD796D73F2@oracle.com> Vote: YES > On 19-Jan-2017, at 3:23 AM, Kevin Rushforth wrote: > > I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. > > Ramesh is a member of JavaFX SQE team at Oracle working on test development for the Java packager, who has contributed 20 changesets to OpenJFX, at least 8 of which [5] are significant. > > Votes are due by February 1, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. > > Thanks, > > -- Kevin > > > [1] http://openjdk.java.net/census#rgangadhar > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of significant changesets: > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 > From murali.billa at oracle.com Thu Jan 19 06:34:40 2017 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 18 Jan 2017 22:34:40 -0800 (PST) Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <587FE3F6.2050000@oracle.com> References: <587FE3F6.2050000@oracle.com> Message-ID: Vote: YES -----Original Message----- From: Kevin Rushforth Sent: Thursday, January 19, 2017 3:24 AM To: Ramesh Gangadhar; openjfx-dev at openjdk.java.net Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. Ramesh is a member of JavaFX SQE team at Oracle working on test development for the Java packager, who has contributed 20 changesets to OpenJFX, at least 8 of which [5] are significant. Votes are due by February 1, 2017. Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. Thanks, -- Kevin [1] http://openjdk.java.net/census#rgangadhar [2] http://openjdk.java.net/census#openjfx [3] http://openjdk.java.net/bylaws#lazy-consensus [4] http://openjdk.java.net/projects#project-committer [5] List of significant changesets: http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 From a.ankit.srivastava at oracle.com Thu Jan 19 06:37:47 2017 From: a.ankit.srivastava at oracle.com (Ankit Srivastava) Date: Wed, 18 Jan 2017 22:37:47 -0800 (PST) Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <587FE3F6.2050000@oracle.com> References: <587FE3F6.2050000@oracle.com> Message-ID: Yes.. -----Original Message----- From: Kevin Rushforth Sent: Thursday, January 19, 2017 3:24 AM To: Ramesh Gangadhar; openjfx-dev at openjdk.java.net Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. Ramesh is a member of JavaFX SQE team at Oracle working on test development for the Java packager, who has contributed 20 changesets to OpenJFX, at least 8 of which [5] are significant. Votes are due by February 1, 2017. Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. Thanks, -- Kevin [1] http://openjdk.java.net/census#rgangadhar [2] http://openjdk.java.net/census#openjfx [3] http://openjdk.java.net/bylaws#lazy-consensus [4] http://openjdk.java.net/projects#project-committer [5] List of significant changesets: http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 From vadim.pakhnushev at oracle.com Thu Jan 19 08:29:56 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Thu, 19 Jan 2017 11:29:56 +0300 Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <587FE3F6.2050000@oracle.com> References: <587FE3F6.2050000@oracle.com> Message-ID: <08aa40ee-b4ac-9e99-e0aa-baaba0ac65b3@oracle.com> Vote: yes On 19.01.2017 0:53, Kevin Rushforth wrote: > I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. > > Ramesh is a member of JavaFX SQE team at Oracle working on test > development for the Java packager, who has contributed 20 changesets > to OpenJFX, at least 8 of which [5] are significant. > > Votes are due by February 1, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks, > > -- Kevin > > > [1] http://openjdk.java.net/census#rgangadhar > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of significant changesets: > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 > From alexander.zvegintsev at oracle.com Thu Jan 19 13:20:43 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 19 Jan 2017 16:20:43 +0300 Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <587FE3F6.2050000@oracle.com> References: <587FE3F6.2050000@oracle.com> Message-ID: <22001d67-db03-b5e7-f29e-04d82106cf18@oracle.com> Vote: yes Thanks, Alexander. On 19/01/2017 00:53, Kevin Rushforth wrote: > I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. > > Ramesh is a member of JavaFX SQE team at Oracle working on test > development for the Java packager, who has contributed 20 changesets > to OpenJFX, at least 8 of which [5] are significant. > > Votes are due by February 1, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a > project Committer is described in [4]. > > Thanks, > > -- Kevin > > > [1] http://openjdk.java.net/census#rgangadhar > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of significant changesets: > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 > From chris.bensen at oracle.com Thu Jan 19 19:46:16 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 19 Jan 2017 11:46:16 -0800 Subject: [9] Review request: 8171811 References to ant-javafx.jar Message-ID: <67769F18-6D4E-4D21-9B56-DBBDC7478324@oracle.com> Victor, Please review these string changes to remove ant-javafx.jar from the error messages where they shouldn?t be. JIRA: https://bugs.openjdk.java.net/browse/JDK-8171811 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8171811/webrev.00/ Chris From jonnyheggheim at sigaint.org Fri Jan 20 00:04:00 2017 From: jonnyheggheim at sigaint.org (Jonny Heggheim) Date: Fri, 20 Jan 2017 00:04:00 +0000 Subject: Fedora RPM package Message-ID: <0dd37b6d-2ab1-45a8-f733-17d2bd0602e3@sigaint.org> Hi! My name is Jonny Heggheim and I am a packager for Fedora[1]. I would like to include OpenJFX in our official Fedora repository to make it possible to redistribute packages that depend on JavaFX. There have been a discussion for several years[2] and I have started on a RPM package based on the work of other. Those of you who run Fedora can test these builds today by installing from COPR[3]. Are there applications/workflows that you recommend that I run to verify that the installation work? Are there anyone running Fedora that can provide feedback before we publish RPM packages? Currently we do not build with media or webkit support, will that cause big problems? Can you redirect me to details about the licenses? The LICENSE file states GPL v2 with exceptions, but I have found other bundled libraries with different license. Sincerely Jonny Heggheim [1] https://fedoraproject.org/wiki/User:Jonny [2] https://bugzilla.redhat.com/show_bug.cgi?id=1145303 [3] https://copr.fedorainfracloud.org/coprs/jonny/openjfx/ From tom.schindl at bestsolution.at Fri Jan 20 08:16:12 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 20 Jan 2017 09:16:12 +0100 Subject: Impossible to implement custom control with a StyleableObjectProperty on JavaFX9 In-Reply-To: References: Message-ID: <6bd48118-605b-6cad-125c-c4d7677230d6@bestsolution.at> https://bugs.openjdk.java.net/browse/JDK-8102126 Tom On 19.01.17 00:09, Jonathan Giles wrote: > This sounds like a reasonable issue to discuss a resolution for. Can you > please file a Jira issue and we can look into our options (either making > a reapplyCss() method available, or following something along the lines > of your suggestion)? > > Also, thanks for taking the time to test JDK 9 - this is exactly the > kind of feedback we need. > > -- Jonathan > > On 19/01/17 12:00 PM, Tom Schindl wrote: >> Hi, >> >> As JavaFX9 has removed impl_reapplyCss() it is impossible for custom >> controls to deal with a styleable Font-Property. >> >> To correctly implement a Font-Property the code needs to look similar to >> the one in Labeled#fontProperty. The only possibility I see implementing >> such a property without providing reapplyCss() to the public is to >> provide a correct implementation as part of StyleablePropertyFactory. >> >> Tom >> > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tom.schindl at bestsolution.at Fri Jan 20 08:23:07 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 20 Jan 2017 09:23:07 +0100 Subject: Impossible to implement custom control with a StyleableObjectProperty on JavaFX9 In-Reply-To: <6bd48118-605b-6cad-125c-c4d7677230d6@bestsolution.at> References: <6bd48118-605b-6cad-125c-c4d7677230d6@bestsolution.at> Message-ID: Hi, naturally it is https://bugs.openjdk.java.net/browse/JDK-8173103 Tom On 20.01.17 09:16, Tom Schindl wrote: > https://bugs.openjdk.java.net/browse/JDK-8102126 > > Tom > > On 19.01.17 00:09, Jonathan Giles wrote: >> This sounds like a reasonable issue to discuss a resolution for. Can you >> please file a Jira issue and we can look into our options (either making >> a reapplyCss() method available, or following something along the lines >> of your suggestion)? >> >> Also, thanks for taking the time to test JDK 9 - this is exactly the >> kind of feedback we need. >> >> -- Jonathan >> >> On 19/01/17 12:00 PM, Tom Schindl wrote: >>> Hi, >>> >>> As JavaFX9 has removed impl_reapplyCss() it is impossible for custom >>> controls to deal with a styleable Font-Property. >>> >>> To correctly implement a Font-Property the code needs to look similar to >>> the one in Labeled#fontProperty. The only possibility I see implementing >>> such a property without providing reapplyCss() to the public is to >>> provide a correct implementation as part of StyleablePropertyFactory. >>> >>> Tom >>> >> > > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tom.schindl at bestsolution.at Fri Jan 20 08:33:45 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 20 Jan 2017 09:33:45 +0100 Subject: Impossible to implement custom control with a StyleableObjectProperty on JavaFX9 In-Reply-To: References: <6bd48118-605b-6cad-125c-c4d7677230d6@bestsolution.at> Message-ID: <3947fdac-4cf2-e4f9-e58c-5fa2c19de282@bestsolution.at> In a similar vein a property like Labeled#graphicProperty - see https://bugs.openjdk.java.net/browse/JDK-8173106 who can not be implemented on JDK9 at all. Tom On 20.01.17 09:23, Tom Schindl wrote: > Hi, > > naturally it is https://bugs.openjdk.java.net/browse/JDK-8173103 > > Tom > > On 20.01.17 09:16, Tom Schindl wrote: >> https://bugs.openjdk.java.net/browse/JDK-8102126 >> >> Tom >> >> On 19.01.17 00:09, Jonathan Giles wrote: >>> This sounds like a reasonable issue to discuss a resolution for. Can you >>> please file a Jira issue and we can look into our options (either making >>> a reapplyCss() method available, or following something along the lines >>> of your suggestion)? >>> >>> Also, thanks for taking the time to test JDK 9 - this is exactly the >>> kind of feedback we need. >>> >>> -- Jonathan >>> >>> On 19/01/17 12:00 PM, Tom Schindl wrote: >>>> Hi, >>>> >>>> As JavaFX9 has removed impl_reapplyCss() it is impossible for custom >>>> controls to deal with a styleable Font-Property. >>>> >>>> To correctly implement a Font-Property the code needs to look similar to >>>> the one in Labeled#fontProperty. The only possibility I see implementing >>>> such a property without providing reapplyCss() to the public is to >>>> provide a correct implementation as part of StyleablePropertyFactory. >>>> >>>> Tom >>>> >>> >> >> > > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From tom.schindl at bestsolution.at Fri Jan 20 10:43:18 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 20 Jan 2017 11:43:18 +0100 Subject: Need an official way to exclude parts of the SceneGraph from CSS-Processing Message-ID: Hi, One of the biggest problems when working with JavaFX is that if you reparent a big portion of the SceneGraph is that a full CSS-Pass is applied on all reparented SG-Nodes even if those nodes are currently not visible (eg. because they are part of a TabPane). I general I think it is ok to also applyCSS changes on currently not visible nodes (eg they still have an influence on layout-bounds) but there are situations like the above mentioned example of TabPane that it is unnecessary overhead to apply applyCSS changes on those parts of the SG until they get visible. I would not mind if the CSS-Pass on JavaFX would be as performant as the one from current browsers but unfortunately it isn't so I'd like to discuss the possibility of a API to *temporarily* exclude portions of the SG from CSS-Passes. In JavaFX8 i was able to hack that in by overwriting impl_processCSS in a subclass who changed to doProcessCSS who now is private so my hack does not work anymore. To give you an impression on what performance gains we are talking about just look at the video I recorded - https://tomsondev.bestsolution.at/2016/11/25/improving-minmax-performance-in-e4-on-javafx-applications/ Tom -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kevin.rushforth at oracle.com Fri Jan 20 15:44:26 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Jan 2017 07:44:26 -0800 Subject: Impossible to implement custom control with a StyleableObjectProperty on JavaFX9 In-Reply-To: <6bd48118-605b-6cad-125c-c4d7677230d6@bestsolution.at> References: <6bd48118-605b-6cad-125c-c4d7677230d6@bestsolution.at> Message-ID: <5882305A.6060304@oracle.com> Hi Tom, As that bug is Resolved/Fixed (with a pushed changeset) we will need a new JBS bug to track any additional changes that might be needed. Thanks. -- Kevin Tom Schindl wrote: > https://bugs.openjdk.java.net/browse/JDK-8102126 > > Tom > > On 19.01.17 00:09, Jonathan Giles wrote: > >> This sounds like a reasonable issue to discuss a resolution for. Can you >> please file a Jira issue and we can look into our options (either making >> a reapplyCss() method available, or following something along the lines >> of your suggestion)? >> >> Also, thanks for taking the time to test JDK 9 - this is exactly the >> kind of feedback we need. >> >> -- Jonathan >> >> On 19/01/17 12:00 PM, Tom Schindl wrote: >> >>> Hi, >>> >>> As JavaFX9 has removed impl_reapplyCss() it is impossible for custom >>> controls to deal with a styleable Font-Property. >>> >>> To correctly implement a Font-Property the code needs to look similar to >>> the one in Labeled#fontProperty. The only possibility I see implementing >>> such a property without providing reapplyCss() to the public is to >>> provide a correct implementation as part of StyleablePropertyFactory. >>> >>> Tom >>> >>> > > > From kevin.rushforth at oracle.com Fri Jan 20 15:58:50 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Jan 2017 07:58:50 -0800 Subject: Need an official way to exclude parts of the SceneGraph from CSS-Processing In-Reply-To: References: Message-ID: <588233BA.6030105@oracle.com> Improving CSS performance is a big goal for JDK 10. It is very likely too late to do anything about this for JDK 9, but Jonathan might be able to comment further. -- Kevin Tom Schindl wrote: > Hi, > > One of the biggest problems when working with JavaFX is that if you > reparent a big portion of the SceneGraph is that a full CSS-Pass is > applied on all reparented SG-Nodes even if those nodes are currently not > visible (eg. because they are part of a TabPane). > > I general I think it is ok to also applyCSS changes on currently not > visible nodes (eg they still have an influence on layout-bounds) but > there are situations like the above mentioned example of TabPane that it > is unnecessary overhead to apply applyCSS changes on those parts of the > SG until they get visible. > > I would not mind if the CSS-Pass on JavaFX would be as performant as the > one from current browsers but unfortunately it isn't so I'd like to > discuss the possibility of a API to *temporarily* exclude portions of > the SG from CSS-Passes. > > In JavaFX8 i was able to hack that in by overwriting impl_processCSS in > a subclass who changed to doProcessCSS who now is private so my hack > does not work anymore. > > To give you an impression on what performance gains we are talking about > just look at the video I recorded - > https://tomsondev.bestsolution.at/2016/11/25/improving-minmax-performance-in-e4-on-javafx-applications/ > > Tom > > From kevin.rushforth at oracle.com Fri Jan 20 17:18:31 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Jan 2017 09:18:31 -0800 Subject: Problems building JavaFX with jdk-9+153 Message-ID: <58824667.9000508@oracle.com> We recently discovered a javac bug that prevents building JavaFX modules using jdk-9+153 as a boot JDK: https://bugs.openjdk.java.net/browse/JDK-8172809 This has now been fixed, and is expected to be delivered in build 154. You can use build 153 to build and run JavaFX applications, but if you need to build JavaFX itself, you should use an earlier build of JDK 9. -- Kevin From chris.bensen at oracle.com Fri Jan 20 19:04:45 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Fri, 20 Jan 2017 11:04:45 -0800 Subject: [9] Review request: Message-ID: Victor, Please review this change to provide a warning with suggested work arounds when packaging on Windows 10 with Windows Defender enabled. JIRA: https://bugs.openjdk.java.net/browse/JDK-8172444 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8172444/webrev.01/ Chris From mp at jugs.org Sat Jan 21 18:17:34 2017 From: mp at jugs.org (Michael Paus) Date: Sat, 21 Jan 2017 19:17:34 +0100 Subject: Need an official way to exclude parts of the SceneGraph from CSS-Processing In-Reply-To: References: Message-ID: Hi Tom, I am wondering whether it is really necessary to provide special API for this case or whether this is not just an implementation issue of controls like the TabPane. For performance reasons (not only CSS-processing) I normally track selection changes in TabPanes and similar controls and then explicitly remove all invisible branches from the scene graph and keep them elsewhere so that I can re-attach them if needed. But I also do this tracking for a second reason because I also want to tell my model which tab is visible so that I can shut down all processing in my model which only updates properties which are only used in the currently invisible branches of the scene graph. I think if currently invisible branches of the scene graph are explicitly detached from it, this does also solve your original problem of reparenting, doesn't it? It would however be nice if the TabPane would do the detaching/attaching itself. Michael Am 20.01.17 um 11:43 schrieb Tom Schindl: > Hi, > > One of the biggest problems when working with JavaFX is that if you > reparent a big portion of the SceneGraph is that a full CSS-Pass is > applied on all reparented SG-Nodes even if those nodes are currently not > visible (eg. because they are part of a TabPane). > > I general I think it is ok to also applyCSS changes on currently not > visible nodes (eg they still have an influence on layout-bounds) but > there are situations like the above mentioned example of TabPane that it > is unnecessary overhead to apply applyCSS changes on those parts of the > SG until they get visible. > > I would not mind if the CSS-Pass on JavaFX would be as performant as the > one from current browsers but unfortunately it isn't so I'd like to > discuss the possibility of a API to *temporarily* exclude portions of > the SG from CSS-Passes. > > In JavaFX8 i was able to hack that in by overwriting impl_processCSS in > a subclass who changed to doProcessCSS who now is private so my hack > does not work anymore. > > To give you an impression on what performance gains we are talking about > just look at the video I recorded - > https://tomsondev.bestsolution.at/2016/11/25/improving-minmax-performance-in-e4-on-javafx-applications/ > > Tom > From jonathan.giles at oracle.com Mon Jan 23 23:15:56 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 24 Jan 2017 12:15:56 +1300 Subject: Need an official way to exclude parts of the SceneGraph from CSS-Processing In-Reply-To: References: Message-ID: <51fe93ab-f284-62ee-c499-e4acc661fadb@oracle.com> There are two different topics here, both of which are near and dear to my heart (and also make me feel like I've been doing JavaFX for way too long!). The specific case of TabPane doing CSS / layout on the content of all tabs is something captured here: https://bugs.openjdk.java.net/browse/JDK-8092206 It dates back to 2012 and I remember spending considerable amount of effort with my team working through this. As can be seen in some of the comments, there were attempts to improve performance (and they were really nice), but the outcome was to back it out as we could not change the default semantics of loading and doing all work on all tabs. The second-to-last comment was a proposal for some API that would specify the policy. I really would like to pick this back up for JDK 10, as JDK 9 is locked and loaded in this regard. I have retargeted this for JDK 10 just now. As Kevin notes, improving performance is a big push I want to get underway for JDK 10. The more general comment made in your email is - how can we get better performance out of our critical paths (CSS, layout, TableView, etc). That's something we will be actively exploring. There are a lot of ideas, some will yield results and some won't. I've been running into a few of those dead-ends myself recently as I do preliminary investigations. If anyone is interested in exploring performance-related topics in JavaFX, I've got plenty of areas to explore :-) Ping me off-list and we can discuss. Unfortunately, again, unless there is some critical oversight these discussions and investigations into performance and additional API are by default targeted to JDK 10 rather than JDK 9. -- Jonathan On 20/01/17 11:43 PM, Tom Schindl wrote: > Hi, > > One of the biggest problems when working with JavaFX is that if you > reparent a big portion of the SceneGraph is that a full CSS-Pass is > applied on all reparented SG-Nodes even if those nodes are currently not > visible (eg. because they are part of a TabPane). > > I general I think it is ok to also applyCSS changes on currently not > visible nodes (eg they still have an influence on layout-bounds) but > there are situations like the above mentioned example of TabPane that it > is unnecessary overhead to apply applyCSS changes on those parts of the > SG until they get visible. > > I would not mind if the CSS-Pass on JavaFX would be as performant as the > one from current browsers but unfortunately it isn't so I'd like to > discuss the possibility of a API to *temporarily* exclude portions of > the SG from CSS-Passes. > > In JavaFX8 i was able to hack that in by overwriting impl_processCSS in > a subclass who changed to doProcessCSS who now is private so my hack > does not work anymore. > > To give you an impression on what performance gains we are talking about > just look at the video I recorded - > https://tomsondev.bestsolution.at/2016/11/25/improving-minmax-performance-in-e4-on-javafx-applications/ > > Tom > From chris.bensen at oracle.com Mon Jan 23 23:45:35 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Mon, 23 Jan 2017 15:45:35 -0800 Subject: [9] Review request: 8173225 codesign fails on symlinks Message-ID: Victor, Please review these changes to submit apps to the Mac App store. JIRA: https://bugs.openjdk.java.net/browse/JDK-8173225 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8173225/webrev.01/ Chris From guru.hb at oracle.com Tue Jan 24 06:12:32 2017 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 24 Jan 2017 11:42:32 +0530 Subject: CFV: New OpenJFX Committer: Ramesh Gangadhar In-Reply-To: <587FE3F6.2050000@oracle.com> References: <587FE3F6.2050000@oracle.com> Message-ID: <6FCBE1F5-905F-4E63-9258-2672FA40260D@oracle.com> Vote: yes > On 19-Jan-2017, at 3:23 AM, Kevin Rushforth wrote: > > I hereby nominate Ramesh Gangadhar [1] to OpenJFX Committer. > > Ramesh is a member of JavaFX SQE team at Oracle working on test development for the Java packager, who has contributed 20 changesets to OpenJFX, at least 8 of which [5] are significant. > > Votes are due by February 1, 2017. > > Only current OpenJFX Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. Nomination to a project Committer is described in [4]. > > Thanks, > > -- Kevin > > > [1] http://openjdk.java.net/census#rgangadhar > > [2] http://openjdk.java.net/census#openjfx > > [3] http://openjdk.java.net/bylaws#lazy-consensus > > [4] http://openjdk.java.net/projects#project-committer > > [5] List of significant changesets: > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0b702e5db31c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0787febc9b94 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b80a8efca46c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/9fe019fe7f5c > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/bf6ae1d345ce > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/be0c0e2d0d31 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/b743144c5e11 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/0181e5e6b9bb > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/a141695f4a7f > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/16542d3f79a9 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/78f45d216138 > http://hg.openjdk.java.net/openjfx/9-dev/tests/rev/92b56a32ebd1 > From guru.hb at oracle.com Tue Jan 24 07:23:55 2017 From: guru.hb at oracle.com (Guru Hb) Date: Tue, 24 Jan 2017 12:53:55 +0530 Subject: [9] Review request: 8158196: WebView Form Post fails if connection is closed before keepAlive-Timeout Message-ID: Hi Kevin, Arun & Murali, Please review the fix for: JBS : https://bugs.openjdk.java.net/browse/JDK-8158196 Webrev : http://cr.openjdk.java.net/~ghb/8158196/webrev.00/ RC and solution updated in JBS. Thanks, Guru From tom.schindl at bestsolution.at Tue Jan 24 08:16:15 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 24 Jan 2017 09:16:15 +0100 Subject: Need an official way to exclude parts of the SceneGraph from CSS-Processing In-Reply-To: References: Message-ID: <1b777d9c-bef8-b134-3889-8c5b6cdacbb8@bestsolution.at> Hi, Well in your sample one has the CSS-Performance hit on each Tab-Switch for a customer I had implemented a custom TabPane who initially detached the SG-Part once a Tab was not selected but because the sub-structures in each Tab had been extremly complex the Tab-Switch lagged so much finally came to the conclusion that we have to keep the SG elements. Tom On 21.01.17 19:17, Michael Paus wrote: > Hi Tom, > > I am wondering whether it is really necessary to provide special API > for this case or whether this is not just an implementation issue of > controls like the TabPane. > > For performance reasons (not only CSS-processing) I normally track > selection changes in TabPanes and similar controls and then explicitly > remove all invisible branches from the scene graph and keep them > elsewhere so that I can re-attach them if needed. > > But I also do this tracking for a second reason because I also want > to tell my model which tab is visible so that I can shut down all > processing in my model which only updates properties which are > only used in the currently invisible branches of the scene graph. > > I think if currently invisible branches of the scene graph are explicitly > detached from it, this does also solve your original problem of > reparenting, doesn't it? It would however be nice if the TabPane would > do the detaching/attaching itself. > > Michael > > > Am 20.01.17 um 11:43 schrieb Tom Schindl: >> Hi, >> >> One of the biggest problems when working with JavaFX is that if you >> reparent a big portion of the SceneGraph is that a full CSS-Pass is >> applied on all reparented SG-Nodes even if those nodes are currently not >> visible (eg. because they are part of a TabPane). >> >> I general I think it is ok to also applyCSS changes on currently not >> visible nodes (eg they still have an influence on layout-bounds) but >> there are situations like the above mentioned example of TabPane that it >> is unnecessary overhead to apply applyCSS changes on those parts of the >> SG until they get visible. >> >> I would not mind if the CSS-Pass on JavaFX would be as performant as the >> one from current browsers but unfortunately it isn't so I'd like to >> discuss the possibility of a API to *temporarily* exclude portions of >> the SG from CSS-Passes. >> >> In JavaFX8 i was able to hack that in by overwriting impl_processCSS in >> a subclass who changed to doProcessCSS who now is private so my hack >> does not work anymore. >> >> To give you an impression on what performance gains we are talking about >> just look at the video I recorded - >> https://tomsondev.bestsolution.at/2016/11/25/improving-minmax-performance-in-e4-on-javafx-applications/ >> >> >> Tom >> > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From hastebrot at gmail.com Tue Jan 24 08:46:23 2017 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Tue, 24 Jan 2017 09:46:23 +0100 Subject: Need an official way to exclude parts of the SceneGraph from CSS-Processing In-Reply-To: <51fe93ab-f284-62ee-c499-e4acc661fadb@oracle.com> References: <51fe93ab-f284-62ee-c499-e4acc661fadb@oracle.com> Message-ID: >As Kevin notes, improving performance is a big push I want to get underway for JDK 10. I'd also love to see the PerformanceTracker API outside of com.sun in JDK 10. >If anyone is interested in exploring performance-related topics in JavaFX I'll ping you, when I've more time to deeply think and experiment with improvements to the PerformanceTracker. --Benjamin On Tue, Jan 24, 2017 at 12:15 AM, Jonathan Giles wrote: > There are two different topics here, both of which are near and dear to my > heart (and also make me feel like I've been doing JavaFX for way too long!). > > The specific case of TabPane doing CSS / layout on the content of all tabs > is something captured here: > > https://bugs.openjdk.java.net/browse/JDK-8092206 > > It dates back to 2012 and I remember spending considerable amount of > effort with my team working through this. As can be seen in some of the > comments, there were attempts to improve performance (and they were really > nice), but the outcome was to back it out as we could not change the > default semantics of loading and doing all work on all tabs. The > second-to-last comment was a proposal for some API that would specify the > policy. I really would like to pick this back up for JDK 10, as JDK 9 is > locked and loaded in this regard. I have retargeted this for JDK 10 just > now. > > As Kevin notes, improving performance is a big push I want to get underway > for JDK 10. The more general comment made in your email is - how can we get > better performance out of our critical paths (CSS, layout, TableView, etc). > That's something we will be actively exploring. There are a lot of ideas, > some will yield results and some won't. I've been running into a few of > those dead-ends myself recently as I do preliminary investigations. > > If anyone is interested in exploring performance-related topics in JavaFX, > I've got plenty of areas to explore :-) Ping me off-list and we can discuss. > > Unfortunately, again, unless there is some critical oversight these > discussions and investigations into performance and additional API are by > default targeted to JDK 10 rather than JDK 9. > > -- Jonathan > > > On 20/01/17 11:43 PM, Tom Schindl wrote: > >> Hi, >> >> One of the biggest problems when working with JavaFX is that if you >> reparent a big portion of the SceneGraph is that a full CSS-Pass is >> applied on all reparented SG-Nodes even if those nodes are currently not >> visible (eg. because they are part of a TabPane). >> >> I general I think it is ok to also applyCSS changes on currently not >> visible nodes (eg they still have an influence on layout-bounds) but >> there are situations like the above mentioned example of TabPane that it >> is unnecessary overhead to apply applyCSS changes on those parts of the >> SG until they get visible. >> >> I would not mind if the CSS-Pass on JavaFX would be as performant as the >> one from current browsers but unfortunately it isn't so I'd like to >> discuss the possibility of a API to *temporarily* exclude portions of >> the SG from CSS-Passes. >> >> In JavaFX8 i was able to hack that in by overwriting impl_processCSS in >> a subclass who changed to doProcessCSS who now is private so my hack >> does not work anymore. >> >> To give you an impression on what performance gains we are talking about >> just look at the video I recorded - >> https://tomsondev.bestsolution.at/2016/11/25/improving-minma >> x-performance-in-e4-on-javafx-applications/ >> >> Tom >> >> > From tom.schindl at bestsolution.at Tue Jan 24 09:21:45 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 24 Jan 2017 10:21:45 +0100 Subject: Need an official way to exclude parts of the SceneGraph from CSS-Processing In-Reply-To: <51fe93ab-f284-62ee-c499-e4acc661fadb@oracle.com> References: <51fe93ab-f284-62ee-c499-e4acc661fadb@oracle.com> Message-ID: <0ee310b5-fcbb-5107-4283-6050305ade81@bestsolution.at> Hi Jonathan & Kevin, Let's take CSS-Performance on the side for a moment. I think the request I have is in itself already legal because there might be situations where I as a component developer want to rule out CSS-Processing for a complete SG-Area. It might be performance (as it is in the case I initially mentioned) but I think there are other use cases as well. Let's assume I write a JavaFX-PDF-Viewer (something I really start doing just today) and I want to avoid someone changing any of the SG-Objects I create (even by accident). A similar problem we see today with the code-editor control we developed, unbound CSS-Rules have a good chance to effect the Text-Nodes who make up our editor and cause performance problems because we have so many Text-Nodes making up the editor! Today I have no other option than to programmatically setting all sorts of properties because then the CSS-Engine then skips them but this eagerly creates Property-Instances which once more effects memory usage. I think that I as a control/component developer HAVE TO HAVE the chance to define that the complete SG below me is managed by me and CSS does NOT have to be applied to it. I would propose the following simple "API": private boolean cssSensitive = true; public boolean isCssSensitive() { return cssSensitive; } public void setCssSensitive(boolean cssSensitive) { if( this.cssSensitive != cssSensitive ) { this.cssSensitive = cssSensitive; if( cssSensitive ) { reapplyCSS(); // or is applyCSS() not sure } } } private void doProcessCSS() { if( ! cssSensitive ) { return; } } I do understand that I'm too late in JDK9 cycle to add such an API but one could at least dream about such a thing. Tom On 24.01.17 00:15, Jonathan Giles wrote: > There are two different topics here, both of which are near and dear to > my heart (and also make me feel like I've been doing JavaFX for way too > long!). > > The specific case of TabPane doing CSS / layout on the content of all > tabs is something captured here: > > https://bugs.openjdk.java.net/browse/JDK-8092206 > > It dates back to 2012 and I remember spending considerable amount of > effort with my team working through this. As can be seen in some of the > comments, there were attempts to improve performance (and they were > really nice), but the outcome was to back it out as we could not change > the default semantics of loading and doing all work on all tabs. The > second-to-last comment was a proposal for some API that would specify > the policy. I really would like to pick this back up for JDK 10, as JDK > 9 is locked and loaded in this regard. I have retargeted this for JDK 10 > just now. > > As Kevin notes, improving performance is a big push I want to get > underway for JDK 10. The more general comment made in your email is - > how can we get better performance out of our critical paths (CSS, > layout, TableView, etc). That's something we will be actively exploring. > There are a lot of ideas, some will yield results and some won't. I've > been running into a few of those dead-ends myself recently as I do > preliminary investigations. > > If anyone is interested in exploring performance-related topics in > JavaFX, I've got plenty of areas to explore :-) Ping me off-list and we > can discuss. > > Unfortunately, again, unless there is some critical oversight these > discussions and investigations into performance and additional API are > by default targeted to JDK 10 rather than JDK 9. > > -- Jonathan > > On 20/01/17 11:43 PM, Tom Schindl wrote: >> Hi, >> >> One of the biggest problems when working with JavaFX is that if you >> reparent a big portion of the SceneGraph is that a full CSS-Pass is >> applied on all reparented SG-Nodes even if those nodes are currently not >> visible (eg. because they are part of a TabPane). >> >> I general I think it is ok to also applyCSS changes on currently not >> visible nodes (eg they still have an influence on layout-bounds) but >> there are situations like the above mentioned example of TabPane that it >> is unnecessary overhead to apply applyCSS changes on those parts of the >> SG until they get visible. >> >> I would not mind if the CSS-Pass on JavaFX would be as performant as the >> one from current browsers but unfortunately it isn't so I'd like to >> discuss the possibility of a API to *temporarily* exclude portions of >> the SG from CSS-Passes. >> >> In JavaFX8 i was able to hack that in by overwriting impl_processCSS in >> a subclass who changed to doProcessCSS who now is private so my hack >> does not work anymore. >> >> To give you an impression on what performance gains we are talking about >> just look at the video I recorded - >> https://tomsondev.bestsolution.at/2016/11/25/improving-minmax-performance-in-e4-on-javafx-applications/ >> >> >> Tom >> > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From victor.drozdov at oracle.com Tue Jan 24 16:19:37 2017 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Tue, 24 Jan 2017 19:19:37 +0300 Subject: [9] Review request: JDK-8172789: fx packager: fx:info doesn't work Message-ID: <4c471166-944e-be40-1e1e-22f60030ff21@oracle.com> Chris, Please review the changes about fx:info JIRA: https://bugs.openjdk.java.net/browse/JDK-8172789 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8172789/webrev.00/ --Victor From jonathan.giles at oracle.com Tue Jan 24 20:47:15 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 25 Jan 2017 09:47:15 +1300 Subject: Need an official way to exclude parts of the SceneGraph from CSS-Processing In-Reply-To: <0ee310b5-fcbb-5107-4283-6050305ade81@bestsolution.at> References: <51fe93ab-f284-62ee-c499-e4acc661fadb@oracle.com> <0ee310b5-fcbb-5107-4283-6050305ade81@bestsolution.at> Message-ID: Tom, You can do one better than dream - you can file a JBS issue where we can continue to discuss it :-) -- Jonathan On 24/01/17 10:21 PM, Tom Schindl wrote: > Hi Jonathan & Kevin, > > Let's take CSS-Performance on the side for a moment. > > I think the request I have is in itself already legal because there > might be situations where I as a component developer want to rule out > CSS-Processing for a complete SG-Area. > > It might be performance (as it is in the case I initially mentioned) but > I think there are other use cases as well. Let's assume I write a > JavaFX-PDF-Viewer (something I really start doing just today) and I want > to avoid someone changing any of the SG-Objects I create (even by accident). > > A similar problem we see today with the code-editor control we > developed, unbound CSS-Rules have a good chance to effect the Text-Nodes > who make up our editor and cause performance problems because we have so > many Text-Nodes making up the editor! > > Today I have no other option than to programmatically setting all sorts > of properties because then the CSS-Engine then skips them but this > eagerly creates Property-Instances which once more effects memory usage. > > I think that I as a control/component developer HAVE TO HAVE the chance > to define that the complete SG below me is managed by me and CSS does > NOT have to be applied to it. > > I would propose the following simple "API": > > private boolean cssSensitive = true; > > public boolean isCssSensitive() { > return cssSensitive; > } > > public void setCssSensitive(boolean cssSensitive) { > if( this.cssSensitive != cssSensitive ) { > this.cssSensitive = cssSensitive; > if( cssSensitive ) { > reapplyCSS(); // or is applyCSS() not sure > } > } > } > > private void doProcessCSS() { > if( ! cssSensitive ) { > return; > } > } > > I do understand that I'm too late in JDK9 cycle to add such an API but > one could at least dream about such a thing. > > Tom > > On 24.01.17 00:15, Jonathan Giles wrote: >> There are two different topics here, both of which are near and dear to >> my heart (and also make me feel like I've been doing JavaFX for way too >> long!). >> >> The specific case of TabPane doing CSS / layout on the content of all >> tabs is something captured here: >> >> https://bugs.openjdk.java.net/browse/JDK-8092206 >> >> It dates back to 2012 and I remember spending considerable amount of >> effort with my team working through this. As can be seen in some of the >> comments, there were attempts to improve performance (and they were >> really nice), but the outcome was to back it out as we could not change >> the default semantics of loading and doing all work on all tabs. The >> second-to-last comment was a proposal for some API that would specify >> the policy. I really would like to pick this back up for JDK 10, as JDK >> 9 is locked and loaded in this regard. I have retargeted this for JDK 10 >> just now. >> >> As Kevin notes, improving performance is a big push I want to get >> underway for JDK 10. The more general comment made in your email is - >> how can we get better performance out of our critical paths (CSS, >> layout, TableView, etc). That's something we will be actively exploring. >> There are a lot of ideas, some will yield results and some won't. I've >> been running into a few of those dead-ends myself recently as I do >> preliminary investigations. >> >> If anyone is interested in exploring performance-related topics in >> JavaFX, I've got plenty of areas to explore :-) Ping me off-list and we >> can discuss. >> >> Unfortunately, again, unless there is some critical oversight these >> discussions and investigations into performance and additional API are >> by default targeted to JDK 10 rather than JDK 9. >> >> -- Jonathan >> >> On 20/01/17 11:43 PM, Tom Schindl wrote: >>> Hi, >>> >>> One of the biggest problems when working with JavaFX is that if you >>> reparent a big portion of the SceneGraph is that a full CSS-Pass is >>> applied on all reparented SG-Nodes even if those nodes are currently not >>> visible (eg. because they are part of a TabPane). >>> >>> I general I think it is ok to also applyCSS changes on currently not >>> visible nodes (eg they still have an influence on layout-bounds) but >>> there are situations like the above mentioned example of TabPane that it >>> is unnecessary overhead to apply applyCSS changes on those parts of the >>> SG until they get visible. >>> >>> I would not mind if the CSS-Pass on JavaFX would be as performant as the >>> one from current browsers but unfortunately it isn't so I'd like to >>> discuss the possibility of a API to *temporarily* exclude portions of >>> the SG from CSS-Passes. >>> >>> In JavaFX8 i was able to hack that in by overwriting impl_processCSS in >>> a subclass who changed to doProcessCSS who now is private so my hack >>> does not work anymore. >>> >>> To give you an impression on what performance gains we are talking about >>> just look at the video I recorded - >>> https://tomsondev.bestsolution.at/2016/11/25/improving-minmax-performance-in-e4-on-javafx-applications/ >>> >>> >>> Tom >>> > From tom.schindl at bestsolution.at Tue Jan 24 21:07:43 2017 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Tue, 24 Jan 2017 22:07:43 +0100 Subject: Need an official way to exclude parts of the SceneGraph from CSS-Processing In-Reply-To: References: <51fe93ab-f284-62ee-c499-e4acc661fadb@oracle.com> <0ee310b5-fcbb-5107-4283-6050305ade81@bestsolution.at> Message-ID: <036c1f64-be5b-a8b1-e14c-401bd71bc8d7@bestsolution.at> There you go - https://bugs.openjdk.java.net/browse/JDK-8173301 Tom On 24.01.17 21:47, Jonathan Giles wrote: > Tom, > > You can do one better than dream - you can file a JBS issue where we can > continue to discuss it :-) > > -- Jonathan > > On 24/01/17 10:21 PM, Tom Schindl wrote: >> Hi Jonathan & Kevin, >> >> Let's take CSS-Performance on the side for a moment. >> >> I think the request I have is in itself already legal because there >> might be situations where I as a component developer want to rule out >> CSS-Processing for a complete SG-Area. >> >> It might be performance (as it is in the case I initially mentioned) but >> I think there are other use cases as well. Let's assume I write a >> JavaFX-PDF-Viewer (something I really start doing just today) and I want >> to avoid someone changing any of the SG-Objects I create (even by >> accident). >> >> A similar problem we see today with the code-editor control we >> developed, unbound CSS-Rules have a good chance to effect the Text-Nodes >> who make up our editor and cause performance problems because we have so >> many Text-Nodes making up the editor! >> >> Today I have no other option than to programmatically setting all sorts >> of properties because then the CSS-Engine then skips them but this >> eagerly creates Property-Instances which once more effects memory usage. >> >> I think that I as a control/component developer HAVE TO HAVE the chance >> to define that the complete SG below me is managed by me and CSS does >> NOT have to be applied to it. >> >> I would propose the following simple "API": >> >> private boolean cssSensitive = true; >> >> public boolean isCssSensitive() { >> return cssSensitive; >> } >> >> public void setCssSensitive(boolean cssSensitive) { >> if( this.cssSensitive != cssSensitive ) { >> this.cssSensitive = cssSensitive; >> if( cssSensitive ) { >> reapplyCSS(); // or is applyCSS() not sure >> } >> } >> } >> >> private void doProcessCSS() { >> if( ! cssSensitive ) { >> return; >> } >> } >> >> I do understand that I'm too late in JDK9 cycle to add such an API but >> one could at least dream about such a thing. >> >> Tom >> >> On 24.01.17 00:15, Jonathan Giles wrote: >>> There are two different topics here, both of which are near and dear to >>> my heart (and also make me feel like I've been doing JavaFX for way too >>> long!). >>> >>> The specific case of TabPane doing CSS / layout on the content of all >>> tabs is something captured here: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8092206 >>> >>> It dates back to 2012 and I remember spending considerable amount of >>> effort with my team working through this. As can be seen in some of the >>> comments, there were attempts to improve performance (and they were >>> really nice), but the outcome was to back it out as we could not change >>> the default semantics of loading and doing all work on all tabs. The >>> second-to-last comment was a proposal for some API that would specify >>> the policy. I really would like to pick this back up for JDK 10, as JDK >>> 9 is locked and loaded in this regard. I have retargeted this for JDK 10 >>> just now. >>> >>> As Kevin notes, improving performance is a big push I want to get >>> underway for JDK 10. The more general comment made in your email is - >>> how can we get better performance out of our critical paths (CSS, >>> layout, TableView, etc). That's something we will be actively exploring. >>> There are a lot of ideas, some will yield results and some won't. I've >>> been running into a few of those dead-ends myself recently as I do >>> preliminary investigations. >>> >>> If anyone is interested in exploring performance-related topics in >>> JavaFX, I've got plenty of areas to explore :-) Ping me off-list and we >>> can discuss. >>> >>> Unfortunately, again, unless there is some critical oversight these >>> discussions and investigations into performance and additional API are >>> by default targeted to JDK 10 rather than JDK 9. >>> >>> -- Jonathan >>> >>> On 20/01/17 11:43 PM, Tom Schindl wrote: >>>> Hi, >>>> >>>> One of the biggest problems when working with JavaFX is that if you >>>> reparent a big portion of the SceneGraph is that a full CSS-Pass is >>>> applied on all reparented SG-Nodes even if those nodes are currently >>>> not >>>> visible (eg. because they are part of a TabPane). >>>> >>>> I general I think it is ok to also applyCSS changes on currently not >>>> visible nodes (eg they still have an influence on layout-bounds) but >>>> there are situations like the above mentioned example of TabPane >>>> that it >>>> is unnecessary overhead to apply applyCSS changes on those parts of the >>>> SG until they get visible. >>>> >>>> I would not mind if the CSS-Pass on JavaFX would be as performant as >>>> the >>>> one from current browsers but unfortunately it isn't so I'd like to >>>> discuss the possibility of a API to *temporarily* exclude portions of >>>> the SG from CSS-Passes. >>>> >>>> In JavaFX8 i was able to hack that in by overwriting impl_processCSS in >>>> a subclass who changed to doProcessCSS who now is private so my hack >>>> does not work anymore. >>>> >>>> To give you an impression on what performance gains we are talking >>>> about >>>> just look at the video I recorded - >>>> https://tomsondev.bestsolution.at/2016/11/25/improving-minmax-performance-in-e4-on-javafx-applications/ >>>> >>>> >>>> >>>> Tom >>>> >> > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From victor.drozdov at oracle.com Wed Jan 25 12:59:47 2017 From: victor.drozdov at oracle.com (Victor Drozdov) Date: Wed, 25 Jan 2017 15:59:47 +0300 Subject: [9] Review request:JDK-8173202: fx packager: Error: -includedt requires the java deployment toolkit, which is not included in this distribution Message-ID: Chris, Please review the changes about including DT files in jdk.packager. JIRA: http://bugs.openjdk.java.net/browse/JDK-8173202 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8173202/webrev.00/ --Victor From David.Hill at Oracle.com Wed Jan 25 19:39:59 2017 From: David.Hill at Oracle.com (David Hill) Date: Wed, 25 Jan 2017 14:39:59 -0500 Subject: CFV: New OpenJFX Committer: Semyon Sadetsky Message-ID: <5888FF0F.5010509@Oracle.com> I hereby nominate Semyon Sadetsky to OpenJFX Committer. Semyon Sadetsky is part of the JavaFX team focusing on glass. A list of Semyon's commits and reviews is available by the following links http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=author%28ssadetsky%29 Votes are due by Feb 9th, 2017. Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. [1] http://openjdk.java.net/census#openjfx [2] http://openjdk.java.net/bylaws#lazy-consensus [3] http://openjdk.java.net/projects#project-committer Thanks, Dave From philip.race at oracle.com Wed Jan 25 19:39:32 2017 From: philip.race at oracle.com (Phil Race) Date: Wed, 25 Jan 2017 11:39:32 -0800 Subject: CFV: New OpenJFX Committer: Semyon Sadetsky In-Reply-To: <5888FF0F.5010509@Oracle.com> References: <5888FF0F.5010509@Oracle.com> Message-ID: Vote: yes -phil. From kevin.rushforth at oracle.com Wed Jan 25 19:42:17 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Jan 2017 11:42:17 -0800 Subject: CFV: New OpenJFX Committer: Semyon Sadetsky In-Reply-To: <5888FF0F.5010509@Oracle.com> References: <5888FF0F.5010509@Oracle.com> Message-ID: <5888FF99.30105@oracle.com> Vote: YES David Hill wrote: > > I hereby nominate Semyon Sadetsky to OpenJFX Committer. > > Semyon Sadetsky is part of the JavaFX team focusing on glass. > > A list of Semyon's commits and reviews is available by the following > links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=author%28ssadetsky%29 > > Votes are due by Feb 9th, 2017. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From vadim.pakhnushev at oracle.com Wed Jan 25 19:49:04 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 25 Jan 2017 22:49:04 +0300 Subject: CFV: New OpenJFX Committer: Semyon Sadetsky In-Reply-To: <5888FF0F.5010509@Oracle.com> References: <5888FF0F.5010509@Oracle.com> Message-ID: <6988970f-136d-c3ca-ec87-a0fded296038@oracle.com> Vote: yes On 25.01.2017 22:39, David Hill wrote: > > I hereby nominate Semyon Sadetsky to OpenJFX Committer. > > Semyon Sadetsky is part of the JavaFX team focusing on glass. > > A list of Semyon's commits and reviews is available by the following > links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=author%28ssadetsky%29 > > Votes are due by Feb 9th, 2017. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From jonathan.giles at oracle.com Wed Jan 25 20:16:11 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 26 Jan 2017 09:16:11 +1300 Subject: CFV: New OpenJFX Committer: Semyon Sadetsky In-Reply-To: <5888FF0F.5010509@Oracle.com> References: <5888FF0F.5010509@Oracle.com> Message-ID: <283d6629-d5b0-3854-6dbe-16559c10cfab@oracle.com> Vote: yes On 26/01/17 8:39 AM, David Hill wrote: > > I hereby nominate Semyon Sadetsky to OpenJFX Committer. > > Semyon Sadetsky is part of the JavaFX team focusing on glass. > > A list of Semyon's commits and reviews is available by the following > links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=author%28ssadetsky%29 > > Votes are due by Feb 9th, 2017. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From alexander.zvegintsev at oracle.com Wed Jan 25 21:09:51 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 26 Jan 2017 00:09:51 +0300 Subject: CFV: New OpenJFX Committer: Semyon Sadetsky In-Reply-To: <5888FF0F.5010509@Oracle.com> References: <5888FF0F.5010509@Oracle.com> Message-ID: <5a7bc7d8-1aac-bfbf-f3c9-78947e616a3a@oracle.com> Vote: yes -- Thanks, Alexander. On 25.01.2017 22:39, David Hill wrote: > > I hereby nominate Semyon Sadetsky to OpenJFX Committer. > > Semyon Sadetsky is part of the JavaFX team focusing on glass. > > A list of Semyon's commits and reviews is available by the following > links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=author%28ssadetsky%29 > > Votes are due by Feb 9th, 2017. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From james.graham at oracle.com Thu Jan 26 02:21:34 2017 From: james.graham at oracle.com (Jim Graham) Date: Wed, 25 Jan 2017 18:21:34 -0800 Subject: CFV: New OpenJFX Committer: Semyon Sadetsky In-Reply-To: <5888FF0F.5010509@Oracle.com> References: <5888FF0F.5010509@Oracle.com> Message-ID: <02dc9e06-5bea-fc6b-b7c5-abec518058ba@oracle.com> Vote: yes ...jim On 1/25/17 11:39 AM, David Hill wrote: > > I hereby nominate Semyon Sadetsky to OpenJFX Committer. > > Semyon Sadetsky is part of the JavaFX team focusing on glass. > > A list of Semyon's commits and reviews is available by the following links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=author%28ssadetsky%29 > > Votes are due by Feb 9th, 2017. > > Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From murali.billa at oracle.com Thu Jan 26 05:55:34 2017 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 25 Jan 2017 21:55:34 -0800 (PST) Subject: CFV: New OpenJFX Committer: Semyon Sadetsky In-Reply-To: <5888FF0F.5010509@Oracle.com> References: <5888FF0F.5010509@Oracle.com> Message-ID: <6ba85e0d-156e-4737-b840-62d32094cb77@default> Vote: YES David Hill wrote: > > I hereby nominate Semyon Sadetsky to OpenJFX Committer. > > Semyon Sadetsky is part of the JavaFX team focusing on glass. > > A list of Semyon's commits and reviews is available by the following > links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=author%28ssadetsky > %29 > > Votes are due by Feb 9th, 2017. > > Only current OpenJFX Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a > project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From semyon.sadetsky at oracle.com Thu Jan 26 06:13:51 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 26 Jan 2017 09:13:51 +0300 Subject: [9] Review request for 8172554: [macos] deadlock on JFXPanel startup Message-ID: <14d9720c-6427-3957-4051-477a7ca3b384@oracle.com> Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8172554 webrev: http://cr.openjdk.java.net/~ssadetsky/8172554/webrev.01/ JFXPanel initializes JFX on EDT as result EDT and Toolkit thread may block each other. The proposed solution do not block EDT while JFX is initialized. See other details in the bug. --Semyon From chris.bensen at oracle.com Thu Jan 26 23:23:37 2017 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 26 Jan 2017 15:23:37 -0800 Subject: [9] Review request: 8173407 New Ensemble AppStore icon Message-ID: <7915D72C-8505-42AC-847A-4B4BC35EF0FF@oracle.com> Victor, Please review this very minor change. Rename of the Ensemble illustrator file, along with an updated version that the AppStore should be happy with, and the new PNG. JIRA: https://bugs.openjdk.java.net/browse/JDK-8173407 Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8173407/webrev.00/ Chris From swpalmer at gmail.com Fri Jan 27 01:48:29 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 26 Jan 2017 20:48:29 -0500 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <5876840F.40508@oracle.com> References: <5876840F.40508@oracle.com> Message-ID: I finally managed to get my app running on JDK 9. It is based on a plugin architecture and the plugins are made accessible by modifying the system class loader at runtime (because that seemed to be the only way to make things like JAXB able to reach the classes in the plugins). That ?hack? broke with the module system so I had to find an alternative. (Now I?m using a java agent to get an Instrumentation interface so I can do it in a somewhat supported way via the appendToSystemClassLoaderSearch method.) Anyway, I?ve noticed that the application runs slower on Java 9. For a simple test I see almost a 10% performance drop. However, I?m not sure that it is Java FX related. I see the same throughput with the default renderer or the recently added Marlin renderer, always a bit slower than Java 8u121. I use the same JVM options, including forcing the garbage collector to use the same algorithm. Is there any expectation of a performance drop with JDK 9 at this stage? For example should I expect some unoptimized stuff in the EA builds? I guess the jigsaw-dev alias the right place to bring this up? I have a feeling it is going to be difficult to track down. :-( I have noticed a couple layout issues fixed with JavaFX 9. Stuff that used to ?snap into place? only when I resized a dialog now seems to be correct when the dialog first appears. Thanks for that! Regards, Scott > On Jan 11, 2017, at 2:14 PM, Kevin Rushforth wrote: > > As you may know JDK 9 has hit the feature extension complete milestone [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need to know about them in order to fix them. Our focus will be on bugs that are new in JDK 9 (regressions). > > I ask all JavaFX developers to please download JDK 9 early access [2] and test your application. You can report any bugs via bugs.java.com [3]. If you have any questions about whether a behavior is a bug or is expected, please ask on this alias or on the jigsaw-dev alias [4]. > > Thank you. > > -- Kevin > > [1] http://openjdk.java.net/projects/jdk9/ > [2] https://jdk9.java.net/download/ > [3] http://bugreport.java.com/ > [4] jigsaw-dev at openjdk.java.net > From kevin.rushforth at oracle.com Fri Jan 27 02:08:17 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 26 Jan 2017 18:08:17 -0800 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: References: <5876840F.40508@oracle.com> Message-ID: <588AAB91.9010108@oracle.com> Hi Scott, Thanks for the report. The only JDK 9 specific performance problems I have seen is with startup, which would be a good thing to discuss on jigsaw-dev. If you are seeing actual application slowdown, that might be something else, depending on where the problem is. Have you profiled your application? -- Kevin Scott Palmer wrote: > I finally managed to get my app running on JDK 9. It is based on a plugin architecture and the plugins are made accessible by modifying the system class loader at runtime (because that seemed to be the only way to make things like JAXB able to reach the classes in the plugins). That ?hack? broke with the module system so I had to find an alternative. (Now I?m using a java agent to get an Instrumentation interface so I can do it in a somewhat supported way via the appendToSystemClassLoaderSearch method.) > > Anyway, I?ve noticed that the application runs slower on Java 9. For a simple test I see almost a 10% performance drop. However, I?m not sure that it is Java FX related. I see the same throughput with the default renderer or the recently added Marlin renderer, always a bit slower than Java 8u121. I use the same JVM options, including forcing the garbage collector to use the same algorithm. > > Is there any expectation of a performance drop with JDK 9 at this stage? For example should I expect some unoptimized stuff in the EA builds? > I guess the jigsaw-dev alias the right place to bring this up? > > I have a feeling it is going to be difficult to track down. :-( > > I have noticed a couple layout issues fixed with JavaFX 9. Stuff that used to ?snap into place? only when I resized a dialog now seems to be correct when the dialog first appears. Thanks for that! > > Regards, > > Scott > > > >> On Jan 11, 2017, at 2:14 PM, Kevin Rushforth wrote: >> >> As you may know JDK 9 has hit the feature extension complete milestone [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need to know about them in order to fix them. Our focus will be on bugs that are new in JDK 9 (regressions). >> >> I ask all JavaFX developers to please download JDK 9 early access [2] and test your application. You can report any bugs via bugs.java.com [3]. If you have any questions about whether a behavior is a bug or is expected, please ask on this alias or on the jigsaw-dev alias [4]. >> >> Thank you. >> >> -- Kevin >> >> [1] http://openjdk.java.net/projects/jdk9/ >> [2] https://jdk9.java.net/download/ >> [3] http://bugreport.java.com/ >> [4] jigsaw-dev at openjdk.java.net >> >> > > From philip.race at oracle.com Fri Jan 27 02:37:52 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 26 Jan 2017 18:37:52 -0800 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <588AAB91.9010108@oracle.com> References: <5876840F.40508@oracle.com> <588AAB91.9010108@oracle.com> Message-ID: <588AB280.20604@oracle.com> Scott, What VM/bitness/platforms show this ? All or just a specific one ? -phil. On 1/26/17, 6:08 PM, Kevin Rushforth wrote: > Hi Scott, > > Thanks for the report. The only JDK 9 specific performance problems I > have seen is with startup, which would be a good thing to discuss on > jigsaw-dev. If you are seeing actual application slowdown, that might > be something else, depending on where the problem is. Have you > profiled your application? > > -- Kevin > > > Scott Palmer wrote: >> I finally managed to get my app running on JDK 9. It is based on a >> plugin architecture and the plugins are made accessible by modifying >> the system class loader at runtime (because that seemed to be the >> only way to make things like JAXB able to reach the classes in the >> plugins). That ?hack? broke with the module system so I had to find >> an alternative. (Now I?m using a java agent to get an >> Instrumentation interface so I can do it in a somewhat supported way >> via the appendToSystemClassLoaderSearch method.) >> >> Anyway, I?ve noticed that the application runs slower on Java 9. For >> a simple test I see almost a 10% performance drop. However, I?m not >> sure that it is Java FX related. I see the same throughput with the >> default renderer or the recently added Marlin renderer, always a bit >> slower than Java 8u121. I use the same JVM options, including >> forcing the garbage collector to use the same algorithm. >> >> Is there any expectation of a performance drop with JDK 9 at this >> stage? For example should I expect some unoptimized stuff in the EA >> builds? >> I guess the jigsaw-dev alias the right place to bring this up? >> >> I have a feeling it is going to be difficult to track down. :-( >> >> I have noticed a couple layout issues fixed with JavaFX 9. Stuff that >> used to ?snap into place? only when I resized a dialog now seems to >> be correct when the dialog first appears. Thanks for that! >> >> Regards, >> >> Scott >> >> >>> On Jan 11, 2017, at 2:14 PM, Kevin Rushforth >>> wrote: >>> >>> As you may know JDK 9 has hit the feature extension complete >>> milestone [1]. We still have a small number of weeks to fix P1-P3 >>> bugs, but we need to know about them in order to fix them. Our focus >>> will be on bugs that are new in JDK 9 (regressions). >>> >>> I ask all JavaFX developers to please download JDK 9 early access >>> [2] and test your application. You can report any bugs via >>> bugs.java.com [3]. If you have any questions about whether a >>> behavior is a bug or is expected, please ask on this alias or on the >>> jigsaw-dev alias [4]. >>> >>> Thank you. >>> >>> -- Kevin >>> >>> [1] http://openjdk.java.net/projects/jdk9/ >>> [2] https://jdk9.java.net/download/ >>> [3] http://bugreport.java.com/ >>> [4] jigsaw-dev at openjdk.java.net >>> >> From swpalmer at gmail.com Fri Jan 27 02:44:17 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 26 Jan 2017 21:44:17 -0500 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <588AB280.20604@oracle.com> References: <5876840F.40508@oracle.com> <588AAB91.9010108@oracle.com> <588AB280.20604@oracle.com> Message-ID: <2703811D-23ED-466A-96CB-4C9DD66E9FDE@gmail.com> I?ve only tested with Java 9 on Windows 10 64-bit so far. I have not yet done any profiling to try to isolate where the difference might be. The application generates data in native code, wrapped in a native ByteBuffer and passes an object around holding the buffer and map of properties to go with it. I?m doing virtually no processing on the data and just measuring the rate that packets are going through the workflow so far. The GUI is mostly static during the test except for a table and some labels showing stats that are updated with bitrates, packet rates, timestamps etc. I?ll continue to try to isolate a test case that I can share as time allows. I should be able to get some testing done on Mac and Linux as well and will send a followup email with any new information. Regards, Scott > On Jan 26, 2017, at 9:37 PM, Philip Race wrote: > > Scott, > > What VM/bitness/platforms show this ? All or just a specific one ? > > -phil. > > On 1/26/17, 6:08 PM, Kevin Rushforth wrote: >> Hi Scott, >> >> Thanks for the report. The only JDK 9 specific performance problems I have seen is with startup, which would be a good thing to discuss on jigsaw-dev. If you are seeing actual application slowdown, that might be something else, depending on where the problem is. Have you profiled your application? >> >> -- Kevin >> >> >> Scott Palmer wrote: >>> I finally managed to get my app running on JDK 9. It is based on a plugin architecture and the plugins are made accessible by modifying the system class loader at runtime (because that seemed to be the only way to make things like JAXB able to reach the classes in the plugins). That ?hack? broke with the module system so I had to find an alternative. (Now I?m using a java agent to get an Instrumentation interface so I can do it in a somewhat supported way via the appendToSystemClassLoaderSearch method.) >>> >>> Anyway, I?ve noticed that the application runs slower on Java 9. For a simple test I see almost a 10% performance drop. However, I?m not sure that it is Java FX related. I see the same throughput with the default renderer or the recently added Marlin renderer, always a bit slower than Java 8u121. I use the same JVM options, including forcing the garbage collector to use the same algorithm. >>> >>> Is there any expectation of a performance drop with JDK 9 at this stage? For example should I expect some unoptimized stuff in the EA builds? >>> I guess the jigsaw-dev alias the right place to bring this up? >>> >>> I have a feeling it is going to be difficult to track down. :-( >>> >>> I have noticed a couple layout issues fixed with JavaFX 9. Stuff that used to ?snap into place? only when I resized a dialog now seems to be correct when the dialog first appears. Thanks for that! >>> >>> Regards, >>> >>> Scott >>> >>> >>>> On Jan 11, 2017, at 2:14 PM, Kevin Rushforth wrote: >>>> >>>> As you may know JDK 9 has hit the feature extension complete milestone [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need to know about them in order to fix them. Our focus will be on bugs that are new in JDK 9 (regressions). >>>> >>>> I ask all JavaFX developers to please download JDK 9 early access [2] and test your application. You can report any bugs via bugs.java.com [3]. If you have any questions about whether a behavior is a bug or is expected, please ask on this alias or on the jigsaw-dev alias [4]. >>>> >>>> Thank you. >>>> >>>> -- Kevin >>>> >>>> [1] http://openjdk.java.net/projects/jdk9/ >>>> [2] https://jdk9.java.net/download/ >>>> [3] http://bugreport.java.com/ >>>> [4] jigsaw-dev at openjdk.java.net >>>> >>> From philip.race at oracle.com Fri Jan 27 02:56:52 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 26 Jan 2017 18:56:52 -0800 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <2703811D-23ED-466A-96CB-4C9DD66E9FDE@gmail.com> References: <5876840F.40508@oracle.com> <588AAB91.9010108@oracle.com> <588AB280.20604@oracle.com> <2703811D-23ED-466A-96CB-4C9DD66E9FDE@gmail.com> Message-ID: <588AB6F4.30800@oracle.com> I was asking about the VM not the O/S. 32 bit or 64 bit in this case. Notably the 32 bit client VM is gone so you get the 32 bit server VM. That could make a difference, although in theory the server VM performs better - so long as it does not run out of memory. -phil. On 1/26/17, 6:44 PM, Scott Palmer wrote: > I?ve only tested with Java 9 on Windows 10 64-bit so far. > > I have not yet done any profiling to try to isolate where the difference might be. The application generates data in native code, wrapped in a native ByteBuffer and passes an object around holding the buffer and map of properties to go with it. I?m doing virtually no processing on the data and just measuring the rate that packets are going through the workflow so far. The GUI is mostly static during the test except for a table and some labels showing stats that are updated with bitrates, packet rates, timestamps etc. > > I?ll continue to try to isolate a test case that I can share as time allows. I should be able to get some testing done on Mac and Linux as well and will send a followup email with any new information. > > Regards, > > Scott > > >> On Jan 26, 2017, at 9:37 PM, Philip Race wrote: >> >> Scott, >> >> What VM/bitness/platforms show this ? All or just a specific one ? >> >> -phil. >> >> On 1/26/17, 6:08 PM, Kevin Rushforth wrote: >>> Hi Scott, >>> >>> Thanks for the report. The only JDK 9 specific performance problems I have seen is with startup, which would be a good thing to discuss on jigsaw-dev. If you are seeing actual application slowdown, that might be something else, depending on where the problem is. Have you profiled your application? >>> >>> -- Kevin >>> >>> >>> Scott Palmer wrote: >>>> I finally managed to get my app running on JDK 9. It is based on a plugin architecture and the plugins are made accessible by modifying the system class loader at runtime (because that seemed to be the only way to make things like JAXB able to reach the classes in the plugins). That ?hack? broke with the module system so I had to find an alternative. (Now I?m using a java agent to get an Instrumentation interface so I can do it in a somewhat supported way via the appendToSystemClassLoaderSearch method.) >>>> >>>> Anyway, I?ve noticed that the application runs slower on Java 9. For a simple test I see almost a 10% performance drop. However, I?m not sure that it is Java FX related. I see the same throughput with the default renderer or the recently added Marlin renderer, always a bit slower than Java 8u121. I use the same JVM options, including forcing the garbage collector to use the same algorithm. >>>> >>>> Is there any expectation of a performance drop with JDK 9 at this stage? For example should I expect some unoptimized stuff in the EA builds? >>>> I guess the jigsaw-dev alias the right place to bring this up? >>>> >>>> I have a feeling it is going to be difficult to track down. :-( >>>> >>>> I have noticed a couple layout issues fixed with JavaFX 9. Stuff that used to ?snap into place? only when I resized a dialog now seems to be correct when the dialog first appears. Thanks for that! >>>> >>>> Regards, >>>> >>>> Scott >>>> >>>> >>>>> On Jan 11, 2017, at 2:14 PM, Kevin Rushforth wrote: >>>>> >>>>> As you may know JDK 9 has hit the feature extension complete milestone [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need to know about them in order to fix them. Our focus will be on bugs that are new in JDK 9 (regressions). >>>>> >>>>> I ask all JavaFX developers to please download JDK 9 early access [2] and test your application. You can report any bugs via bugs.java.com [3]. If you have any questions about whether a behavior is a bug or is expected, please ask on this alias or on the jigsaw-dev alias [4]. >>>>> >>>>> Thank you. >>>>> >>>>> -- Kevin >>>>> >>>>> [1] http://openjdk.java.net/projects/jdk9/ >>>>> [2] https://jdk9.java.net/download/ >>>>> [3] http://bugreport.java.com/ >>>>> [4] jigsaw-dev at openjdk.java.net >>>>> From swpalmer at gmail.com Fri Jan 27 03:06:00 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 26 Jan 2017 22:06:00 -0500 Subject: Testing your JavaFX applications on JDK 9 In-Reply-To: <588AB6F4.30800@oracle.com> References: <5876840F.40508@oracle.com> <588AAB91.9010108@oracle.com> <588AB280.20604@oracle.com> <2703811D-23ED-466A-96CB-4C9DD66E9FDE@gmail.com> <588AB6F4.30800@oracle.com> Message-ID: Sorry, I believe I'm running a 64-bit JRE in both cases. I will verify when I?m back in the office tomorrow. Scott > On Jan 26, 2017, at 9:56 PM, Philip Race wrote: > > I was asking about the VM not the O/S. > > 32 bit or 64 bit in this case. > > Notably the 32 bit client VM is gone so you get the 32 bit server VM. > That could make a difference, although in theory the server VM performs better - so > long as it does not run out of memory. > > -phil. > > On 1/26/17, 6:44 PM, Scott Palmer wrote: >> I?ve only tested with Java 9 on Windows 10 64-bit so far. >> >> I have not yet done any profiling to try to isolate where the difference might be. The application generates data in native code, wrapped in a native ByteBuffer and passes an object around holding the buffer and map of properties to go with it. I?m doing virtually no processing on the data and just measuring the rate that packets are going through the workflow so far. The GUI is mostly static during the test except for a table and some labels showing stats that are updated with bitrates, packet rates, timestamps etc. >> >> I?ll continue to try to isolate a test case that I can share as time allows. I should be able to get some testing done on Mac and Linux as well and will send a followup email with any new information. >> >> Regards, >> >> Scott >> >> >>> On Jan 26, 2017, at 9:37 PM, Philip Race wrote: >>> >>> Scott, >>> >>> What VM/bitness/platforms show this ? All or just a specific one ? >>> >>> -phil. >>> >>> On 1/26/17, 6:08 PM, Kevin Rushforth wrote: >>>> Hi Scott, >>>> >>>> Thanks for the report. The only JDK 9 specific performance problems I have seen is with startup, which would be a good thing to discuss on jigsaw-dev. If you are seeing actual application slowdown, that might be something else, depending on where the problem is. Have you profiled your application? >>>> >>>> -- Kevin >>>> >>>> >>>> Scott Palmer wrote: >>>>> I finally managed to get my app running on JDK 9. It is based on a plugin architecture and the plugins are made accessible by modifying the system class loader at runtime (because that seemed to be the only way to make things like JAXB able to reach the classes in the plugins). That ?hack? broke with the module system so I had to find an alternative. (Now I?m using a java agent to get an Instrumentation interface so I can do it in a somewhat supported way via the appendToSystemClassLoaderSearch method.) >>>>> >>>>> Anyway, I?ve noticed that the application runs slower on Java 9. For a simple test I see almost a 10% performance drop. However, I?m not sure that it is Java FX related. I see the same throughput with the default renderer or the recently added Marlin renderer, always a bit slower than Java 8u121. I use the same JVM options, including forcing the garbage collector to use the same algorithm. >>>>> >>>>> Is there any expectation of a performance drop with JDK 9 at this stage? For example should I expect some unoptimized stuff in the EA builds? >>>>> I guess the jigsaw-dev alias the right place to bring this up? >>>>> >>>>> I have a feeling it is going to be difficult to track down. :-( >>>>> >>>>> I have noticed a couple layout issues fixed with JavaFX 9. Stuff that used to ?snap into place? only when I resized a dialog now seems to be correct when the dialog first appears. Thanks for that! >>>>> >>>>> Regards, >>>>> >>>>> Scott >>>>> >>>>> >>>>>> On Jan 11, 2017, at 2:14 PM, Kevin Rushforth wrote: >>>>>> >>>>>> As you may know JDK 9 has hit the feature extension complete milestone [1]. We still have a small number of weeks to fix P1-P3 bugs, but we need to know about them in order to fix them. Our focus will be on bugs that are new in JDK 9 (regressions). >>>>>> >>>>>> I ask all JavaFX developers to please download JDK 9 early access [2] and test your application. You can report any bugs via bugs.java.com [3]. If you have any questions about whether a behavior is a bug or is expected, please ask on this alias or on the jigsaw-dev alias [4]. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> [1] http://openjdk.java.net/projects/jdk9/ >>>>>> [2] https://jdk9.java.net/download/ >>>>>> [3] http://bugreport.java.com/ >>>>>> [4] jigsaw-dev at openjdk.java.net >>>>>> From guru.hb at oracle.com Fri Jan 27 14:05:06 2017 From: guru.hb at oracle.com (Guru Hb) Date: Fri, 27 Jan 2017 19:35:06 +0530 Subject: CFV: New OpenJFX Committer: Semyon Sadetsky In-Reply-To: <5888FF0F.5010509@Oracle.com> References: <5888FF0F.5010509@Oracle.com> Message-ID: <601C969D-BEEE-4FED-8E54-5E02AF6E629E@oracle.com> Vote: YES > On 26-Jan-2017, at 1:09 AM, David Hill wrote: > > > I hereby nominate Semyon Sadetsky to OpenJFX Committer. > > Semyon Sadetsky is part of the JavaFX team focusing on glass. > > A list of Semyon's commits and reviews is available by the following links > > http://hg.openjdk.java.net/openjfx/9-dev/rt/log?rev=author%28ssadetsky%29 > > Votes are due by Feb 9th, 2017. > > Only current OpenJFX Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. Nomination to a project Committer is described in [3]. > > [1] http://openjdk.java.net/census#openjfx > > [2] http://openjdk.java.net/bylaws#lazy-consensus > > [3] http://openjdk.java.net/projects#project-committer > > Thanks, > > Dave From jonathan.giles at oracle.com Sun Jan 29 21:31:05 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 30 Jan 2017 10:31:05 +1300 Subject: 8173385: spelling errors in JavaFX javadoc Message-ID: <45026449-0fd5-29e2-33cc-5675afea360a@oracle.com> Ajit, Could you please review the following jira issue and webrev: https://bugs.openjdk.java.net/browse/JDK-8173385 http://cr.openjdk.java.net/~jgiles/8173385/ Thanks -- -- Jonathan From semyon.sadetsky at oracle.com Mon Jan 30 15:32:13 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 30 Jan 2017 18:32:13 +0300 Subject: [9] Review request for 8152421: After initing the modality of a non-primary stage to MODAL, closing that stage causes the primary stage to become non-resizable Message-ID: Hello Kevin & David, Please review the fix for jfx9: bug: https://bugs.openjdk.java.net/browse/JDK-8152421 webrev: http://cr.openjdk.java.net/~ssadetsky/8152421/webrev.01/ Set window enabled logic is updated to restore window resizability correctly. --Semyon From kevin.rushforth at oracle.com Mon Jan 30 18:31:57 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Jan 2017 10:31:57 -0800 Subject: [9] Review request: 8172950: JavaFX 9 l10n resource file update - msgdrop 30 Message-ID: <588F869D.3040408@oracle.com> Chris, Please review the following translation drop for JavaFX 9: https://bugs.openjdk.java.net/browse/JDK-8172950 http://cr.openjdk.java.net/~kcr/8172950/webrev.00/ I verified that the list of files is as expected, and and the list of properties in each file matches, with the exception of two property strings that were newly added last week in the English files. We will pick those two up in the next translation drop. -- Kevin From james.graham at oracle.com Mon Jan 30 21:30:08 2017 From: james.graham at oracle.com (Jim Graham) Date: Mon, 30 Jan 2017 13:30:08 -0800 Subject: 8173385: spelling errors in JavaFX javadoc In-Reply-To: <45026449-0fd5-29e2-33cc-5675afea360a@oracle.com> References: <45026449-0fd5-29e2-33cc-5675afea360a@oracle.com> Message-ID: The spelling changes look right, but "of Foo method" bothers me - it should be "of the Foo method". The same comment would reply to the retainAll doc comment... :( ...jim On 1/29/17 1:31 PM, Jonathan Giles wrote: > Ajit, > > Could you please review the following jira issue and webrev: > > https://bugs.openjdk.java.net/browse/JDK-8173385 > > http://cr.openjdk.java.net/~jgiles/8173385/ > > Thanks > From jonathan.giles at oracle.com Mon Jan 30 21:37:58 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 31 Jan 2017 10:37:58 +1300 Subject: 8173385: spelling errors in JavaFX javadoc In-Reply-To: References: <45026449-0fd5-29e2-33cc-5675afea360a@oracle.com> Message-ID: <708ad61a-6e9c-f051-4723-593efe6f66b5@oracle.com> I fear we might be seeing the beginning of a snowball of small javadoc cleanups :-) In any case, I have now posted a third revision to include fixes identified by Ajit, Kevin, and Jim (as well as a few of my own) here: http://cr.openjdk.java.net/~jgiles/8173385.3/ Further discussion can continue in https://bugs.openjdk.java.net/browse/JDK-8173385 -- Jonathan On 31/01/17 10:30 AM, Jim Graham wrote: > The spelling changes look right, but "of Foo method" bothers me - it > should be "of the Foo method". The same comment would reply to the > retainAll doc comment... :( > > ...jim > > On 1/29/17 1:31 PM, Jonathan Giles wrote: >> Ajit, >> >> Could you please review the following jira issue and webrev: >> >> https://bugs.openjdk.java.net/browse/JDK-8173385 >> >> http://cr.openjdk.java.net/~jgiles/8173385/ >> >> Thanks >> From yuri.nesterenko at oracle.com Tue Jan 31 13:03:25 2017 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 31 Jan 2017 16:03:25 +0300 Subject: [9] Review request: JDK-8170979: Update for Jigsaw etc. the openFX functional tests In-Reply-To: <90f3a0f8-b3bf-4d16-f840-3571d29127df@oracle.com> References: <146f2adf-ee57-0c79-1a73-1b97798e6c8a@oracle.com> <5b29377e-b016-83b0-98da-db03d315a3b8@oracle.com> <90f3a0f8-b3bf-4d16-f840-3571d29127df@oracle.com> Message-ID: <4587affd-3d44-c322-2bc2-0fcedf6c7923@oracle.com> And once more: http://cr.openjdk.java.net/~yan/8170979/webrev.04 Added: a port of JDK-8138872; a change in javaclient/shared/screenshots/GoldenImageManager.java to allow it find old golden images. In the index.html there's a list of 10 files to remove after the patch applied. Webrev script includes only 4 of them in the patch. I tried to commit the change, jcheck has nothing against it. We use this state of the tests (plus a closed part, and our own svn storage for images) to run in ATR. If not to analyze. Thank you! -yan On 12/29/2016 04:38 PM, Yuri Nesterenko wrote: > And again: > http://cr.openjdk.java.net/~yan/8170979/webrev.03 > > (Discussion in the bug) > Unfortunately, webrev doesn't process properly > files deleted by 'hg rm' . > > -yan > > On 12/22/2016 12:07 PM, Yuri Nesterenko wrote: >> A new version is here: >> http://cr.openjdk.java.net/~yan/8170979/webrev.01 >> (trailing spaces removed). >> See also discussion in the bug report: >> https://bugs.openjdk.java.net/browse/JDK-8170979 >> thank you, Kevin! >> >> -yan >> >> On 12/21/2016 12:19 PM, Yuri Nesterenko wrote: >>> A gentle reminder. >>> Without this change, we have to make All Test Run out of >>> the makeshift workspace. >>> >>> Thanks, >>> -yan >>> >>> On 12/09/2016 02:02 PM, Yuri Nesterenko wrote: >>>> Colleagues, >>>> >>>> please review this test bug fix: >>>> http://cr.openjdk.java.net/~yan/8170979/webrev.00/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170979 >>>> >>>> >>>> The changes are mostly in tests/functional/. >>>> >>>> This is a merge of current testbase in >>>> http://hg.openjdk.java.net/openjfx/9-dev/tests and whatever >>>> we have internally. The tests should now compile and work >>>> with Jigsaw (including b148, --add-opens), recognize already >>>> not too new JDK directory structure, do not use Builders etc. >>>> Small number of tests was excluded and even dropped for various >>>> reasons. >>>> Several suites were tested with b142-b146 and PIT build for >>>> the recent Jigsaw update (re: --add-opens). >>>> >>>> There are still some reservations and unanswered questions. >>>> For instance, a hard monotonous work of creation and maintaining >>>> of the so called golden images is up to a tester: I don't know a >>>> good place to share them between independent teams. >>>> A couple of the suites still won't start without a minor >>>> reconfiguration beforehand, not always properly documented. >>>> We intend to use this state of the tests for the next massive test run >>>> starting from jdk9 b150. >>> >> > > From ajit.ghaisas at oracle.com Tue Jan 31 18:20:24 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Tue, 31 Jan 2017 10:20:24 -0800 (PST) Subject: [9] Review request : JDK-8089875 : MenuBarSkin does not update if a menu changes its visibility. Message-ID: <62a7437c-f41d-48d7-87e3-d2b871b14e38@default> Hi Jonathan, Request you to review following fix : Menus that were added after MenuBarSkin construction never used to trigger UI rebuilding if their visible property changed. Bug : https://bugs.openjdk.java.net/browse/JDK-8089875 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8089875/webrev.0/ Regards, Ajit From vadim.pakhnushev at oracle.com Tue Jan 31 19:16:33 2017 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 31 Jan 2017 22:16:33 +0300 Subject: [9] Review request for 8173468: Font.loadFont returns null on some Ubuntu 32bits Message-ID: Hi Phil, Could you please review the fix inline in the bug: https://bugs.openjdk.java.net/browse/JDK-8173468 Thanks, Vadim From David.Hill at Oracle.com Tue Jan 31 19:28:34 2017 From: David.Hill at Oracle.com (David Hill) Date: Tue, 31 Jan 2017 14:28:34 -0500 Subject: review: add developer script whatsChanged Message-ID: <5890E562.3000002@Oracle.com> Kevin, please review this developer script: jbs: https://bugs.openjdk.java.net/browse/JDK-8173696 webrev: http://cr.openjdk.java.net/~ddhill/8173696 -- 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)