From prasanta.sadhukhan at oracle.com Fri Sep 1 10:26:40 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 1 Sep 2017 15:56:40 +0530 Subject: [10] RFR JDK-8156042:Modifiers of swing ActionEvent does not work when "-Djavafx.embed.singleThread=true" Message-ID: Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8156042/webrev.00/ for fx issue https://bugs.openjdk.java.net/browse/JDK-8156042 More info in JBS. Regards Prasanta From bourges.laurent at gmail.com Fri Sep 1 20:56:17 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 1 Sep 2017 22:56:17 +0200 Subject: Fwd: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> Message-ID: CCing the mailing-lists Hi Jim, I read carefully your very good inputs on clipping / filtering in both Renderer or PreFilter. Here are my comments (in the discussion order): On 8/31/17 4:15 PM, Jim Graham wrote: > > - It can stop processing when it reaches the right edge of the clip as the > crossings out there have no impact on anything that will be rendered > Not exactly, the Renderer needs at least one crossing on the right side to determine the current span end. However, I added a shortcut to quickly exit from the loop on the right side. To act as you said, a post loop code should be added to see if the count is > 0 and that would mean the current span should be emitted until the right side. > The only thing missing for curves is that they might be rejected in their > entirety, or we might be able to pare them down to only the pieces that > need to be processed. Currently they will be rejected as they feed their > pieces to addLine() and it rejects each segment in turn, but we might be > able to short circuit the process by looking at their control points up > front before we run DDA on them. > I totally agree and I already implemented such quad/curve shortcut in my own Renderer variant (minor gain) and that could benefit to either Stroker and the filling case notably on the left / right sides. > If a curve is more complicated in how it interacts with the > top/bot/left/right clip coordinates, then it might still be rejected, or it > might need to be partially rendered. Something is going to need to do some > computation to figure that out. If we try to do those computations before > we get to the Renderer, then whatever computations we use to do that will > likely be just as complicated as the DDA work done inside the Renderer. > That work as a "pre-filter" will also be complicated in that it will then > need to express its results as a "simplified, but connected" path rather > than simply dropping pieces on the floor as the Renderer can do. > Agreed. I do not want to duplicate such complicated code, only 80% gain (pareto rule) so my current PathClipFilter only rejects trivial segments and rely on the Renderer to efficiently deal with more complex cases. > Now, it is possible that we could sub-divide a curve that has no simple > out-code rejection criteria - for example a curve that starts above the > clip, but horizontally "over" it, extends around the upper-right corner of > the clip to a position that is to the right of the clip, but within its > vertical bounds. Such a curve would not be rejected by any "all Y "all X>right" tests. It might be true that you could cut it at some point > on the curve (and you might even be lucky enough that a midpoint cut would > suffice) and each half of the curve would then pass the rejection criteria, > but you'd have to analyze the curve to figure that out. It is just as > likely that while the control points follow the pattern I outlined at the > start of this paragraph, the actual traced outline goes inside the clip. > You won't know until you perform some calculations. In the meantime, the > Renderer already does a pretty fast DDA subsection of the curve and those > pieces are then rejected by addLine() each in turn. How sure can you be > that you can find a computation for such curves that will be successful in > enough cases that you will save time over DDA? How often are curves even > in this particular situation in the first place? If only .1% of curves > ever benefit from this analysis then you might slow down the common case to > be slightly faster in a rare case. > As I said, let's try to Keep It Simple Silly for now. Although, I could later perform one subdivision step (line, quad, curve) for TOP <-> LEFT <-> BOTTOM <-> RIGHT transitions and try again a trivial reject test (all control points outside) but only for large enough curves / lines. It will benefit to large filled circles but I agree it is a corner case. > Finally, if there is some calculation that could be performed on such "not > immediately rejectable, but possibly outside" curves to simplify their > processing, the best place for those calculations is still in the Renderer > where its response to finding a piece of a curve that is trivially > rejectable is to just skip it, rather than a pre-filter which will have to > worry about how to connect the path around the skipped pieces. > I disagree: the Renderer class has already several variants (maintainability issue) and it very complex so I want to leave it untouched as most as possible and externalize that supplementary stage into the rendering pipeline. The Stroker webrev works like a charm and it already performs path filtering. Modifying the Renderer will mean that the path filtering will be done twice or that Stroker should indicate to not filter twice the segments ! > > So, in the end, I don't see any situation - including any calculation that > you think could help reject pieces faster - that would be better served as > a filter run ahead of Renderer that can't be more optimally done by adding > code to the Renderer and simply dropping pieces on the floor...? > I already tried to explain an interesting case: closed subpaths on the left or right sides are bringing lots of edges into the Renderer bag that cost a lot due to the scanline processing (crossing inc, sort, spans ...). I prefer coding an external simplifier compatible with Renderer, than complexifying the Renderer itself to record subpaths, test outcodes that would add more complexity, code lines... > > On 8/31/17 1:34 PM, Laurent Bourg?s wrote: > >> Another case: you provided a Test class using a path made with 10000 line >> segments on the left side. If it is converted by createStrokedShape(), then >> the Renderer will again deal with thousands crossings and it will be slow >> again. >> > > Such a case will already be handled by the clipping in the Stroker, though > - work that you've already done in these webrevs. > Yes that works well with Stroker. As I explained such huge polyline can be converted to a polygon by calling createStrokedShape() and then rendered by fill(shape): - unclipped: 300ms - (experimental) clipped path: 4ms (twice slower than Stroker as there is twice more segments as the shape was completely stroked) > For the Even-odd filling rule, I think it needs exact segment >> intersections on the left side, so I am focused on the Non-zero filling >> rule for now. >> > > They are identical. All that matters is that you have the proper starting > winding count as you enter the clip from the left. They could be replaced > by either a segment with the same "Y range" as I mention above, or they > could be replaced by having a value in the segments list that is "starting > count", so if you have a segment that is out-left and it goes from Y=10 to > Y=20, you simply add (or subtract for reversed lines) one to the "starting > count" field for all scanlines from 10->20. > I am still very skeptic with EO rule as I am not sure it was equivalent as shapes can have self intersections ... or curve / line intersections on the left side that could lead to different accumulated count. After reading several times your explanations, I understand that on the left side (outside): - curves / quads can be simplified to a simple line (P0 to P3), but what about intersections in the middle of the curves ? should the Y range be set to min(curveY), max(curveY) that is not easy to solve ... - quad/curve/line segments can not be skipped with the EO rule to preserve the Y ranges properly. Am I right ? Maybe your later approach is interesting to introduce a new starting_counts array along the Y axis to increment / decrement and then it would be possible to totally ignore invisible segments on the left side ? > Finally I tried two approach: >> - basic subpath outside test (derived from the ClosedPathDetector) to >> ignore closed sub-paths outside of the clip. >> - more general clipper that follows the path, detect enter/exit the clip >> but it needs to insert/remove corner points. I am improving this latter >> approach. >> > > Consider that your filter that works ahead of the Renderer will need to > deal with the following issues: > > - detecting if the segments are out-top/bottom/right and drop them > - A filter will then need to worry how to connect those paths back to > the rest > - Renderer can just drop them, end of story > On right side, Renderer need a 'closing' span edge. > - detecting if the segments are out-left and manage the winding counts > - A filter will need to manage that plus it will have to connect the > paths > - Renderer can just do addLine() or adjust "scanline-starting-count", > end of story > But addLine() is the origin of the performance issue = extra cost of processing extra crossings ! > - worrying about paths that loop around the entire clip, perhaps winding > several times around the clip before they dive back into the clip rectangle > - A filter has to construct a meaningful path to represent that same > outcome > - Renderer just discards all pieces that aren't out-left and > just manages the "starting count" for just the out-left parts > Thanks for the filter specifications I am working on. I will find a compromise between rejecting segments and preserving accuracy while providing better performance for the NZ rule as EO seems too complicated to me (later ?). 2017-09-01 1:37 GMT+02:00 Jim Graham : > I had another thought here. > > If you have some plan where you can identify incoming paths as "probably > benefiting from more aggressive clipping logic" vs others that are > classified as "most likely will have little to no clipping" and you want to > avoid the overhead of having the early-rejection clipping logic on all > paths, then a simple tweak to the design of the Renderer would make it much > easier. > > Right now Renderer is both a "bag of segments with a scan-line sampling > loop" and it is also a PathConsumer2D. If you want to insert something > ahead of it, it makes logical sense to have that delegating class > communicate downstream to the Renderer via PathConsumer2D. > > But, we could remove the PathConsumer2D from Renderer and turn it into > just a "bag of segments" that is managed by an external PathConsumer2D > helper class. Basically, take all of the PC2D methods in Renderer and move > them into an UnclippedFiller class - just cut and paste. The new class > will need a pointer to a Renderer object and it will only call r.addLine() > and r.fooBreakIntoLines*() calls. It would actually be a very small class > since the PC2D interface was such a tiny portion of what Renderer > implemented. The new helper class will manage all > sub-path/moveto/close-path awareness on its own with the Renderer being > unaware of such distinctions. > > This should be computationally identical to the Renderer we have now - no > new methods are inserted, they are just moved to a different class. But by > separating out the PC2D methods into a separate class, we have the > flexibility to have different ways for the PC2D chain to interact with the > Renderer. > > This would let us create an analogous sister class - ClippedFiller - that > does the same thing, but adds some early rejection computations as well. > This is a simpler design than what you are attempting now because its > output is only "segments to add to the bag of segments", not "well-behaved > PC2D paths". > > But, if there is no easy way to identify paths up front as "we should > pre-clip this" or "not" then this isn't really needed - just add the > necessary logic to Renderer instead... > My Stroker webrev relies on the current Renderer ability to clip properly top/bottom and manages the shape boundaries. My PathClipFiller is only applied in the filling case (low overhead). As your approach is very generic, it would be a good idea to extract that clip part for better maintainability and simplify the Renderer code. However, the Renderer deals with subpixel coordinates so its clip is scaled and both addLine() and fooBreakIntoLines() should be adapted to handle the subpixel scaling factors. 2017-09-01 1:55 GMT+02:00 Jim Graham : > I want to elaborate on winding count issues for segments to the left of > the clip for both winding modes. > Thanks as it is not obvious to me ! All curves have the property that the winding count of any sample point to > the right of them is identical to the winding count of a line from their > starting point to their ending point. > > Consider a quad. If it is monotonic, then the observation should be > fairly obvious as the curve only ever has one crossing for any scanline and > only the X location of that crossing varies and it only varies within the > bounds of the X coordinates of all of 3 defining points. Once you are to > the right of all 3 X coordinates, the winding count is uniformly a single > value over the entire Y range of the (monotonic) quad. > > Consider a quad with a vertical reversal. If one of the endpoints is > higher than the other, then in the area between the Y coordinates of the > endpoints it will increase or decrease the winding count by only 1, and the > sign of that winding count change will be identical to a segment that > connects the two endpoints. For the rest of the quad, the part where it > doubles back on itself, those 2 parts of the path cancel each other out. > You either have a downward portion that curves into an upward portion, or > vice versa. In both cases, that portion has a resulting winding count of 0 > because the direction of those 2 parts of the curve are opposite. > But if the polygon has self intersections, then a line can cross the vertical reversal and its position will depend on the exact curve, so the accumulated winding count will be different along the Y axis. > A cubic is more complicated with more cases to consider, but if you > diagram it out you can see that the winding count contribution off to the > right of the cubic will be identical in all cases to the winding count > contribution of a line segment joining the two endpoints. You can have up > to 3 reversals, but all reversals that are above or below the end points > will be paired with each other and all reversals within the Y range of the > end points will either result in 1 or 3 competing pieces and the 1 or the > majority of the 3 will be in the same direction/sign as the direction/sign > of the segment between the endpoints. If there are 3 then 2 will cancel > out and the remaining one will be the same direction as the endpoint line > segment. > > So, all path segments, regardless of line/quad/cubic that lie entirely to > the left of the clip have identical winding count to a simple line segment. > But that also means that in the EO case, it is not possible to ignore any line segment on the left side ? And with the proper winding count computed, the winding mode has no impact, > the same winding count is appropriate and accurate whether the entire path > is EO or NZ... > I am still skeptical on the winding rules ... will try to study some concrete examples. Thanks again, Laurent -- -- Laurent Bourg?s From bourges.laurent at gmail.com Fri Sep 1 21:09:18 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 1 Sep 2017 23:09:18 +0200 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> Message-ID: Jim, Here is the current code for my experimental PathClipFilter only to show you what I have done so far: - DMarlingRenderingEngine.getAATileGenerator(): ... // fill shape: final PathIterator pi = norm.getNormalizingPathIterator(rdrCtx, s.getPathIterator(_at)); final int windingRule = pi.getWindingRule(); // note: Winding rule may be EvenOdd ONLY for fill operations ! r = rdrCtx.renderer.init(clip.getLoX(), clip.getLoY(), clip.getWidth(), clip.getHeight(), windingRule); if (windingRule == WIND_NON_ZERO) { DPathConsumer2D pc2d = r; if (rdrCtx.doClip) { pc2d = rdrCtx.transformerPC2D.pathClipper(pc2d); } // TODO: subdivide quad/cubic curves into monotonic curves ? pathTo(rdrCtx, pi, pc2d); } - PathClipper: static final class GeneralPathClipper implements DPathConsumer2D { private DPathConsumer2D out; // Bounds of the drawing region, at pixel precision. private final double[] clipRect; // the outcode of the starting point private int sOutCode = 0; // the current outcode of the current sub path private int cOutCode = 0; GeneralPathClipper(final DRendererContext rdrCtx) { this.clipRect = rdrCtx.clipRect; } GeneralPathClipper init(final DPathConsumer2D out) { this.out = out; // Adjust the clipping rectangle with the renderer offsets final double rdrOffX = DRenderer.RDR_OFFSET_X; final double rdrOffY = DRenderer.RDR_OFFSET_Y; final double[] _clipRect = this.clipRect; _clipRect[0] += rdrOffY; _clipRect[1] += rdrOffY; _clipRect[2] += rdrOffX; _clipRect[3] += rdrOffX; return this; // fluent API } @Override public void pathDone() { out.pathDone(); } @Override public void closePath() { out.closePath(); this.cOutCode = sOutCode; } private void finish() { if (outside) { this.outside = false; out.lineTo(cx0, cy0); } } @Override public void moveTo(final double x0, final double y0) { final int outcode = DHelpers.outcode(x0, y0, clipRect); // basic rejection criteria this.sOutCode = outcode; this.cOutCode = outcode; this.outside = false; out.moveTo(x0, y0); } boolean outside = false; double cx0, cy0; @Override public void lineTo(final double x1, final double y1) { final int outcode0 = this.cOutCode; final int outcode1 = DHelpers.outcode(x1, y1, clipRect); this.cOutCode = outcode1; final int sidecode = (outcode0 & outcode1); // basic rejection criteria: if (sidecode != 0) { // top or bottom or same: if ((outcode0 == outcode1) || ((sidecode & DHelpers.OUTCODE_MASK_T_B) != 0) ) { // corner or cross-boundary this.outside = true; // TODO: add to outside stack (throw if never enter again ?) this.cx0 = x1; this.cy0 = y1; return; } else { // corner or cross-boundary on left or right side: // TODO: add to outside stack (throw if never enter again ?) // line(P0-P1) } } finish(); // clipping disabled: out.lineTo(x1, y1); } @Override public void curveTo(final double x1, final double y1, final double x2, final double y2, final double x3, final double y3) { final int outcode0 = this.cOutCode; final int outcode3 = DHelpers.outcode(x3, y3, clipRect); this.cOutCode = outcode3; // TODO: optimize ? final int outcode1 = DHelpers.outcode(x1, y1, clipRect); final int outcode2 = DHelpers.outcode(x2, y2, clipRect); // basic rejection criteria if ((outcode0 & outcode1 & outcode2 & outcode3) != 0) { // Different quadrant ? if ((outcode0 == outcode3) && (outcode0 == outcode1) && (outcode0 == outcode2)) { // corner or cross-boundary this.outside = true; // TODO: add to outside stack (throw if never enter again ?) this.cx0 = x3; this.cy0 = y3; return; } else { // corner or cross-boundary // TODO: add to outside stack (throw if never enter again ?) // line(P0-P1) finish(); // clipping disabled: out.lineTo(x3, y3); return; } } finish(); // clipping disabled: out.curveTo(x1, y1, x2, y2, x3, y3); } @Override public void quadTo(final double x1, final double y1, final double x2, final double y2) { final int outcode0 = this.cOutCode; final int outcode2 = DHelpers.outcode(x2, y2, clipRect); this.cOutCode = outcode2; // TODO: optimize ? final int outcode1 = DHelpers.outcode(x1, y1, clipRect); // basic rejection criteria if ((outcode0 & outcode1 & outcode2) != 0) { // Different quadrant ? if ((outcode0 == outcode2) && (outcode0 == outcode1)) { // corner or cross-boundary this.outside = true; // TODO: add to outside stack (throw if never enter again ?) this.cx0 = x2; this.cy0 = y2; return; } else { // corner or cross-boundary // TODO: add to outside stack (throw if never enter again ?) // line(P0-P1) finish(); // clipping disabled: out.lineTo(x2, y2); return; } } finish(); // clipping disabled: out.quadTo(x1, y1, x2, y2); } @Override public long getNativeConsumer() { throw new InternalError("Not using a native peer"); } } Here is a screenshot illustrating the remaining paths in Renderer after clipping a 4000x4000 spiral converted as stroked shape: http://cr.openjdk.java.net/~lbourges/png/SpiralTest-dash-false.ser.png You can see all rounds arround the clip that I expect soon to ignore too as I plan to use a corner stack to remember turining points until the path enters again or go back in reverse order... clip off: ~ 145ms clip on: ~ 106ms TODO: handle corner points & turns arround / reverse the clip Cheers, Laurent 2017-09-01 22:09 GMT+02:00 Laurent Bourg?s : > Dear Jim, > > I am not so good at explaining my early solution for NZ rule in english: > - it mimics the Stroker approach > - it skips all intermediate segments outside (except at corners ie > different outcodes) > - preserve only the last point of the entering segment > > So mostly invisible segments on the left and right sides are skipped from > the original that makes the Renderer only processing visible segments like > in the Stroker case where I opened the path. > > It improves the performance as less left / right segments are processed in > addLine(). For now the Renderer accepts all segments and only rejects > top/bottom parts and keeps all left/right edges in its processing: that > costs a lot. > > > I think we are discussing two different things. I thought you were > considering a separate filter for clipping filled only paths. I agree that > the Stroker webrev is still needed for stroked paths. We should also > create one for dashed paths that will clip before dashing. There are > multiple stages at which we can clip to reduce processing. > > > Exactly I also like the pipeline approach that decouples stages into > different parts. > > > I take that case into account. How is a prefilter that excludes those > segments any simpler than the Renderer rejecting them itself? > > Keep in mind that they are already rejected. Renderer.addLine() already > does this. In the case of a polygon, there isn't much code you can reduce > because it goes from the loop that feeds the path in the rendering engine > directly to Renderer.move/lineTo() which goes directly to addLine() which > rejects all of those segments. > > > Not on the left / right side. > Closed subpaths or extra segments can be ignored for NZ rule = only > keeping the path closed properly matters. > > Will send you the current code to illustrate the basic filter asap. > > > In the case of curves, the path is nearly as direct, but first you run a > DDA on it to break it into lines. Simply modifying Renderer.quadTo and > cubicTo to perform quick-rejection would be a very simple change (certainly > simpler than adding a new class to do that) and would reject all of those > curved segments much faster... > > > Agreed, I have done it in the past and can provide the change. > > Laurent > > -- -- Laurent Bourg?s From bszbur at gmail.com Sat Sep 2 19:14:55 2017 From: bszbur at gmail.com (Cindy Prather/massey) Date: Sat, 2 Sep 2017 15:14:55 -0400 Subject: No subject In-Reply-To: References: Message-ID: I am so sorry. Was not thinking.I'm trying to fix my browser it crashes all time..again sorry. Thanks cindy prather From prasanta.sadhukhan at oracle.com Tue Sep 5 10:24:31 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 5 Sep 2017 15:54:31 +0530 Subject: [10] RFR JDK-8087528:[SWT] FXCanvas: DnD is implemented incorrectly Message-ID: Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8087528/webrev.00/ for a fx issue https://bugs.openjdk.java.net/browse/JDK-8087528 More info in JBS. Regards Prasanta From prasanta.sadhukhan at oracle.com Tue Sep 5 10:28:11 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 5 Sep 2017 15:58:11 +0530 Subject: [10] RFR: JDK-8129747:SwingFXUtils.fromFXImage seems to have a bug inside In-Reply-To: References: Message-ID: Gentle reminder for review . Regards Prasanta On 8/30/2017 1:41 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix > http://cr.openjdk.java.net/~psadhukhan/fx/8129747/webrev.00/ > for fx issue > https://bugs.openjdk.java.net/browse/JDK-8129747 > > More info in JBS. > > Regards > Prasanta From jayathirth.d.v at oracle.com Tue Sep 5 11:42:10 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 5 Sep 2017 04:42:10 -0700 (PDT) Subject: [10] RFR: JDK-8129747:SwingFXUtils.fromFXImage seems to have a bug inside In-Reply-To: References: Message-ID: <266c1b26-5f1a-4c2d-8e21-2ba4e47b64a8@default> Hello Prasanta, Looks like after Jim's comment you have updated the code to check for PixelFormat, as PixelFormat type and BufferedImage type enum's serves different purpose. In the bug I see updated webrev : http://cr.openjdk.java.net/~psadhukhan/fx/8129747/webrev.01/ Changes in updated webrev are working fine. Thanks, Jay -----Original Message----- From: Prasanta Sadhukhan Sent: Tuesday, September 05, 2017 3:58 PM To: Kevin Rushforth; ALEXANDER.ZVEGINTSEV; openjfx-dev at openjdk.java.net Mailing Subject: Re: [10] RFR: JDK-8129747:SwingFXUtils.fromFXImage seems to have a bug inside Gentle reminder for review . Regards Prasanta On 8/30/2017 1:41 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix > http://cr.openjdk.java.net/~psadhukhan/fx/8129747/webrev.00/ > for fx issue > https://bugs.openjdk.java.net/browse/JDK-8129747 > > More info in JBS. > > Regards > Prasanta From prasanta.sadhukhan at oracle.com Tue Sep 5 16:31:22 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 5 Sep 2017 22:01:22 +0530 Subject: [10] RFR JDK-8089774: [SwingNode] getKeyLocation not correctly implemented with JavaFX Message-ID: <957c7b85-1984-9ca6-e9be-f34aa14401e6@oracle.com> Hi All, Please review a fix/enhancement cr.openjdk.java.net/~psadhukhan/fx/8089774/webrev.00/ for a fx issue https://bugs.openjdk.java.net/browse/JDK-8089774 and enhancement https://bugs.openjdk.java.net/browse/JDK-8090524 More info in JBS. Regards Prasanta From bourges.laurent at gmail.com Tue Sep 5 20:41:12 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 5 Sep 2017 22:41:12 +0200 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> Message-ID: Hi Jim, I made good progress on my PathClipFilter that works now perfectly with many test maps for the NZ rule (EO has artefacts if I enable the filter in that case). Here is the updated code below to illustrate the approach: - use a new IndexStack in (D)Helpers to store only corner indexes (0/1 for Top/Bottom Left, 2/3 for Top/Bottom Right) - when the segment is out, I now check (L/R case) if the segment ends have different outcodes to insert needed corners that can be removed later if a segment does the same in the reverse order (same repeated corner is cancelled out): see IndexStack.push(int) - PathClipFilter: static final class PathClipFilter implements DPathConsumer2D { private DPathConsumer2D out; // Bounds of the drawing region, at pixel precision. private final double[] clipRect; private final double[] corners = new double[8]; private boolean init_corners = false; private final IndexStack stack; // the outcode of the starting point private int sOutCode = 0; // the current outcode of the current sub path private int cOutCode = 0; private boolean outside = false; private double cx0, cy0; PathClipFilter(final DRendererContext rdrCtx) { this.clipRect = rdrCtx.clipRect; this.stack = (rdrCtx.stats != null) ? new IndexStack(rdrCtx, rdrCtx.stats.stat_pcf_idxstack_indices, rdrCtx.stats.hist_pcf_idxstack_indices, rdrCtx.stats.stat_array_pcf_idxstack_indices) : new IndexStack(rdrCtx); } PathClipFilter init(final DPathConsumer2D out) { this.out = out; // Adjust the clipping rectangle with the renderer offsets final double rdrOffX = DRenderer.RDR_OFFSET_X; final double rdrOffY = DRenderer.RDR_OFFSET_Y; // add a small rounding error: final double margin = 1e-3d; final double[] _clipRect = this.clipRect; _clipRect[0] -= margin - rdrOffY; _clipRect[1] += margin + rdrOffY; _clipRect[2] -= margin - rdrOffX; _clipRect[3] += margin + rdrOffX; init_corners = true; return this; // fluent API } /** * Disposes this instance: * clean up before reusing this instance */ void dispose() { stack.dispose(); } @Override public void pathDone() { out.pathDone(); // TODO: fix possible leak if exception happened // Dispose this instance: dispose(); } @Override public void closePath() { if (outside) { this.outside = false; if (sOutCode == 0) { finish(); } else { stack.reset(); } } out.closePath(); this.cOutCode = sOutCode; } private void finish() { if (!stack.isEmpty()) { if (init_corners) { init_corners = false; // Top Left (0): corners[0] = clipRect[2]; corners[1] = clipRect[0]; // Bottom Left (1): corners[2] = clipRect[2]; corners[3] = clipRect[1]; // Top right (2): corners[4] = clipRect[3]; corners[5] = clipRect[0]; // Bottom Right (3): corners[6] = clipRect[3]; corners[7] = clipRect[1]; } stack.pullAll(corners, out); } out.lineTo(cx0, cy0); } @Override public void moveTo(final double x0, final double y0) { final int outcode = DHelpers.outcode(x0, y0, clipRect); this.sOutCode = outcode; this.cOutCode = outcode; this.outside = false; out.moveTo(x0, y0); } @Override public void lineTo(final double xe, final double ye) { final int outcode0 = this.cOutCode; final int outcode1 = DHelpers.outcode(xe, ye, clipRect); this.cOutCode = outcode1; final int sideCode = (outcode0 & outcode1); // basic rejection criteria: if (sideCode != 0) { // keep last point coordinate before entering the clip again: this.outside = true; this.cx0 = xe; this.cy0 = ye; clip(sideCode, outcode0, outcode1); return; } if (outside) { this.outside = false; finish(); } // clipping disabled: out.lineTo(xe, ye); } private void clip(final int sideCode, final int outcode0, final int outcode1) { // corner or cross-boundary on left or right side: if ((outcode0 != outcode1) && ((sideCode & DHelpers.OUTCODE_MASK_T_B) != 0)) { // combine outcodes: final int mergeCode = (outcode0 | outcode1); final int tbCode = mergeCode & DHelpers.OUTCODE_MASK_T_B; final int lrCode = mergeCode & DHelpers.OUTCODE_MASK_L_R; // add corners to outside stack: final int off = (lrCode == DHelpers.OUTCODE_LEFT) ? 0 : 2; switch (tbCode) { case DHelpers.OUTCODE_TOP: stack.push(off); // top return; case DHelpers.OUTCODE_BOTTOM: stack.push(off + 1); // bottom return; default: // both TOP / BOTTOM: if ((outcode0 & DHelpers.OUTCODE_TOP) != 0) { // top to bottom stack.push(off); // top stack.push(off + 1); // bottom } else { // bottom to top stack.push(off + 1); // bottom stack.push(off); // top } } } } @Override public void curveTo(final double x1, final double y1, final double x2, final double y2, final double xe, final double ye) { final int outcode0 = this.cOutCode; final int outcode3 = DHelpers.outcode(xe, ye, clipRect); this.cOutCode = outcode3; int sideCode = outcode0 & outcode3; if (sideCode != 0) { sideCode &= DHelpers.outcode(x1, y1, clipRect); sideCode &= DHelpers.outcode(x2, y2, clipRect); // basic rejection criteria: if (sideCode != 0) { // keep last point coordinate before entering the clip again: this.outside = true; this.cx0 = xe; this.cy0 = ye; clip(sideCode, outcode0, outcode3); return; } } if (outside) { this.outside = false; finish(); } // clipping disabled: out.curveTo(x1, y1, x2, y2, xe, ye); } @Override public void quadTo(final double x1, final double y1, final double xe, final double ye) { final int outcode0 = this.cOutCode; final int outcode2 = DHelpers.outcode(xe, ye, clipRect); this.cOutCode = outcode2; int sideCode = outcode0 & outcode2; if (outcode2 != 0) { sideCode &= DHelpers.outcode(x1, y1, clipRect); // basic rejection criteria: if (sideCode != 0) { // keep last point coordinate before entering the clip again: this.outside = true; this.cx0 = xe; this.cy0 = ye; clip(sideCode, outcode0, outcode2); return; } } if (outside) { this.outside = false; finish(); } // clipping disabled: out.quadTo(x1, y1, xe, ye); } @Override public long getNativeConsumer() { throw new InternalError("Not using a native peer"); } } - DHelpers.IndexStack: // a stack of integer indices static final class IndexStack { // integer capacity = edges count / 4 ~ 1024 private static final int INITIAL_COUNT = INITIAL_EDGES_COUNT >> 2; private int end; private int[] indices; // indices ref (dirty) private final IntArrayCache.Reference indices_ref; // used marks (stats only) private int indicesUseMark; private final StatLong stat_idxstack_indices; private final Histogram hist_idxstack_indices; private final StatLong stat_array_idxstack_indices; IndexStack(final DRendererContext rdrCtx) { this(rdrCtx, null, null, null); } IndexStack(final DRendererContext rdrCtx, final StatLong stat_idxstack_indices, final Histogram hist_idxstack_indices, final StatLong stat_array_idxstack_indices) { indices_ref = rdrCtx.newDirtyIntArrayRef(INITIAL_COUNT); // 4K indices = indices_ref.initial; end = 0; if (DO_STATS) { indicesUseMark = 0; } this.stat_idxstack_indices = stat_idxstack_indices; this.hist_idxstack_indices = hist_idxstack_indices; this.stat_array_idxstack_indices = stat_array_idxstack_indices; } /** * Disposes this PolyStack: * clean up before reusing this instance */ void dispose() { end = 0; if (DO_STATS) { stat_idxstack_indices.add(indicesUseMark); hist_idxstack_indices.add(indicesUseMark); // reset marks indicesUseMark = 0; } // Return arrays: // values is kept dirty indices = indices_ref.putArray(indices); } boolean isEmpty() { return (end == 0); } void reset() { end = 0; } void push(final int v) { // remove redundant values (reverse order): int[] _values = indices; final int nc = end; if (nc != 0) { if (_values[nc - 1] == v) { // remove both duplicated values: end--; return; } } if (_values.length <= nc) { if (DO_STATS) { stat_array_idxstack_indices.add(nc + 1); } indices = _values = indices_ref.widenArray(_values, nc, nc + 1); } _values[end++] = v; if (DO_STATS) { // update used marks: if (end > indicesUseMark) { indicesUseMark = end; } } } void pullAll(final double[] points, final DPathConsumer2D io) { final int nc = end; if (nc == 0) { return; } final int[] _values = indices; for (int i = 0, j; i < nc; i++) { j = _values[i] << 1; io.lineTo(points[j], points[j + 1]); } end = 0; } } Here is a screenshot illustrating the remaining paths in Renderer after > clipping a 4000x4000 spiral converted as stroked shape: > http://cr.openjdk.java.net/~lbourges/png/SpiralTest-dash-false.ser.png > Now all useless rounds are totally discarded from the path sent to the Renderer (removing lots of edges on the left/right sides) > clip off: ~ 145ms > clip on: ~ 106ms > clip on: ~ 68ms for this huge filled spiral ~ 50% faster Could you answer my previous email on EO questions ? How to deal with self intersections or is it possible to skip left segments in the EO case or not ? (I am a bit lost) I need a simple path to test clipping with the EO rule (redudant segments); any idea ? Cheers, Laurent From johnvalrose at gmail.com Wed Sep 6 06:53:27 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 6 Sep 2017 16:53:27 +1000 Subject: WebView and WebGL In-Reply-To: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> Message-ID: Getting back to the original issue, it's good to know that work is being done to implement WebGL support but I fear that the whole process will take longer than is really needed. As I see it, JavaFX has one major competitor which is Qt. Naturally JavaFX lags behind Qt in features and performance as they basically had a 20 year head start! But they do have a WebView with WebGL support and very advanced 3D features in general (like a 3D Canvas). For JavaFX, it looks as though the 3D features have been "unofficially deprecated" as no enhancements are planned for JFX 10 and the existing features are rudimentary at best. But... just getting WebView to support WebGL instantly gives JavaFX advanced 3D features via the multitude of WebGL libraries such as three.js etc. and the urgency for a dedicated 3D Canvas would be greatly reduced. Further, Chromium (as used by Qt) is about to support WebGL 2 so the gulf is widening at a rapid pace. Could someone please try to answer the following questions so I can get a better handle on where we are and what needs to be done: 1. Why wasn't WebGL support implemented from day zero given that WebKit supports it? 2. Is there some significant technical issue that makes WebGL implementation particularly difficult? 3. What is a brief overview of the work that needs to be done? I ask because (as I said), I am willing to work on this feature with as much spare time as I can find and am keen to get going ASAP. And it's not just a WebGL problem per se as the current WebView only supports Google Maps (one of the world's top websites) in Lite Mode which again limits the potential quite badly. I hope these issues are related and can be addressed simultaneously. Ultimately, I think it will be "fatal" if we have to wait another 4 years or so for Java 10 to get features that are already well developed in the competitor products. Graciously, John-Val Rose Rosethorn Technology > On 26 Aug 2017, at 23:46, Scott Palmer wrote: > > +1 > > ... to Any high performance way to get images from native code to the screen in a JavaFX app. I filed an enhancement request many years ago for a method to supply portions of the media pipeline for the media player APIs. > > I've also been asking for some way to get at a native surface context. Be it DirectX, OpenGL, Metal,... even just a native window handle. > > > Scott > >> On Aug 26, 2017, at 9:15 AM, Sten Nordstrom wrote: >> >> Hi Michael, all, >> >> Just want to state my support for Michael's "Direct backed WritableImage". >> Having a way to do natively-backed rendering is IMO the most important >> feature still missing from FX. This is an area where QT is still way ahead >> with it's OpenGL/OpenGL ES integration. >> >> Having something like a direct-WritableImage implementation would also make >> it easier to implement a video viewer using native decoder libs. Personally >> I find this approach much more powerful than the existing FX 3D and media >> streaming features, which are (especially 3D) limited in their >> capabilities. >> >> I will be at JavaOne this year, so if there is any interest in meeting up >> and talking JavaFX I'm in! >> >> Best regards, >> >> Sten Nordstr?m >> >>> On Fri, 25 Aug 2017 at 22.41 Michael Hoffer wrote: >>> >>> Hi Jonathan, hi all, >>> >>> I would like to bring up the "WritableImage backed by DirectBuffer" >>> discussion again: >>> From bourges.laurent at gmail.com Wed Sep 6 08:25:50 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 6 Sep 2017 10:25:50 +0200 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> Message-ID: Hi all, As Jim is no more available to review & answer my questions on java2d / computer graphics, I need another reviewer on this webrev implementing path clipping in Marlin (huge potential gains). Do you know someone else who can help me in the 2d / prism fields to improve the Marlin renderer even more ? Thanks, Laurent Le 5 sept. 2017 22:41, "Laurent Bourg?s" a ?crit : > Hi Jim, > > I made good progress on my PathClipFilter that works now perfectly with > many test maps for the NZ rule (EO has artefacts if I enable the filter in > that case). > > Here is the updated code below to illustrate the approach: > - use a new IndexStack in (D)Helpers to store only corner indexes (0/1 for > Top/Bottom Left, 2/3 for Top/Bottom Right) > - when the segment is out, I now check (L/R case) if the segment ends have > different outcodes to insert needed corners that can be removed later if a > segment does the same in the reverse order (same repeated corner is > cancelled out): see IndexStack.push(int) > > - PathClipFilter: > > static final class PathClipFilter implements DPathConsumer2D { > > private DPathConsumer2D out; > > // Bounds of the drawing region, at pixel precision. > private final double[] clipRect; > > private final double[] corners = new double[8]; > private boolean init_corners = false; > > private final IndexStack stack; > > // the outcode of the starting point > private int sOutCode = 0; > > // the current outcode of the current sub path > private int cOutCode = 0; > > private boolean outside = false; > private double cx0, cy0; > > PathClipFilter(final DRendererContext rdrCtx) { > this.clipRect = rdrCtx.clipRect; > this.stack = (rdrCtx.stats != null) ? > new IndexStack(rdrCtx, > rdrCtx.stats.stat_pcf_idxstack_indices, > rdrCtx.stats.hist_pcf_idxstack_indices, > rdrCtx.stats.stat_array_pcf_idxstack_indices) > : new IndexStack(rdrCtx); > } > > PathClipFilter init(final DPathConsumer2D out) { > this.out = out; > > // Adjust the clipping rectangle with the renderer offsets > final double rdrOffX = DRenderer.RDR_OFFSET_X; > final double rdrOffY = DRenderer.RDR_OFFSET_Y; > > // add a small rounding error: > final double margin = 1e-3d; > > final double[] _clipRect = this.clipRect; > _clipRect[0] -= margin - rdrOffY; > _clipRect[1] += margin + rdrOffY; > _clipRect[2] -= margin - rdrOffX; > _clipRect[3] += margin + rdrOffX; > > init_corners = true; > > return this; // fluent API > } > > /** > * Disposes this instance: > * clean up before reusing this instance > */ > void dispose() { > stack.dispose(); > } > > @Override > public void pathDone() { > out.pathDone(); > > // TODO: fix possible leak if exception happened > // Dispose this instance: > dispose(); > } > > @Override > public void closePath() { > if (outside) { > this.outside = false; > > if (sOutCode == 0) { > finish(); > } else { > stack.reset(); > } > } > out.closePath(); > this.cOutCode = sOutCode; > } > > private void finish() { > if (!stack.isEmpty()) { > if (init_corners) { > init_corners = false; > // Top Left (0): > corners[0] = clipRect[2]; > corners[1] = clipRect[0]; > // Bottom Left (1): > corners[2] = clipRect[2]; > corners[3] = clipRect[1]; > // Top right (2): > corners[4] = clipRect[3]; > corners[5] = clipRect[0]; > // Bottom Right (3): > corners[6] = clipRect[3]; > corners[7] = clipRect[1]; > } > stack.pullAll(corners, out); > } > out.lineTo(cx0, cy0); > } > > @Override > public void moveTo(final double x0, final double y0) { > final int outcode = DHelpers.outcode(x0, y0, clipRect); > this.sOutCode = outcode; > this.cOutCode = outcode; > this.outside = false; > out.moveTo(x0, y0); > } > > @Override > public void lineTo(final double xe, final double ye) { > final int outcode0 = this.cOutCode; > final int outcode1 = DHelpers.outcode(xe, ye, clipRect); > this.cOutCode = outcode1; > > final int sideCode = (outcode0 & outcode1); > > // basic rejection criteria: > if (sideCode != 0) { > // keep last point coordinate before entering the clip > again: > this.outside = true; > this.cx0 = xe; > this.cy0 = ye; > > clip(sideCode, outcode0, outcode1); > return; > } > if (outside) { > this.outside = false; > finish(); > } > // clipping disabled: > out.lineTo(xe, ye); > } > > private void clip(final int sideCode, > final int outcode0, > final int outcode1) > { > // corner or cross-boundary on left or right side: > if ((outcode0 != outcode1) > && ((sideCode & DHelpers.OUTCODE_MASK_T_B) != 0)) > { > // combine outcodes: > final int mergeCode = (outcode0 | outcode1); > final int tbCode = mergeCode & DHelpers.OUTCODE_MASK_T_B; > final int lrCode = mergeCode & DHelpers.OUTCODE_MASK_L_R; > // add corners to outside stack: > final int off = (lrCode == DHelpers.OUTCODE_LEFT) ? 0 : 2; > > switch (tbCode) { > case DHelpers.OUTCODE_TOP: > stack.push(off); // top > return; > case DHelpers.OUTCODE_BOTTOM: > stack.push(off + 1); // bottom > return; > default: > // both TOP / BOTTOM: > if ((outcode0 & DHelpers.OUTCODE_TOP) != 0) { > // top to bottom > stack.push(off); // top > stack.push(off + 1); // bottom > } else { > // bottom to top > stack.push(off + 1); // bottom > stack.push(off); // top > } > } > } > } > > @Override > public void curveTo(final double x1, final double y1, > final double x2, final double y2, > final double xe, final double ye) > { > final int outcode0 = this.cOutCode; > final int outcode3 = DHelpers.outcode(xe, ye, clipRect); > this.cOutCode = outcode3; > > int sideCode = outcode0 & outcode3; > > if (sideCode != 0) { > sideCode &= DHelpers.outcode(x1, y1, clipRect); > sideCode &= DHelpers.outcode(x2, y2, clipRect); > > // basic rejection criteria: > if (sideCode != 0) { > // keep last point coordinate before entering the clip > again: > this.outside = true; > this.cx0 = xe; > this.cy0 = ye; > > clip(sideCode, outcode0, outcode3); > return; > } > } > if (outside) { > this.outside = false; > finish(); > } > // clipping disabled: > out.curveTo(x1, y1, x2, y2, xe, ye); > } > > @Override > public void quadTo(final double x1, final double y1, > final double xe, final double ye) > { > final int outcode0 = this.cOutCode; > final int outcode2 = DHelpers.outcode(xe, ye, clipRect); > this.cOutCode = outcode2; > > int sideCode = outcode0 & outcode2; > > if (outcode2 != 0) { > sideCode &= DHelpers.outcode(x1, y1, clipRect); > > // basic rejection criteria: > if (sideCode != 0) { > // keep last point coordinate before entering the clip > again: > this.outside = true; > this.cx0 = xe; > this.cy0 = ye; > > clip(sideCode, outcode0, outcode2); > return; > } > } > if (outside) { > this.outside = false; > finish(); > } > // clipping disabled: > out.quadTo(x1, y1, xe, ye); > } > > @Override > public long getNativeConsumer() { > throw new InternalError("Not using a native peer"); > } > } > > - DHelpers.IndexStack: > // a stack of integer indices > static final class IndexStack { > > // integer capacity = edges count / 4 ~ 1024 > private static final int INITIAL_COUNT = INITIAL_EDGES_COUNT >> 2; > > private int end; > private int[] indices; > > // indices ref (dirty) > private final IntArrayCache.Reference indices_ref; > > // used marks (stats only) > private int indicesUseMark; > > private final StatLong stat_idxstack_indices; > private final Histogram hist_idxstack_indices; > private final StatLong stat_array_idxstack_indices; > > IndexStack(final DRendererContext rdrCtx) { > this(rdrCtx, null, null, null); > } > > IndexStack(final DRendererContext rdrCtx, > final StatLong stat_idxstack_indices, > final Histogram hist_idxstack_indices, > final StatLong stat_array_idxstack_indices) > { > indices_ref = rdrCtx.newDirtyIntArrayRef(INITIAL_COUNT); // 4K > indices = indices_ref.initial; > end = 0; > > if (DO_STATS) { > indicesUseMark = 0; > } > this.stat_idxstack_indices = stat_idxstack_indices; > this.hist_idxstack_indices = hist_idxstack_indices; > this.stat_array_idxstack_indices = > stat_array_idxstack_indices; > } > > /** > * Disposes this PolyStack: > * clean up before reusing this instance > */ > void dispose() { > end = 0; > > if (DO_STATS) { > stat_idxstack_indices.add(indicesUseMark); > hist_idxstack_indices.add(indicesUseMark); > > // reset marks > indicesUseMark = 0; > } > > // Return arrays: > // values is kept dirty > indices = indices_ref.putArray(indices); > } > > boolean isEmpty() { > return (end == 0); > } > > void reset() { > end = 0; > } > > void push(final int v) { > // remove redundant values (reverse order): > int[] _values = indices; > final int nc = end; > if (nc != 0) { > if (_values[nc - 1] == v) { > // remove both duplicated values: > end--; > return; > } > } > if (_values.length <= nc) { > if (DO_STATS) { > stat_array_idxstack_indices.add(nc + 1); > } > indices = _values = indices_ref.widenArray(_values, nc, > nc + 1); > } > _values[end++] = v; > > if (DO_STATS) { > // update used marks: > if (end > indicesUseMark) { > indicesUseMark = end; > } > } > } > > void pullAll(final double[] points, final DPathConsumer2D io) { > final int nc = end; > if (nc == 0) { > return; > } > final int[] _values = indices; > > for (int i = 0, j; i < nc; i++) { > j = _values[i] << 1; > io.lineTo(points[j], points[j + 1]); > } > end = 0; > } > } > > > Here is a screenshot illustrating the remaining paths in Renderer after >> clipping a 4000x4000 spiral converted as stroked shape: >> http://cr.openjdk.java.net/~lbourges/png/SpiralTest-dash-false.ser.png >> > > Now all useless rounds are totally discarded from the path sent to the > Renderer (removing lots of edges on the left/right sides) > > >> clip off: ~ 145ms >> clip on: ~ 106ms >> > > clip on: ~ 68ms for this huge filled spiral ~ 50% faster > > > Could you answer my previous email on EO questions ? > How to deal with self intersections or is it possible to skip left > segments in the EO case or not ? > (I am a bit lost) > > I need a simple path to test clipping with the EO rule (redudant > segments); any idea ? > > Cheers, > Laurent > From kevin.rushforth at oracle.com Wed Sep 6 14:02:58 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 06 Sep 2017 07:02:58 -0700 Subject: [10] Review request: 8187043: JavaFX fails to launch on some Windows platforms due to missing VS2017 libraries Message-ID: <59B00012.4040602@oracle.com> Please review the following fix for a critical regression introduced in 10 (and 9.x) due to the VS 2017 compiler upgrade that was done as part of the recent WebKit update: https://bugs.openjdk.java.net/browse/JDK-8187043 http://cr.openjdk.java.net/~kcr/8187043/webrev.00/ -- Kevin From kevin.rushforth at oracle.com Wed Sep 6 14:22:55 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 06 Sep 2017 07:22:55 -0700 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> Message-ID: <59B004BF.2000105@oracle.com> Hi Laurent, Some combination of Phil, Sergey, and I will take a look at this when we can. Perhaps there might be others on these two lists who could lend a helping hand? -- Kevin Laurent Bourg?s wrote: > Hi all, > > As Jim is no more available to review & answer my questions on java2d / > computer graphics, I need another reviewer on this webrev implementing path > clipping in Marlin (huge potential gains). > > Do you know someone else who can help me in the 2d / prism fields to > improve the Marlin renderer even more ? > > Thanks, > Laurent > > > Le 5 sept. 2017 22:41, "Laurent Bourg?s" a > ?crit : > > >> Hi Jim, >> >> I made good progress on my PathClipFilter that works now perfectly with >> many test maps for the NZ rule (EO has artefacts if I enable the filter in >> that case). >> >> Here is the updated code below to illustrate the approach: >> - use a new IndexStack in (D)Helpers to store only corner indexes (0/1 for >> Top/Bottom Left, 2/3 for Top/Bottom Right) >> - when the segment is out, I now check (L/R case) if the segment ends have >> different outcodes to insert needed corners that can be removed later if a >> segment does the same in the reverse order (same repeated corner is >> cancelled out): see IndexStack.push(int) >> >> - PathClipFilter: >> >> static final class PathClipFilter implements DPathConsumer2D { >> >> private DPathConsumer2D out; >> >> // Bounds of the drawing region, at pixel precision. >> private final double[] clipRect; >> >> private final double[] corners = new double[8]; >> private boolean init_corners = false; >> >> private final IndexStack stack; >> >> // the outcode of the starting point >> private int sOutCode = 0; >> >> // the current outcode of the current sub path >> private int cOutCode = 0; >> >> private boolean outside = false; >> private double cx0, cy0; >> >> PathClipFilter(final DRendererContext rdrCtx) { >> this.clipRect = rdrCtx.clipRect; >> this.stack = (rdrCtx.stats != null) ? >> new IndexStack(rdrCtx, >> rdrCtx.stats.stat_pcf_idxstack_indices, >> rdrCtx.stats.hist_pcf_idxstack_indices, >> rdrCtx.stats.stat_array_pcf_idxstack_indices) >> : new IndexStack(rdrCtx); >> } >> >> PathClipFilter init(final DPathConsumer2D out) { >> this.out = out; >> >> // Adjust the clipping rectangle with the renderer offsets >> final double rdrOffX = DRenderer.RDR_OFFSET_X; >> final double rdrOffY = DRenderer.RDR_OFFSET_Y; >> >> // add a small rounding error: >> final double margin = 1e-3d; >> >> final double[] _clipRect = this.clipRect; >> _clipRect[0] -= margin - rdrOffY; >> _clipRect[1] += margin + rdrOffY; >> _clipRect[2] -= margin - rdrOffX; >> _clipRect[3] += margin + rdrOffX; >> >> init_corners = true; >> >> return this; // fluent API >> } >> >> /** >> * Disposes this instance: >> * clean up before reusing this instance >> */ >> void dispose() { >> stack.dispose(); >> } >> >> @Override >> public void pathDone() { >> out.pathDone(); >> >> // TODO: fix possible leak if exception happened >> // Dispose this instance: >> dispose(); >> } >> >> @Override >> public void closePath() { >> if (outside) { >> this.outside = false; >> >> if (sOutCode == 0) { >> finish(); >> } else { >> stack.reset(); >> } >> } >> out.closePath(); >> this.cOutCode = sOutCode; >> } >> >> private void finish() { >> if (!stack.isEmpty()) { >> if (init_corners) { >> init_corners = false; >> // Top Left (0): >> corners[0] = clipRect[2]; >> corners[1] = clipRect[0]; >> // Bottom Left (1): >> corners[2] = clipRect[2]; >> corners[3] = clipRect[1]; >> // Top right (2): >> corners[4] = clipRect[3]; >> corners[5] = clipRect[0]; >> // Bottom Right (3): >> corners[6] = clipRect[3]; >> corners[7] = clipRect[1]; >> } >> stack.pullAll(corners, out); >> } >> out.lineTo(cx0, cy0); >> } >> >> @Override >> public void moveTo(final double x0, final double y0) { >> final int outcode = DHelpers.outcode(x0, y0, clipRect); >> this.sOutCode = outcode; >> this.cOutCode = outcode; >> this.outside = false; >> out.moveTo(x0, y0); >> } >> >> @Override >> public void lineTo(final double xe, final double ye) { >> final int outcode0 = this.cOutCode; >> final int outcode1 = DHelpers.outcode(xe, ye, clipRect); >> this.cOutCode = outcode1; >> >> final int sideCode = (outcode0 & outcode1); >> >> // basic rejection criteria: >> if (sideCode != 0) { >> // keep last point coordinate before entering the clip >> again: >> this.outside = true; >> this.cx0 = xe; >> this.cy0 = ye; >> >> clip(sideCode, outcode0, outcode1); >> return; >> } >> if (outside) { >> this.outside = false; >> finish(); >> } >> // clipping disabled: >> out.lineTo(xe, ye); >> } >> >> private void clip(final int sideCode, >> final int outcode0, >> final int outcode1) >> { >> // corner or cross-boundary on left or right side: >> if ((outcode0 != outcode1) >> && ((sideCode & DHelpers.OUTCODE_MASK_T_B) != 0)) >> { >> // combine outcodes: >> final int mergeCode = (outcode0 | outcode1); >> final int tbCode = mergeCode & DHelpers.OUTCODE_MASK_T_B; >> final int lrCode = mergeCode & DHelpers.OUTCODE_MASK_L_R; >> // add corners to outside stack: >> final int off = (lrCode == DHelpers.OUTCODE_LEFT) ? 0 : 2; >> >> switch (tbCode) { >> case DHelpers.OUTCODE_TOP: >> stack.push(off); // top >> return; >> case DHelpers.OUTCODE_BOTTOM: >> stack.push(off + 1); // bottom >> return; >> default: >> // both TOP / BOTTOM: >> if ((outcode0 & DHelpers.OUTCODE_TOP) != 0) { >> // top to bottom >> stack.push(off); // top >> stack.push(off + 1); // bottom >> } else { >> // bottom to top >> stack.push(off + 1); // bottom >> stack.push(off); // top >> } >> } >> } >> } >> >> @Override >> public void curveTo(final double x1, final double y1, >> final double x2, final double y2, >> final double xe, final double ye) >> { >> final int outcode0 = this.cOutCode; >> final int outcode3 = DHelpers.outcode(xe, ye, clipRect); >> this.cOutCode = outcode3; >> >> int sideCode = outcode0 & outcode3; >> >> if (sideCode != 0) { >> sideCode &= DHelpers.outcode(x1, y1, clipRect); >> sideCode &= DHelpers.outcode(x2, y2, clipRect); >> >> // basic rejection criteria: >> if (sideCode != 0) { >> // keep last point coordinate before entering the clip >> again: >> this.outside = true; >> this.cx0 = xe; >> this.cy0 = ye; >> >> clip(sideCode, outcode0, outcode3); >> return; >> } >> } >> if (outside) { >> this.outside = false; >> finish(); >> } >> // clipping disabled: >> out.curveTo(x1, y1, x2, y2, xe, ye); >> } >> >> @Override >> public void quadTo(final double x1, final double y1, >> final double xe, final double ye) >> { >> final int outcode0 = this.cOutCode; >> final int outcode2 = DHelpers.outcode(xe, ye, clipRect); >> this.cOutCode = outcode2; >> >> int sideCode = outcode0 & outcode2; >> >> if (outcode2 != 0) { >> sideCode &= DHelpers.outcode(x1, y1, clipRect); >> >> // basic rejection criteria: >> if (sideCode != 0) { >> // keep last point coordinate before entering the clip >> again: >> this.outside = true; >> this.cx0 = xe; >> this.cy0 = ye; >> >> clip(sideCode, outcode0, outcode2); >> return; >> } >> } >> if (outside) { >> this.outside = false; >> finish(); >> } >> // clipping disabled: >> out.quadTo(x1, y1, xe, ye); >> } >> >> @Override >> public long getNativeConsumer() { >> throw new InternalError("Not using a native peer"); >> } >> } >> >> - DHelpers.IndexStack: >> // a stack of integer indices >> static final class IndexStack { >> >> // integer capacity = edges count / 4 ~ 1024 >> private static final int INITIAL_COUNT = INITIAL_EDGES_COUNT >> 2; >> >> private int end; >> private int[] indices; >> >> // indices ref (dirty) >> private final IntArrayCache.Reference indices_ref; >> >> // used marks (stats only) >> private int indicesUseMark; >> >> private final StatLong stat_idxstack_indices; >> private final Histogram hist_idxstack_indices; >> private final StatLong stat_array_idxstack_indices; >> >> IndexStack(final DRendererContext rdrCtx) { >> this(rdrCtx, null, null, null); >> } >> >> IndexStack(final DRendererContext rdrCtx, >> final StatLong stat_idxstack_indices, >> final Histogram hist_idxstack_indices, >> final StatLong stat_array_idxstack_indices) >> { >> indices_ref = rdrCtx.newDirtyIntArrayRef(INITIAL_COUNT); // 4K >> indices = indices_ref.initial; >> end = 0; >> >> if (DO_STATS) { >> indicesUseMark = 0; >> } >> this.stat_idxstack_indices = stat_idxstack_indices; >> this.hist_idxstack_indices = hist_idxstack_indices; >> this.stat_array_idxstack_indices = >> stat_array_idxstack_indices; >> } >> >> /** >> * Disposes this PolyStack: >> * clean up before reusing this instance >> */ >> void dispose() { >> end = 0; >> >> if (DO_STATS) { >> stat_idxstack_indices.add(indicesUseMark); >> hist_idxstack_indices.add(indicesUseMark); >> >> // reset marks >> indicesUseMark = 0; >> } >> >> // Return arrays: >> // values is kept dirty >> indices = indices_ref.putArray(indices); >> } >> >> boolean isEmpty() { >> return (end == 0); >> } >> >> void reset() { >> end = 0; >> } >> >> void push(final int v) { >> // remove redundant values (reverse order): >> int[] _values = indices; >> final int nc = end; >> if (nc != 0) { >> if (_values[nc - 1] == v) { >> // remove both duplicated values: >> end--; >> return; >> } >> } >> if (_values.length <= nc) { >> if (DO_STATS) { >> stat_array_idxstack_indices.add(nc + 1); >> } >> indices = _values = indices_ref.widenArray(_values, nc, >> nc + 1); >> } >> _values[end++] = v; >> >> if (DO_STATS) { >> // update used marks: >> if (end > indicesUseMark) { >> indicesUseMark = end; >> } >> } >> } >> >> void pullAll(final double[] points, final DPathConsumer2D io) { >> final int nc = end; >> if (nc == 0) { >> return; >> } >> final int[] _values = indices; >> >> for (int i = 0, j; i < nc; i++) { >> j = _values[i] << 1; >> io.lineTo(points[j], points[j + 1]); >> } >> end = 0; >> } >> } >> >> >> Here is a screenshot illustrating the remaining paths in Renderer after >> >>> clipping a 4000x4000 spiral converted as stroked shape: >>> http://cr.openjdk.java.net/~lbourges/png/SpiralTest-dash-false.ser.png >>> >>> >> Now all useless rounds are totally discarded from the path sent to the >> Renderer (removing lots of edges on the left/right sides) >> >> >> >>> clip off: ~ 145ms >>> clip on: ~ 106ms >>> >>> >> clip on: ~ 68ms for this huge filled spiral ~ 50% faster >> >> >> Could you answer my previous email on EO questions ? >> How to deal with self intersections or is it possible to skip left >> segments in the EO case or not ? >> (I am a bit lost) >> >> I need a simple path to test clipping with the EO rule (redudant >> segments); any idea ? >> >> Cheers, >> Laurent >> >> From rajath.kamath at oracle.com Thu Sep 7 06:42:01 2017 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Wed, 6 Sep 2017 23:42:01 -0700 (PDT) Subject: [webkit][10] Review request - 8089124: HTML5: Number input allows non-numeric input Message-ID: Hi all, Please review the patch for enabling HTML5 form validation. With this enabled, WebKit would by default show validation specific error message dialogs using Shadow DOM + CSS styled web elements. This will serve as a placeholder until the FX platform implementation of ValidationMessageClient is ready. Have created a separate enhancement request for the same at https://bugs.openjdk.java.net/browse/JDK-8187075 Also note that a missing error string has been added with the following patch. The internationalization for this string would happen subsequently, tracked through https://bugs.openjdk.java.net/browse/JDK-8187300 JBS : https://bugs.openjdk.java.net/browse/JDK-8089124 WebRev : http://cr.openjdk.java.net/~ghb/rkamath/8089124/webrev.00/ Thanks, Rajath From bourges.laurent at gmail.com Thu Sep 7 06:52:18 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 7 Sep 2017 08:52:18 +0200 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <59B004BF.2000105@oracle.com> References: <342d141a-da55-520b-dae0-c87fbb990a98@oracle.com> <2a2436e3-ac17-f7e3-1088-bd60205cb6e6@oracle.com> <1a80ab24-db5a-9708-e53a-2af277c5bc76@oracle.com> <034d753b-599c-f4c0-f4fa-0a7fa47e76a7@oracle.com> <59B004BF.2000105@oracle.com> Message-ID: Hi Kevin, Ok I propose to withdraw or postpone this review after JavaOne where we will be able to discuss in a face to face meeting about Marlin & MarlinFX changes for JDK10. I hope the 2d / jfx groups have other Graphics Guru to help, as good as Jim Graham. Cheers, Laurent Le 6 sept. 2017 16:23, "Kevin Rushforth" a ?crit : > Hi Laurent, > > Some combination of Phil, Sergey, and I will take a look at this when we > can. Perhaps there might be others on these two lists who could lend a > helping hand? > > -- Kevin > > > Laurent Bourg?s wrote: > >> Hi all, >> >> As Jim is no more available to review & answer my questions on java2d / >> computer graphics, I need another reviewer on this webrev implementing >> path >> clipping in Marlin (huge potential gains). >> >> Do you know someone else who can help me in the 2d / prism fields to >> improve the Marlin renderer even more ? >> >> Thanks, >> Laurent >> >> >> Le 5 sept. 2017 22:41, "Laurent Bourg?s" a >> ?crit : >> >> >> >>> Hi Jim, >>> >>> I made good progress on my PathClipFilter that works now perfectly with >>> many test maps for the NZ rule (EO has artefacts if I enable the filter >>> in >>> that case). >>> >>> Here is the updated code below to illustrate the approach: >>> - use a new IndexStack in (D)Helpers to store only corner indexes (0/1 >>> for >>> Top/Bottom Left, 2/3 for Top/Bottom Right) >>> - when the segment is out, I now check (L/R case) if the segment ends >>> have >>> different outcodes to insert needed corners that can be removed later if >>> a >>> segment does the same in the reverse order (same repeated corner is >>> cancelled out): see IndexStack.push(int) >>> >>> - PathClipFilter: >>> >>> static final class PathClipFilter implements DPathConsumer2D { >>> >>> private DPathConsumer2D out; >>> >>> // Bounds of the drawing region, at pixel precision. >>> private final double[] clipRect; >>> >>> private final double[] corners = new double[8]; >>> private boolean init_corners = false; >>> >>> private final IndexStack stack; >>> >>> // the outcode of the starting point >>> private int sOutCode = 0; >>> >>> // the current outcode of the current sub path >>> private int cOutCode = 0; >>> >>> private boolean outside = false; >>> private double cx0, cy0; >>> >>> PathClipFilter(final DRendererContext rdrCtx) { >>> this.clipRect = rdrCtx.clipRect; >>> this.stack = (rdrCtx.stats != null) ? >>> new IndexStack(rdrCtx, >>> rdrCtx.stats.stat_pcf_idxstack_indices, >>> rdrCtx.stats.hist_pcf_idxstack_indices, >>> rdrCtx.stats.stat_array_pcf_idxstack_indices) >>> : new IndexStack(rdrCtx); >>> } >>> >>> PathClipFilter init(final DPathConsumer2D out) { >>> this.out = out; >>> >>> // Adjust the clipping rectangle with the renderer offsets >>> final double rdrOffX = DRenderer.RDR_OFFSET_X; >>> final double rdrOffY = DRenderer.RDR_OFFSET_Y; >>> >>> // add a small rounding error: >>> final double margin = 1e-3d; >>> >>> final double[] _clipRect = this.clipRect; >>> _clipRect[0] -= margin - rdrOffY; >>> _clipRect[1] += margin + rdrOffY; >>> _clipRect[2] -= margin - rdrOffX; >>> _clipRect[3] += margin + rdrOffX; >>> >>> init_corners = true; >>> >>> return this; // fluent API >>> } >>> >>> /** >>> * Disposes this instance: >>> * clean up before reusing this instance >>> */ >>> void dispose() { >>> stack.dispose(); >>> } >>> >>> @Override >>> public void pathDone() { >>> out.pathDone(); >>> >>> // TODO: fix possible leak if exception happened >>> // Dispose this instance: >>> dispose(); >>> } >>> >>> @Override >>> public void closePath() { >>> if (outside) { >>> this.outside = false; >>> >>> if (sOutCode == 0) { >>> finish(); >>> } else { >>> stack.reset(); >>> } >>> } >>> out.closePath(); >>> this.cOutCode = sOutCode; >>> } >>> >>> private void finish() { >>> if (!stack.isEmpty()) { >>> if (init_corners) { >>> init_corners = false; >>> // Top Left (0): >>> corners[0] = clipRect[2]; >>> corners[1] = clipRect[0]; >>> // Bottom Left (1): >>> corners[2] = clipRect[2]; >>> corners[3] = clipRect[1]; >>> // Top right (2): >>> corners[4] = clipRect[3]; >>> corners[5] = clipRect[0]; >>> // Bottom Right (3): >>> corners[6] = clipRect[3]; >>> corners[7] = clipRect[1]; >>> } >>> stack.pullAll(corners, out); >>> } >>> out.lineTo(cx0, cy0); >>> } >>> >>> @Override >>> public void moveTo(final double x0, final double y0) { >>> final int outcode = DHelpers.outcode(x0, y0, clipRect); >>> this.sOutCode = outcode; >>> this.cOutCode = outcode; >>> this.outside = false; >>> out.moveTo(x0, y0); >>> } >>> >>> @Override >>> public void lineTo(final double xe, final double ye) { >>> final int outcode0 = this.cOutCode; >>> final int outcode1 = DHelpers.outcode(xe, ye, clipRect); >>> this.cOutCode = outcode1; >>> >>> final int sideCode = (outcode0 & outcode1); >>> >>> // basic rejection criteria: >>> if (sideCode != 0) { >>> // keep last point coordinate before entering the clip >>> again: >>> this.outside = true; >>> this.cx0 = xe; >>> this.cy0 = ye; >>> >>> clip(sideCode, outcode0, outcode1); >>> return; >>> } >>> if (outside) { >>> this.outside = false; >>> finish(); >>> } >>> // clipping disabled: >>> out.lineTo(xe, ye); >>> } >>> >>> private void clip(final int sideCode, >>> final int outcode0, >>> final int outcode1) >>> { >>> // corner or cross-boundary on left or right side: >>> if ((outcode0 != outcode1) >>> && ((sideCode & DHelpers.OUTCODE_MASK_T_B) != 0)) >>> { >>> // combine outcodes: >>> final int mergeCode = (outcode0 | outcode1); >>> final int tbCode = mergeCode & DHelpers.OUTCODE_MASK_T_B; >>> final int lrCode = mergeCode & DHelpers.OUTCODE_MASK_L_R; >>> // add corners to outside stack: >>> final int off = (lrCode == DHelpers.OUTCODE_LEFT) ? 0 : >>> 2; >>> >>> switch (tbCode) { >>> case DHelpers.OUTCODE_TOP: >>> stack.push(off); // top >>> return; >>> case DHelpers.OUTCODE_BOTTOM: >>> stack.push(off + 1); // bottom >>> return; >>> default: >>> // both TOP / BOTTOM: >>> if ((outcode0 & DHelpers.OUTCODE_TOP) != 0) { >>> // top to bottom >>> stack.push(off); // top >>> stack.push(off + 1); // bottom >>> } else { >>> // bottom to top >>> stack.push(off + 1); // bottom >>> stack.push(off); // top >>> } >>> } >>> } >>> } >>> >>> @Override >>> public void curveTo(final double x1, final double y1, >>> final double x2, final double y2, >>> final double xe, final double ye) >>> { >>> final int outcode0 = this.cOutCode; >>> final int outcode3 = DHelpers.outcode(xe, ye, clipRect); >>> this.cOutCode = outcode3; >>> >>> int sideCode = outcode0 & outcode3; >>> >>> if (sideCode != 0) { >>> sideCode &= DHelpers.outcode(x1, y1, clipRect); >>> sideCode &= DHelpers.outcode(x2, y2, clipRect); >>> >>> // basic rejection criteria: >>> if (sideCode != 0) { >>> // keep last point coordinate before entering the >>> clip >>> again: >>> this.outside = true; >>> this.cx0 = xe; >>> this.cy0 = ye; >>> >>> clip(sideCode, outcode0, outcode3); >>> return; >>> } >>> } >>> if (outside) { >>> this.outside = false; >>> finish(); >>> } >>> // clipping disabled: >>> out.curveTo(x1, y1, x2, y2, xe, ye); >>> } >>> >>> @Override >>> public void quadTo(final double x1, final double y1, >>> final double xe, final double ye) >>> { >>> final int outcode0 = this.cOutCode; >>> final int outcode2 = DHelpers.outcode(xe, ye, clipRect); >>> this.cOutCode = outcode2; >>> >>> int sideCode = outcode0 & outcode2; >>> >>> if (outcode2 != 0) { >>> sideCode &= DHelpers.outcode(x1, y1, clipRect); >>> >>> // basic rejection criteria: >>> if (sideCode != 0) { >>> // keep last point coordinate before entering the >>> clip >>> again: >>> this.outside = true; >>> this.cx0 = xe; >>> this.cy0 = ye; >>> >>> clip(sideCode, outcode0, outcode2); >>> return; >>> } >>> } >>> if (outside) { >>> this.outside = false; >>> finish(); >>> } >>> // clipping disabled: >>> out.quadTo(x1, y1, xe, ye); >>> } >>> >>> @Override >>> public long getNativeConsumer() { >>> throw new InternalError("Not using a native peer"); >>> } >>> } >>> >>> - DHelpers.IndexStack: >>> // a stack of integer indices >>> static final class IndexStack { >>> >>> // integer capacity = edges count / 4 ~ 1024 >>> private static final int INITIAL_COUNT = INITIAL_EDGES_COUNT >> >>> 2; >>> >>> private int end; >>> private int[] indices; >>> >>> // indices ref (dirty) >>> private final IntArrayCache.Reference indices_ref; >>> >>> // used marks (stats only) >>> private int indicesUseMark; >>> >>> private final StatLong stat_idxstack_indices; >>> private final Histogram hist_idxstack_indices; >>> private final StatLong stat_array_idxstack_indices; >>> >>> IndexStack(final DRendererContext rdrCtx) { >>> this(rdrCtx, null, null, null); >>> } >>> >>> IndexStack(final DRendererContext rdrCtx, >>> final StatLong stat_idxstack_indices, >>> final Histogram hist_idxstack_indices, >>> final StatLong stat_array_idxstack_indices) >>> { >>> indices_ref = rdrCtx.newDirtyIntArrayRef(INITIAL_COUNT); // >>> 4K >>> indices = indices_ref.initial; >>> end = 0; >>> >>> if (DO_STATS) { >>> indicesUseMark = 0; >>> } >>> this.stat_idxstack_indices = stat_idxstack_indices; >>> this.hist_idxstack_indices = hist_idxstack_indices; >>> this.stat_array_idxstack_indices = >>> stat_array_idxstack_indices; >>> } >>> >>> /** >>> * Disposes this PolyStack: >>> * clean up before reusing this instance >>> */ >>> void dispose() { >>> end = 0; >>> >>> if (DO_STATS) { >>> stat_idxstack_indices.add(indicesUseMark); >>> hist_idxstack_indices.add(indicesUseMark); >>> >>> // reset marks >>> indicesUseMark = 0; >>> } >>> >>> // Return arrays: >>> // values is kept dirty >>> indices = indices_ref.putArray(indices); >>> } >>> >>> boolean isEmpty() { >>> return (end == 0); >>> } >>> >>> void reset() { >>> end = 0; >>> } >>> >>> void push(final int v) { >>> // remove redundant values (reverse order): >>> int[] _values = indices; >>> final int nc = end; >>> if (nc != 0) { >>> if (_values[nc - 1] == v) { >>> // remove both duplicated values: >>> end--; >>> return; >>> } >>> } >>> if (_values.length <= nc) { >>> if (DO_STATS) { >>> stat_array_idxstack_indices.add(nc + 1); >>> } >>> indices = _values = indices_ref.widenArray(_values, nc, >>> nc + 1); >>> } >>> _values[end++] = v; >>> >>> if (DO_STATS) { >>> // update used marks: >>> if (end > indicesUseMark) { >>> indicesUseMark = end; >>> } >>> } >>> } >>> >>> void pullAll(final double[] points, final DPathConsumer2D io) { >>> final int nc = end; >>> if (nc == 0) { >>> return; >>> } >>> final int[] _values = indices; >>> >>> for (int i = 0, j; i < nc; i++) { >>> j = _values[i] << 1; >>> io.lineTo(points[j], points[j + 1]); >>> } >>> end = 0; >>> } >>> } >>> >>> >>> Here is a screenshot illustrating the remaining paths in Renderer after >>> >>> >>>> clipping a 4000x4000 spiral converted as stroked shape: >>>> http://cr.openjdk.java.net/~lbourges/png/SpiralTest-dash-false.ser.png >>>> >>>> >>>> >>> Now all useless rounds are totally discarded from the path sent to the >>> Renderer (removing lots of edges on the left/right sides) >>> >>> >>> >>> >>>> clip off: ~ 145ms >>>> clip on: ~ 106ms >>>> >>>> >>>> >>> clip on: ~ 68ms for this huge filled spiral ~ 50% faster >>> >>> >>> Could you answer my previous email on EO questions ? >>> How to deal with self intersections or is it possible to skip left >>> segments in the EO case or not ? >>> (I am a bit lost) >>> >>> I need a simple path to test clipping with the EO rule (redudant >>> segments); any idea ? >>> >>> Cheers, >>> Laurent >>> >>> >>> >> From bourges.laurent at gmail.com Thu Sep 7 08:04:30 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Thu, 7 Sep 2017 10:04:30 +0200 Subject: Client group consolidation ? In-Reply-To: References: Message-ID: Hi, I wonder what is the current status of the Client consolidation gathering former openjdk groups 2d, awt, sound... and maybe openjfx ? I remember that Phil Race proposed such a big change but as these groups are fragmented with only few active members, I think it is worth to merge them to obtain a larger work team. Of course, it depends on the ByLaws consensus. Laurent From prasanta.sadhukhan at oracle.com Thu Sep 7 11:45:16 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 7 Sep 2017 17:15:16 +0530 Subject: [10] RFR JDK-8089774: [SwingNode] getKeyLocation not correctly implemented with JavaFX In-Reply-To: <957c7b85-1984-9ca6-e9be-f34aa14401e6@oracle.com> References: <957c7b85-1984-9ca6-e9be-f34aa14401e6@oracle.com> Message-ID: <1ec612b9-4057-c060-a32b-e9e3d0eca32f@oracle.com> Modified webrev with implementation for linux too. http://cr.openjdk.java.net/~psadhukhan/fx/8089774/webrev.01/ Regards Prasanta On 9/5/2017 10:01 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix/enhancement > cr.openjdk.java.net/~psadhukhan/fx/8089774/webrev.00/ > for a fx issue > https://bugs.openjdk.java.net/browse/JDK-8089774 > and enhancement > https://bugs.openjdk.java.net/browse/JDK-8090524 > > More info in JBS. > > Regards > Prasanta > From guru.hb at oracle.com Fri Sep 8 05:58:42 2017 From: guru.hb at oracle.com (Guru Hb) Date: Fri, 8 Sep 2017 11:28:42 +0530 Subject: [10] Review request: 8187361: Revert non reviewed commit done for the fix to JDK-8087528 Message-ID: <7C48FF11-96C7-4376-B75A-F70C2DB2EA17@oracle.com> Hi Murali & Arun, Please do the review for JBS : https://bugs.openjdk.java.net/browse/JDK-8187361 Webrev : http://cr.openjdk.java.net/~ghb/8187361/webrev.00/ Thanks, Guru From prasanta.sadhukhan at oracle.com Fri Sep 8 06:04:35 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 8 Sep 2017 11:34:35 +0530 Subject: [10] Review request: 8187361: Revert non reviewed commit done for the fix to JDK-8087528 In-Reply-To: <7C48FF11-96C7-4376-B75A-F70C2DB2EA17@oracle.com> References: <7C48FF11-96C7-4376-B75A-F70C2DB2EA17@oracle.com> Message-ID: <44fcb8f5-3c86-43c9-b941-fcb3bb477b18@oracle.com> 8087528 has been reverted ok. +1. Regards Prasanta On 9/8/2017 11:28 AM, Guru Hb wrote: > Hi Murali & Arun, > > Please do the review for > JBS : https://bugs.openjdk.java.net/browse/JDK-8187361 > Webrev : http://cr.openjdk.java.net/~ghb/8187361/webrev.00/ > > Thanks, > Guru From sverre.moe at gmail.com Fri Sep 8 09:05:56 2017 From: sverre.moe at gmail.com (Sverre Moe) Date: Fri, 8 Sep 2017 11:05:56 +0200 Subject: Support additional video codec and container format Message-ID: Why is JavaFX not supporting open video container and codec? >From Java 9 VP6 is deprecated. The only relevant supported coded for JavaFX is H.264/AVC. The only other alternative is VP6 which has been deprecated in Java 9. We cannot use H.264 without paying lisence fee for a commercial application. Support for Ogg Theroa/Vorbis should be considered, at least VP8 and/or VP9 in place for the deprecated VP6. The MediaPlayer for Java 10 has not gotten any changes either. I reckon it is too late for Java 9 to get new formats. From johnvalrose at gmail.com Fri Sep 8 10:51:06 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 8 Sep 2017 20:51:06 +1000 Subject: Support additional video codec and container format In-Reply-To: References: Message-ID: <51D7CA89-1D83-4E0F-A9F8-EF59A00B6A74@gmail.com> +1 > On 8 Sep 2017, at 19:05, Sverre Moe wrote: > > Why is JavaFX not supporting open video container and codec? > From Java 9 VP6 is deprecated. > > The only relevant supported coded for JavaFX is H.264/AVC. The only other > alternative is VP6 which has been deprecated in Java 9. > > We cannot use H.264 without paying lisence fee for a commercial application. > > Support for Ogg Theroa/Vorbis should be considered, at least VP8 and/or VP9 > in place for the deprecated VP6. The MediaPlayer for Java 10 has not gotten > any changes either. I reckon it is too late for Java 9 to get new formats. From johnvalrose at gmail.com Fri Sep 8 10:54:56 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 8 Sep 2017 20:54:56 +1000 Subject: WebView and WebGL In-Reply-To: References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> Message-ID: <785E40D7-F2A7-4A99-AB28-4020510E2CD4@gmail.com> This is a genuinely serious issue and a genuinely sincere offer of helping as much as I can. Some response would be greatly appreciated... > On 6 Sep 2017, at 16:53, John-Val Rose wrote: > > Getting back to the original issue, it's good to know that work is being done to implement WebGL support but I fear that the whole process will take longer than is really needed. > > As I see it, JavaFX has one major competitor which is Qt. Naturally JavaFX lags behind Qt in features and performance as they basically had a 20 year head start! > > But they do have a WebView with WebGL support and very advanced 3D features in general (like a 3D Canvas). For JavaFX, it looks as though the 3D features have been "unofficially deprecated" as no enhancements are planned for JFX 10 and the existing features are rudimentary at best. > > But... just getting WebView to support WebGL instantly gives JavaFX advanced 3D features via the multitude of WebGL libraries such as three.js etc. and the urgency for a dedicated 3D Canvas would be greatly reduced. > > Further, Chromium (as used by Qt) is about to support WebGL 2 so the gulf is widening at a rapid pace. > > Could someone please try to answer the following questions so I can get a better handle on where we are and what needs to be done: > > 1. Why wasn't WebGL support implemented from day zero given that WebKit supports it? > > 2. Is there some significant technical issue that makes WebGL implementation particularly difficult? > > 3. What is a brief overview of the work that needs to be done? > > I ask because (as I said), I am willing to work on this feature with as much spare time as I can find and am keen to get going ASAP. > > And it's not just a WebGL problem per se as the current WebView only supports Google Maps (one of the world's top websites) in Lite Mode which again limits the potential quite badly. > > I hope these issues are related and can be addressed simultaneously. > > Ultimately, I think it will be "fatal" if we have to wait another 4 years or so for Java 10 to get features that are already well developed in the competitor products. > > Graciously, > > John-Val Rose > Rosethorn Technology > >> On 26 Aug 2017, at 23:46, Scott Palmer wrote: >> >> +1 >> >> ... to Any high performance way to get images from native code to the screen in a JavaFX app. I filed an enhancement request many years ago for a method to supply portions of the media pipeline for the media player APIs. >> >> I've also been asking for some way to get at a native surface context. Be it DirectX, OpenGL, Metal,... even just a native window handle. >> >> >> Scott >> >>> On Aug 26, 2017, at 9:15 AM, Sten Nordstrom wrote: >>> >>> Hi Michael, all, >>> >>> Just want to state my support for Michael's "Direct backed WritableImage". >>> Having a way to do natively-backed rendering is IMO the most important >>> feature still missing from FX. This is an area where QT is still way ahead >>> with it's OpenGL/OpenGL ES integration. >>> >>> Having something like a direct-WritableImage implementation would also make >>> it easier to implement a video viewer using native decoder libs. Personally >>> I find this approach much more powerful than the existing FX 3D and media >>> streaming features, which are (especially 3D) limited in their >>> capabilities. >>> >>> I will be at JavaOne this year, so if there is any interest in meeting up >>> and talking JavaFX I'm in! >>> >>> Best regards, >>> >>> Sten Nordstr?m >>> >>>> On Fri, 25 Aug 2017 at 22.41 Michael Hoffer wrote: >>>> >>>> Hi Jonathan, hi all, >>>> >>>> I would like to bring up the "WritableImage backed by DirectBuffer" >>>> discussion again: >>>> From mp at jugs.org Fri Sep 8 11:15:23 2017 From: mp at jugs.org (Michael Paus) Date: Fri, 8 Sep 2017 13:15:23 +0200 Subject: WebView and WebGL In-Reply-To: <785E40D7-F2A7-4A99-AB28-4020510E2CD4@gmail.com> References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> <785E40D7-F2A7-4A99-AB28-4020510E2CD4@gmail.com> Message-ID: I can't give you any more feedback than to say that I'd very much appreciate such an effort. Are you aware of this project/product? https://www.teamdev.com/jxbrowser Michael Am 08.09.17 um 12:54 schrieb John-Val Rose: > This is a genuinely serious issue and a genuinely sincere offer of helping as much as I can. > > Some response would be greatly appreciated... > >> On 6 Sep 2017, at 16:53, John-Val Rose wrote: >> >> Getting back to the original issue, it's good to know that work is being done to implement WebGL support but I fear that the whole process will take longer than is really needed. >> >> As I see it, JavaFX has one major competitor which is Qt. Naturally JavaFX lags behind Qt in features and performance as they basically had a 20 year head start! >> >> But they do have a WebView with WebGL support and very advanced 3D features in general (like a 3D Canvas). For JavaFX, it looks as though the 3D features have been "unofficially deprecated" as no enhancements are planned for JFX 10 and the existing features are rudimentary at best. >> >> But... just getting WebView to support WebGL instantly gives JavaFX advanced 3D features via the multitude of WebGL libraries such as three.js etc. and the urgency for a dedicated 3D Canvas would be greatly reduced. >> >> Further, Chromium (as used by Qt) is about to support WebGL 2 so the gulf is widening at a rapid pace. >> >> Could someone please try to answer the following questions so I can get a better handle on where we are and what needs to be done: >> >> 1. Why wasn't WebGL support implemented from day zero given that WebKit supports it? >> >> 2. Is there some significant technical issue that makes WebGL implementation particularly difficult? >> >> 3. What is a brief overview of the work that needs to be done? >> >> I ask because (as I said), I am willing to work on this feature with as much spare time as I can find and am keen to get going ASAP. >> >> And it's not just a WebGL problem per se as the current WebView only supports Google Maps (one of the world's top websites) in Lite Mode which again limits the potential quite badly. >> >> I hope these issues are related and can be addressed simultaneously. >> >> Ultimately, I think it will be "fatal" if we have to wait another 4 years or so for Java 10 to get features that are already well developed in the competitor products. >> >> Graciously, >> >> John-Val Rose >> Rosethorn Technology >> >>> On 26 Aug 2017, at 23:46, Scott Palmer wrote: >>> >>> +1 >>> >>> ... to Any high performance way to get images from native code to the screen in a JavaFX app. I filed an enhancement request many years ago for a method to supply portions of the media pipeline for the media player APIs. >>> >>> I've also been asking for some way to get at a native surface context. Be it DirectX, OpenGL, Metal,... even just a native window handle. >>> >>> >>> Scott >>> >>>> On Aug 26, 2017, at 9:15 AM, Sten Nordstrom wrote: >>>> >>>> Hi Michael, all, >>>> >>>> Just want to state my support for Michael's "Direct backed WritableImage". >>>> Having a way to do natively-backed rendering is IMO the most important >>>> feature still missing from FX. This is an area where QT is still way ahead >>>> with it's OpenGL/OpenGL ES integration. >>>> >>>> Having something like a direct-WritableImage implementation would also make >>>> it easier to implement a video viewer using native decoder libs. Personally >>>> I find this approach much more powerful than the existing FX 3D and media >>>> streaming features, which are (especially 3D) limited in their >>>> capabilities. >>>> >>>> I will be at JavaOne this year, so if there is any interest in meeting up >>>> and talking JavaFX I'm in! >>>> >>>> Best regards, >>>> >>>> Sten Nordstr?m >>>> >>>>> On Fri, 25 Aug 2017 at 22.41 Michael Hoffer wrote: >>>>> >>>>> Hi Jonathan, hi all, >>>>> >>>>> I would like to bring up the "WritableImage backed by DirectBuffer" >>>>> discussion again: >>>>> From johnvalrose at gmail.com Fri Sep 8 11:46:45 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Fri, 8 Sep 2017 21:46:45 +1000 Subject: WebView and WebGL In-Reply-To: References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> <785E40D7-F2A7-4A99-AB28-4020510E2CD4@gmail.com> Message-ID: <454CEE89-45B1-4AA2-91AA-35E7A7970C5B@gmail.com> Thanks Michael - yes I have, and, extensively evaluated it. It's major problem is that it is a *heavyweight* component using native Chromium rendering. It's fast, supports WebGL but doesn't play nicely with the lightweight JavaFX controls. Anything rendered on top of it for example will not be visible. It's not a valid swap-in for lightweight WebView. They offer a lightweight "mode" for JxBrowser but all it does is render into an offscreen buffer and then use that as an image in JavaFX. It's very slow, maxes-out CPU utilisation and they had to implement an event handler delegate (which is feature deficient), and... it doesn't support WebGL in this mode!!! We need to add WebGL support to a lightweight Web View (be it based on WebKit or Chromium) > On 8 Sep 2017, at 21:15, Michael Paus wrote: > > I can't give you any more feedback than to say that I'd very much appreciate such an effort. > Are you aware of this project/product? https://www.teamdev.com/jxbrowser > Michael > >> Am 08.09.17 um 12:54 schrieb John-Val Rose: >> This is a genuinely serious issue and a genuinely sincere offer of helping as much as I can. >> >> Some response would be greatly appreciated... >> >>> On 6 Sep 2017, at 16:53, John-Val Rose wrote: >>> >>> Getting back to the original issue, it's good to know that work is being done to implement WebGL support but I fear that the whole process will take longer than is really needed. >>> >>> As I see it, JavaFX has one major competitor which is Qt. Naturally JavaFX lags behind Qt in features and performance as they basically had a 20 year head start! >>> >>> But they do have a WebView with WebGL support and very advanced 3D features in general (like a 3D Canvas). For JavaFX, it looks as though the 3D features have been "unofficially deprecated" as no enhancements are planned for JFX 10 and the existing features are rudimentary at best. >>> >>> But... just getting WebView to support WebGL instantly gives JavaFX advanced 3D features via the multitude of WebGL libraries such as three.js etc. and the urgency for a dedicated 3D Canvas would be greatly reduced. >>> >>> Further, Chromium (as used by Qt) is about to support WebGL 2 so the gulf is widening at a rapid pace. >>> >>> Could someone please try to answer the following questions so I can get a better handle on where we are and what needs to be done: >>> >>> 1. Why wasn't WebGL support implemented from day zero given that WebKit supports it? >>> >>> 2. Is there some significant technical issue that makes WebGL implementation particularly difficult? >>> >>> 3. What is a brief overview of the work that needs to be done? >>> >>> I ask because (as I said), I am willing to work on this feature with as much spare time as I can find and am keen to get going ASAP. >>> >>> And it's not just a WebGL problem per se as the current WebView only supports Google Maps (one of the world's top websites) in Lite Mode which again limits the potential quite badly. >>> >>> I hope these issues are related and can be addressed simultaneously. >>> >>> Ultimately, I think it will be "fatal" if we have to wait another 4 years or so for Java 10 to get features that are already well developed in the competitor products. >>> >>> Graciously, >>> >>> John-Val Rose >>> Rosethorn Technology >>> >>>> On 26 Aug 2017, at 23:46, Scott Palmer wrote: >>>> >>>> +1 >>>> >>>> ... to Any high performance way to get images from native code to the screen in a JavaFX app. I filed an enhancement request many years ago for a method to supply portions of the media pipeline for the media player APIs. >>>> >>>> I've also been asking for some way to get at a native surface context. Be it DirectX, OpenGL, Metal,... even just a native window handle. >>>> >>>> >>>> Scott >>>> >>>>> On Aug 26, 2017, at 9:15 AM, Sten Nordstrom wrote: >>>>> >>>>> Hi Michael, all, >>>>> >>>>> Just want to state my support for Michael's "Direct backed WritableImage". >>>>> Having a way to do natively-backed rendering is IMO the most important >>>>> feature still missing from FX. This is an area where QT is still way ahead >>>>> with it's OpenGL/OpenGL ES integration. >>>>> >>>>> Having something like a direct-WritableImage implementation would also make >>>>> it easier to implement a video viewer using native decoder libs. Personally >>>>> I find this approach much more powerful than the existing FX 3D and media >>>>> streaming features, which are (especially 3D) limited in their >>>>> capabilities. >>>>> >>>>> I will be at JavaOne this year, so if there is any interest in meeting up >>>>> and talking JavaFX I'm in! >>>>> >>>>> Best regards, >>>>> >>>>> Sten Nordstr?m >>>>> >>>>>> On Fri, 25 Aug 2017 at 22.41 Michael Hoffer wrote: >>>>>> >>>>>> Hi Jonathan, hi all, >>>>>> >>>>>> I would like to bring up the "WritableImage backed by DirectBuffer" >>>>>> discussion again: >>>>>> > From fbrunnerlist at gmx.ch Fri Sep 8 19:24:02 2017 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Fri, 08 Sep 2017 21:24:02 +0200 Subject: Style a Popup in a Skin Message-ID: <1846222.lRJ5sKo1Rr@andor> Hi, Sorry to bother this list with this question, but I didn' receive any answer on Stackoverflow and I'm not sure if or how this is supported at all: https://stackoverflow.com/questions/45467626/custom-skin-style-popup https://stackoverflow.com/questions/14610639/custom-control-opaque-popup In a Skin implementation of a custom control I want to style a Popup. I guess I have to use the PopupControl[1], not Popup[2]. PopupControl popup = new PopupControl(); popup.getScene().setRoot(popupContentPane); popup.setAutoHide(true); popup.setAnchorLocation(PopupWindow.AnchorLocation.WINDOW_BOTTOM_LEFT); popup.setStyle("-fx-background-color: red;"); popup.getStyleClass().add("my-popup"); popup.show(getSkinnable(), screenLocation.getX(), screenLocation.getY()); The skinnable overrides the userAgentStylesheet: @Override public String getUserAgentStylesheet() { return Stylesheets.getDefaultStylesheet(); } But neither the style, nor the styleClass nor any styleClass applied to any child node of popupContentPane has some effect. If I understand the documentation[3] correctly the popup should use the stylesheet of the ownerNode (here the skinnable). How can I style a popup in a skin? Or should I file an enhancement request? Kind regards,Florian -------- [1] http://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/PopupControl.html [2] http://docs.oracle.com/javase/8/javafx/api/javafx/stage/Popup.html [3] http://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/PopupControl.html#getStyleableParent-- From mike at plan99.net Sat Sep 9 15:06:23 2017 From: mike at plan99.net (Mike Hearn) Date: Sat, 9 Sep 2017 17:06:23 +0200 Subject: WebView and WebGL In-Reply-To: References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> Message-ID: I'm not on the FX team, but I'd suggest just starting work on it and see how far you get. You might duplicate some of the research the FX engineers are doing but you also might not, or you might find yourself being able to influence the direction of the project with unique input. If you can make WebGL work in WebKit, I guess it's not much harder to expose an eGL binding via JavaFX itself as WebGL is basically eGL for the web. I'd like to see GL support in JavaFX, if only because I enjoy blinging apps I write, including business apps! The embedded video player is invaluable for this sort of thing too. 1. Why wasn't WebGL support implemented from day zero given that WebKit > supports it? > I am going to take a stab at these answers based on my relatively poor understanding of how JavaFX works. Answers worth what you paid for them. I'm going to guess that the answer is Windows. WebKit drawing is routed via the FX rendering layer, which is in turn an abstraction over OpenGL and Direct3D on Windows. Mapping OpenGL to Direct3D is a tricky problem that requires a sophisticated rendering layer. In order to make WebGL happen, Google had to do a deal with a company called TransGaming that had developed a translation layer between OpenGL and Direct3D. That layer is called ANGLE and Google open sourced it once they had acquired the rights. https://chromium.googlesource.com/angle/angle/+/master/README.md To support OpenGL in Java, you have two choices: 1) Directly expose the operating system underlying OpenGL driver. 2) Emulate GL on top of whatever the OS provides. Whenever you see OpenGL being used in Java today, the path taken is (1). The reason browsers use the rather odd and indirect path of number (2) is that on Windows OpenGL is not the native drawing layer, unlike MacOS and Linux, games do not typically use OpenGL and as such the GL drivers are often low quality, low performance and buggy. The GL driver situation is so poor that it is basically never a good idea to use anything other than DirectX on Windows. I suspect this is why JavaFX uses a dedicated Direct3D backend on Windows: http://grepcode.com/file/repo1.maven.org/maven2/net.java.openjfx.backport/openjfx-78-backport/1.8.0-ea-b96.1/com/sun/prism/d3d/D3DPipeline.java > 2. Is there some significant technical issue that makes WebGL > implementation particularly difficult? > Yes. See above. > 3. What is a brief overview of the work that needs to be done? > To expose WebGL, you have to do what Chrome does and map GL to Direct3D using ANGLE. That's probably a fairly major engineering effort and requires the complete import of a new open source subsystem into FX. Note that if you do this, it'd be silly to restrict it to WebGL in WebView! You might as well expose a new JavaFX control that implements eGL at the same time, as a first step towards competing the work. That in turn would reduce the demand for WebGL because once you can do low level 3D graphics from Java directly, you don't need to go through WebKit. It'd only be needed for sites like Maps. Ultimately, I think it will be "fatal" if we have to wait another 4 years > or so for Java 10 to get features that are already well developed in the > competitor products. > See the recent announcement by the lead Java architect that they want to speed up Java releases. They definitely don't want a 4 year wait for Java 10: https://mreinhold.org/blog/forward-faster I'd suggest getting started by exploring ANGLE and reading their documentation and presentation materials. The path to WebGL or any form of GL in JavaFX lies through ANGLE. From stnordstrom at gmail.com Sat Sep 9 16:51:42 2017 From: stnordstrom at gmail.com (Sten Nordstrom) Date: Sat, 09 Sep 2017 16:51:42 +0000 Subject: WebView and WebGL In-Reply-To: References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> Message-ID: Having done some GL work on windows I've to agree with Mike. Windows GL drivers can be a disaster. If you are able to specify hardware for your users it's fine but if you take a random win-machine you are most likely in trouble. So something like angle would probably be the safest way to get EGL to work, especially as FX seems to use Direct3D on windows anyway. And yes, doing it as Mike proposes one would get an EGL node on the way to webgl. -- Sten From johnvalrose at gmail.com Sat Sep 9 20:10:05 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sun, 10 Sep 2017 06:10:05 +1000 Subject: WebView and WebGL In-Reply-To: References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> Message-ID: Thanks guys - that sounds like a good "angle" to approach this :-; I too suspected that Windows and poor OpenGL support was at the heart of the matter after the decades-long "API Wars". I just didn't realise that OpenGL on Windows was that inferior/buggy to Direct3D (by design, of course!). I will start investigating and I definitely agree that it's not really just about WebView, although that's a good first candidate. I guess I'm just a bit disappointed that it has only been community members who have replied on this important issue. Surely my mission will be easier if Oracle guide and assist me... Graciously, John-Val Rose > On 10 Sep 2017, at 01:06, Mike Hearn wrote: > > I'm not on the FX team, but I'd suggest just starting work on it and see > how far you get. You might duplicate some of the research the FX engineers > are doing but you also might not, or you might find yourself being able to > influence the direction of the project with unique input. > > If you can make WebGL work in WebKit, I guess it's not much harder to > expose an eGL binding via JavaFX itself as WebGL is basically eGL for the > web. > > I'd like to see GL support in JavaFX, if only because I enjoy blinging apps > I write, including business apps! The embedded video player is invaluable > for this sort of thing too. > > 1. Why wasn't WebGL support implemented from day zero given that WebKit >> supports it? >> > > I am going to take a stab at these answers based on my relatively poor > understanding of how JavaFX works. Answers worth what you paid for them. > > I'm going to guess that the answer is Windows. > > WebKit drawing is routed via the FX rendering layer, which is in turn an > abstraction over OpenGL and Direct3D on Windows. Mapping OpenGL to Direct3D > is a tricky problem that requires a sophisticated rendering layer. In order > to make WebGL happen, Google had to do a deal with a company called > TransGaming that had developed a translation layer between OpenGL and > Direct3D. That layer is called ANGLE and Google open sourced it once they > had acquired the rights. > > https://chromium.googlesource.com/angle/angle/+/master/README.md > > To support OpenGL in Java, you have two choices: > > 1) Directly expose the operating system underlying OpenGL driver. > > 2) Emulate GL on top of whatever the OS provides. > > Whenever you see OpenGL being used in Java today, the path taken is (1). > The reason browsers use the rather odd and indirect path of number (2) is > that on Windows OpenGL is not the native drawing layer, unlike MacOS and > Linux, games do not typically use OpenGL and as such the GL drivers are > often low quality, low performance and buggy. The GL driver situation is so > poor that it is basically never a good idea to use anything other than > DirectX on Windows. I suspect this is why JavaFX uses a dedicated Direct3D > backend on Windows: > > http://grepcode.com/file/repo1.maven.org/maven2/net.java.openjfx.backport/openjfx-78-backport/1.8.0-ea-b96.1/com/sun/prism/d3d/D3DPipeline.java > > >> 2. Is there some significant technical issue that makes WebGL >> implementation particularly difficult? >> > > Yes. See above. > > >> 3. What is a brief overview of the work that needs to be done? >> > > To expose WebGL, you have to do what Chrome does and map GL to Direct3D > using ANGLE. That's probably a fairly major engineering effort and requires > the complete import of a new open source subsystem into FX. > > Note that if you do this, it'd be silly to restrict it to WebGL in WebView! > You might as well expose a new JavaFX control that implements eGL at the > same time, as a first step towards competing the work. That in turn would > reduce the demand for WebGL because once you can do low level 3D graphics > from Java directly, you don't need to go through WebKit. It'd only be > needed for sites like Maps. > > Ultimately, I think it will be "fatal" if we have to wait another 4 years >> or so for Java 10 to get features that are already well developed in the >> competitor products. >> > > See the recent announcement by the lead Java architect that they want to > speed up Java releases. They definitely don't want a 4 year wait for Java > 10: > > https://mreinhold.org/blog/forward-faster > > I'd suggest getting started by exploring ANGLE and reading their > documentation and presentation materials. The path to WebGL or any form of > GL in JavaFX lies through ANGLE. > On 10 Sep 2017, at 02:51, Sten Nordstrom wrote: > > Having done some GL work on windows I've to agree with Mike. Windows GL > drivers can be a disaster. If you are able to specify hardware for your > users it's fine but if you take a random win-machine you are most likely in > trouble. So something like angle would probably be the safest way to get > EGL to work, especially as FX seems to use Direct3D on windows anyway. > > And yes, doing it as Mike proposes one would get an EGL node on the way to > webgl. > > -- Sten From philip.race at oracle.com Sat Sep 9 21:55:17 2017 From: philip.race at oracle.com (Philip Race) Date: Sat, 09 Sep 2017 14:55:17 -0700 Subject: WebView and WebGL In-Reply-To: References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> Message-ID: <59B46345.3050003@oracle.com> FWIW Java 2D ships OGL support on Windows (turned on by a flag) and our SQE have occasionally dutifully run tests in that mode and regularly turn up bugs that look like driver bugs. As a consequence FX decided to not ship it. So although FX builds OGL support on all platforms it is excluded from the windows product distribution. -phil. On 9/9/17, 9:51 AM, Sten Nordstrom wrote: > Having done some GL work on windows I've to agree with Mike. Windows GL > drivers can be a disaster. If you are able to specify hardware for your > users it's fine but if you take a random win-machine you are most likely in > trouble. So something like angle would probably be the safest way to get > EGL to work, especially as FX seems to use Direct3D on windows anyway. > > And yes, doing it as Mike proposes one would get an EGL node on the way to > webgl. > > -- Sten From swpalmer at gmail.com Sat Sep 9 22:16:17 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Sat, 9 Sep 2017 18:16:17 -0400 Subject: WebView and WebGL In-Reply-To: References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> Message-ID: <12A269FF-0CAD-40B3-9C54-AE0BBB572044@gmail.com> If I?m remembering correctly, I think the another factor for why WebGL wasn?t included is that the rendering layer of WebKit was done on top of JavaFX. That allows it to integrate nicely with the all the other JavaFX rendering. Personally I wish that time wasn?t wasted (IMO) on the existing 3D support and instead proper OpenGL support was done for JavaFX - *outside* of WebKit. I think that might have required solving another problem - integrating a native rendering surface into the scene graph. That would have allowed me to solve other problems, such as showing realtime video from a camera or other image sources, that the existing media API doesn?t support. My issue requesting extensible media support is coming up on its 9-year anniversary: https://bugs.openjdk.java.net/browse/JDK-8091063 (It?s closed now as it is marked as a duplicate of issues that were created later, even though those issues don?t adequately cover what is required.) Frankly I have very little use for WebKit in a JavaFX application (other than for displaying help pages or something). If I?m going to make a web app, I will just make a web app. JavaFX would only serve to make a web app less accessible. I would of course never make a web app where a proper desktop app is more appropriate, because they always suck compared to apps that aren?t crippled by running in a browser. :-) Scott > On Sep 9, 2017, at 11:06 AM, Mike Hearn wrote: > > I'm not on the FX team, but I'd suggest just starting work on it and see how far you get. You might duplicate some of the research the FX engineers are doing but you also might not, or you might find yourself being able to influence the direction of the project with unique input. > > If you can make WebGL work in WebKit, I guess it's not much harder to expose an eGL binding via JavaFX itself as WebGL is basically eGL for the web. > > I'd like to see GL support in JavaFX, if only because I enjoy blinging apps I write, including business apps! The embedded video player is invaluable for this sort of thing too. > > 1. Why wasn't WebGL support implemented from day zero given that WebKit supports it? > > I am going to take a stab at these answers based on my relatively poor understanding of how JavaFX works. Answers worth what you paid for them. > > I'm going to guess that the answer is Windows. From johnvalrose at gmail.com Sat Sep 9 22:45:43 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sun, 10 Sep 2017 08:45:43 +1000 Subject: WebView and WebGL In-Reply-To: <12A269FF-0CAD-40B3-9C54-AE0BBB572044@gmail.com> References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> <12A269FF-0CAD-40B3-9C54-AE0BBB572044@gmail.com> Message-ID: <9F73E1A8-B98B-42FC-B08B-05BABF6648CE@gmail.com> Yes Scott, the rendering in WebView is done with the JavaFX API which has pros and cons. The major "pro" is that it is a lightweight control that plays nicely with all other controls (and the performance is surprisingly good). The "con" is that implementing WebGL was thus very complicated (with the issues about OpenGL on Windows already mentioned) and therefore omitted. As I mentioned in another post, the product "JxBrowser" which is based on Chromium is a heavyweight control where all the rendering is done by Chromium itself. This makes it perform just as well as Chrome and supports WebGL and full-mode Google Maps. It looks like a great choice until you want to use other (lightweight) controls with it. The native rendering will just override anything you do over the top of JxBrowser and that age-old problem of trying to mix heavyweight and lightweight controls is highlighted. But, if you just want a real HTML5 browser control in your JavaFX app surrounded by normal controls, it works great (if you can afford it!). But it isn't portable to iOS or Android either with tools like Gluon Mobile. It is NOT the correct, long-term solution to enabling proper, advanced OpenGL support in JavaFX, either in a 3D Canvas or in WebView. Determining the best solution & making it work is now my mission :-) (And yes, the current JavaFX 3D features are extremely rudimentary and not particularly useful. I don't expect them to be ever enhanced. They're effectively "frozen". It's a harsh call but I think they were a mistake from day one. We need a completely different alternative). Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology > On 10 Sep 2017, at 08:16, Scott Palmer wrote: > > If I?m remembering correctly, I think the another factor for why WebGL wasn?t included is that the rendering layer of WebKit was done on top of JavaFX. That allows it to integrate nicely with the all the other JavaFX rendering. > > Personally I wish that time wasn?t wasted (IMO) on the existing 3D support and instead proper OpenGL support was done for JavaFX - *outside* of WebKit. I think that might have required solving another problem - integrating a native rendering surface into the scene graph. That would have allowed me to solve other problems, such as showing realtime video from a camera or other image sources, that the existing media API doesn?t support. > > My issue requesting extensible media support is coming up on its 9-year anniversary: > https://bugs.openjdk.java.net/browse/JDK-8091063 > (It?s closed now as it is marked as a duplicate of issues that were created later, even though those issues don?t adequately cover what is required.) > > > Frankly I have very little use for WebKit in a JavaFX application (other than for displaying help pages or something). If I?m going to make a web app, I will just make a web app. JavaFX would only serve to make a web app less accessible. I would of course never make a web app where a proper desktop app is more appropriate, because they always suck compared to apps that aren?t crippled by running in a browser. :-) > > > Scott > > >> On Sep 9, 2017, at 11:06 AM, Mike Hearn wrote: >> >> I'm not on the FX team, but I'd suggest just starting work on it and see how far you get. You might duplicate some of the research the FX engineers are doing but you also might not, or you might find yourself being able to influence the direction of the project with unique input. >> >> If you can make WebGL work in WebKit, I guess it's not much harder to expose an eGL binding via JavaFX itself as WebGL is basically eGL for the web. >> >> I'd like to see GL support in JavaFX, if only because I enjoy blinging apps I write, including business apps! The embedded video player is invaluable for this sort of thing too. >> >> 1. Why wasn't WebGL support implemented from day zero given that WebKit supports it? >> >> I am going to take a stab at these answers based on my relatively poor understanding of how JavaFX works. Answers worth what you paid for them. >> >> I'm going to guess that the answer is Windows. > > From mike at plan99.net Sun Sep 10 11:04:25 2017 From: mike at plan99.net (Mike Hearn) Date: Sun, 10 Sep 2017 13:04:25 +0200 Subject: WebView and WebGL In-Reply-To: <9F73E1A8-B98B-42FC-B08B-05BABF6648CE@gmail.com> References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> <12A269FF-0CAD-40B3-9C54-AE0BBB572044@gmail.com> <9F73E1A8-B98B-42FC-B08B-05BABF6648CE@gmail.com> Message-ID: > > (And yes, the current JavaFX 3D features are extremely rudimentary and not > particularly useful. I don't expect them to be ever enhanced. They're > effectively "frozen". It's a harsh call but I think they were a mistake > from day one. We need a completely different alternative). > I somewhat agree, but at the time - lacking something like ANGLE - there was no alternative. And it's sufficient to be able to put a UI surface onto a cube and spin it around, and other simple but effective animation techniques. As macOS has showed you don't need a full blown 3D engine to make good use of a GPU: just tasteful use of basic shapes, animations and shader effects gets you a long way, and FX does support those. From johnvalrose at gmail.com Sun Sep 10 11:15:27 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sun, 10 Sep 2017 21:15:27 +1000 Subject: WebView and WebGL In-Reply-To: References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> <12A269FF-0CAD-40B3-9C54-AE0BBB572044@gmail.com> <9F73E1A8-B98B-42FC-B08B-05BABF6648CE@gmail.com> Message-ID: <02333516-7D82-4D15-9BF6-E5790489E300@gmail.com> ...if only you could "bring your own" shader :-; On 10 Sep 2017, at 21:04, Mike Hearn wrote: >> >> (And yes, the current JavaFX 3D features are extremely rudimentary and not >> particularly useful. I don't expect them to be ever enhanced. They're >> effectively "frozen". It's a harsh call but I think they were a mistake >> from day one. We need a completely different alternative). >> > > I somewhat agree, but at the time - lacking something like ANGLE - there > was no alternative. And it's sufficient to be able to put a UI surface onto > a cube and spin it around, and other simple but effective animation > techniques. As macOS has showed you don't need a full blown 3D engine to > make good use of a GPU: just tasteful use of basic shapes, animations and > shader effects gets you a long way, and FX does support those. From nlisker at gmail.com Sun Sep 10 13:13:53 2017 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 10 Sep 2017 16:13:53 +0300 Subject: WebView and WebGL Message-ID: I don't want to hijack the WebGL discussion but since it rolled into the 3D library territory anyway I'll give my 2 cents. 3D enhancement are indeed not planned for Java10 (at the minimum) and indeed you can't bring your own shader (asked already at https://stackoverflow.com/questions/43622856/can-we-implement-our-own-materials-in-javafx), but I agree with Mike - you can, maybe somewhat surprisingly, do quite a lot with what there is. Perhaps the most limiting feature is not supporting industry standards of 3D modeling via converters (import/export). It has been suggested ( https://bugs.openjdk.java.net/browse/JDK-8091851) but last activity was 5 years ago. As for shaders (materials), lightings etc., from what I remember by looking around in the source, it will take some effort to rewrite the API to be able to accept custom ones but it's far from impossible. If Phong is implemented there's little reason reason others won't fit (maybe reflective surfaces don't work). Similarly a directional light can be based on the implemented point light be using a cone instead of a sphere. We've employed some clever tricks to get adequate "advanced features" results and considering that all of it can be single-handedly run on iOS and Android with Gluon Mobile (specifically JavaFXPorts) I think there *is* a future in this direction and I'm willing to team up with whomever is interested provided we can get minimal support from the Oracle team. From sverre.moe at gmail.com Sun Sep 10 18:49:56 2017 From: sverre.moe at gmail.com (Sverre Moe) Date: Sun, 10 Sep 2017 20:49:56 +0200 Subject: Support additional video codec and container format Message-ID: Some very old issues for this kind of change https://bugs.openjdk.java.net/browse/JDK-8091063 https://bugs.openjdk.java.net/browse/JDK-8091656 One new comment on the latter issue suggesting to add new formats like "Ogg/{Vorbis,Theora}, flac, matroska (MKV), Opus, VP8, 3GPP, GSM" This would be great to have on JavaFX. I seriously hope they would add it for Java 10 at least, or a later Java 9 update. > Date: Fri, 8 Sep 2017 20:51:06 +1000 > From: John-Val Rose > To: Sverre Moe > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Support additional video codec and container format > Message-ID: <51D7CA89-1D83-4E0F-A9F8-EF59A00B6A74 at gmail.com> > Content-Type: text/plain; charset=us-ascii > > +1 > > > On 8 Sep 2017, at 19:05, Sverre Moe wrote: > > > > Why is JavaFX not supporting open video container and codec? > > From Java 9 VP6 is deprecated. > > > > The only relevant supported coded for JavaFX is H.264/AVC. The only other > > alternative is VP6 which has been deprecated in Java 9. > > > > We cannot use H.264 without paying lisence fee for a commercial > application. > > > > Support for Ogg Theroa/Vorbis should be considered, at least VP8 and/or > VP9 > > in place for the deprecated VP6. The MediaPlayer for Java 10 has not > gotten > > any changes either. I reckon it is too late for Java 9 to get new > formats. > From johnvalrose at gmail.com Sun Sep 10 20:29:22 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Mon, 11 Sep 2017 06:29:22 +1000 Subject: Innovation (Was: WebView and WebGL) In-Reply-To: References: Message-ID: Nir, You're not "hijacking" anything - I think it's been established that this a broader "3D API support" issue. In fact, even broader than that. I'm only new on the JavaFX "scene" but I've looked through the history and tried to analyse the present and anticipate the future. It seems that there are 2 main groups of JavaFX users: one that takes it as it is and makes the most of it, sometimes in stunning and amazing ways but they don't seem to like to rock the boat or try to force the improvement of JavaFX itself so much. Then there's the others who get frustrated, ask for change, offer to enable change or put on their boots and make change. A lot of them seem to get "burned". We need people from both camps: one to showcase what can be done with what we have in surprising ways and the others to drive innovation. I'm clearly in the 2nd group and I'm finding that there are quite a few of us. I'm not so afraid of "getting burned" as we all take risks in life and if you are passionate about something, you just go with it. But, the most disappointing aspect is that Oracle staff are often "M.I.A." when discussing innovation and the future feature plans. As in this thread, Oracle haven't exactly been chiming-in (and yes, I know a lot of it has occurred outside of normal working hours). So Nir, Laurent (and the many others who are putting their hands up), perhaps we should collaborate and not just "casually". OpenJFX is, after all, "open" so perhaps a more formally coordinated team of motivated community members can pool our resources and skills and "Just do it" (with or without Oracle's help). I like what you are suggesting and what Sverre is requesting and what numerous others are wanting, and I for one *want* them to become realities. Quite frankly, I don't see these changes and innovations (especially) actually being realised any other way. Comments? Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology > On 10 Sep 2017, at 23:13, Nir Lisker wrote: > > I don't want to hijack the WebGL discussion but since it rolled into the 3D > library territory anyway I'll give my 2 cents. > > 3D enhancement are indeed not planned for Java10 (at the minimum) and > indeed you can't bring your own shader (asked already at > https://stackoverflow.com/questions/43622856/can-we-implement-our-own-materials-in-javafx), > but I agree with Mike - you can, maybe somewhat surprisingly, do quite a > lot with what there is. > > Perhaps the most limiting feature is not supporting industry standards of > 3D modeling via converters (import/export). It has been suggested ( > https://bugs.openjdk.java.net/browse/JDK-8091851) but last activity was 5 > years ago. As for shaders (materials), lightings etc., from what I remember > by looking around in the source, it will take some effort to rewrite the > API to be able to accept custom ones but it's far from impossible. If Phong > is implemented there's little reason reason others won't fit (maybe > reflective surfaces don't work). Similarly a directional light can be based > on the implemented point light be using a cone instead of a sphere. > > We've employed some clever tricks to get adequate "advanced features" > results and considering that all of it can be single-handedly run on iOS > and Android with Gluon Mobile (specifically JavaFXPorts) I think there *is* > a future in this direction and I'm willing to team up with whomever is > interested provided we can get minimal support from the Oracle team. From nlisker at gmail.com Mon Sep 11 00:25:39 2017 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 11 Sep 2017 03:25:39 +0300 Subject: Innovation (Was: WebView and WebGL) In-Reply-To: References: Message-ID: I don't mind giving it a go but I wouldn't like doing the work and then it not getting implemented (if the result is a success). Personally, I think that the first thing we should do is make a list of what exactly it is we are trying to do if only to get a sense of the magnitude and be sure we have enough of the right people to finish it. Then we would, in all probability, need to write a JEP ( http://openjdk.java.net/jeps/1) which also means we will need a project lead. Then follow the JEP road and hope for the best I guess. On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose wrote: > Nir, > > You're not "hijacking" anything - I think it's been established that this > a broader "3D API support" issue. In fact, even broader than that. > > I'm only new on the JavaFX "scene" but I've looked through the history and > tried to analyse the present and anticipate the future. > > It seems that there are 2 main groups of JavaFX users: one that takes it > as it is and makes the most of it, sometimes in stunning and amazing ways > but they don't seem to like to rock the boat or try to force the > improvement of JavaFX itself so much. > > Then there's the others who get frustrated, ask for change, offer to > enable change or put on their boots and make change. A lot of them seem to > get "burned". > > We need people from both camps: one to showcase what can be done with what > we have in surprising ways and the others to drive innovation. > > I'm clearly in the 2nd group and I'm finding that there are quite a few of > us. I'm not so afraid of "getting burned" as we all take risks in life and > if you are passionate about something, you just go with it. > > But, the most disappointing aspect is that Oracle staff are often "M.I.A." > when discussing innovation and the future feature plans. As in this thread, > Oracle haven't exactly been chiming-in (and yes, I know a lot of it has > occurred outside of normal working hours). > > So Nir, Laurent (and the many others who are putting their hands up), > perhaps we should collaborate and not just "casually". OpenJFX is, after > all, "open" so perhaps a more formally coordinated team of motivated > community members can pool our resources and skills and "Just do it" (with > or without Oracle's help). > > I like what you are suggesting and what Sverre is requesting and what > numerous others are wanting, and I for one *want* them to become realities. > > Quite frankly, I don't see these changes and innovations (especially) > actually being realised any other way. > > Comments? > > Graciously, > > John-Val Rose > Chief Scientist/Architect > Rosethorn Technology > > > On 10 Sep 2017, at 23:13, Nir Lisker wrote: > > > > I don't want to hijack the WebGL discussion but since it rolled into the > 3D > > library territory anyway I'll give my 2 cents. > > > > 3D enhancement are indeed not planned for Java10 (at the minimum) and > > indeed you can't bring your own shader (asked already at > > https://stackoverflow.com/questions/43622856/can-we- > implement-our-own-materials-in-javafx), > > but I agree with Mike - you can, maybe somewhat surprisingly, do quite a > > lot with what there is. > > > > Perhaps the most limiting feature is not supporting industry standards of > > 3D modeling via converters (import/export). It has been suggested ( > > https://bugs.openjdk.java.net/browse/JDK-8091851) but last activity was > 5 > > years ago. As for shaders (materials), lightings etc., from what I > remember > > by looking around in the source, it will take some effort to rewrite the > > API to be able to accept custom ones but it's far from impossible. If > Phong > > is implemented there's little reason reason others won't fit (maybe > > reflective surfaces don't work). Similarly a directional light can be > based > > on the implemented point light be using a cone instead of a sphere. > > > > We've employed some clever tricks to get adequate "advanced features" > > results and considering that all of it can be single-handedly run on iOS > > and Android with Gluon Mobile (specifically JavaFXPorts) I think there > *is* > > a future in this direction and I'm willing to team up with whomever is > > interested provided we can get minimal support from the Oracle team. > From johnvalrose at gmail.com Mon Sep 11 00:49:08 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Mon, 11 Sep 2017 10:49:08 +1000 Subject: Innovation (Was: WebView and WebGL) In-Reply-To: References: Message-ID: Thanks Nir. I am very aware of the formal processes involved but also cognisant of the considerable time/delays and "red tape" that can be an undesirable consequence of such formality. I'm also not a "hope for the best" kinda guy. I think first we really need (and really hope) someone from Oracle to make an official comment on all these matters to ensure, as you suggest, that any or all of our efforts are "successful". There are multiple ways for a "lack of success" to result that have nothing to do with the quality, correctness, efficiency or even the "value" of our contributions. There's absolutely no point in devoting one nanosecond of anyone's time to a project doomed to fail for reasons beyond our control. Oracle: can you please comment on these issues and the various ways to expedite implementation of both resolutions and (especially) increase the velocity of innovation? Graciously, John-Val Rose > On 11 Sep 2017, at 10:25, Nir Lisker wrote: > > I don't mind giving it a go but I wouldn't like doing the work and then it > not getting implemented (if the result is a success). > > Personally, I think that the first thing we should do is make a list of > what exactly it is we are trying to do if only to get a sense of the > magnitude and be sure we have enough of the right people to finish it. Then > we would, in all probability, need to write a JEP ( > http://openjdk.java.net/jeps/1) which also means we will need a project > lead. Then follow the JEP road and hope for the best I guess. > > On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose > wrote: > >> Nir, >> >> You're not "hijacking" anything - I think it's been established that this >> a broader "3D API support" issue. In fact, even broader than that. >> >> I'm only new on the JavaFX "scene" but I've looked through the history and >> tried to analyse the present and anticipate the future. >> >> It seems that there are 2 main groups of JavaFX users: one that takes it >> as it is and makes the most of it, sometimes in stunning and amazing ways >> but they don't seem to like to rock the boat or try to force the >> improvement of JavaFX itself so much. >> >> Then there's the others who get frustrated, ask for change, offer to >> enable change or put on their boots and make change. A lot of them seem to >> get "burned". >> >> We need people from both camps: one to showcase what can be done with what >> we have in surprising ways and the others to drive innovation. >> >> I'm clearly in the 2nd group and I'm finding that there are quite a few of >> us. I'm not so afraid of "getting burned" as we all take risks in life and >> if you are passionate about something, you just go with it. >> >> But, the most disappointing aspect is that Oracle staff are often "M.I.A." >> when discussing innovation and the future feature plans. As in this thread, >> Oracle haven't exactly been chiming-in (and yes, I know a lot of it has > I don't mind giving it a go but I wouldn't like doing the work and then it > not getting implemented (if the result is a success). > > Personally, I think that the first thing we should do is make a list of > what exactly it is we are trying to do if only to get a sense of the > magnitude and be sure we have enough of the right people to finish it. Then > we would, in all probability, need to write a JEP ( > http://openjdk.java.net/jeps/1) which also means we will need a project > lead. Then follow the JEP road and hope for the best I guess. > > On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose > wrote: > >> Nir, >> >> You're not "hijacking" anything - I think it's been established that this >> a broader "3D API support" issue. In fact, even broader than that. >> >> I'm only new on the JavaFX "scene" but I've looked through the history and >> tried to analyse the present and anticipate the future. >> >> It seems that there are 2 main groups of JavaFX users: one that takes it >> as it is and makes the most of it, sometimes in stunning and amazing ways >> but they don't seem to like to rock the boat or try to force the >> improvement of JavaFX itself so much. >> >> Then there's the others who get frustrated, ask for change, offer to >> enable change or put on their boots and make change. A lot of them seem to >> get "burned". >> >> We need people from both camps: one to showcase what can be done with what >> we have in surprising ways and the others to drive innovation. >> >> I'm clearly in the 2nd group and I'm finding that there are quite a few of >> us. I'm not so afraid of "getting burned" as we all take risks in life and >> if you are passionate about something, you just go with it. >> >> But, the most disappointing aspect is that Oracle staff are often "M.I.A." >> when discussing innovation and the future feature plans. As in this thread, >> Oracle haven't exactly been chiming-in (and yes, I know a lot of it has >> occurred outside of normal working hours). >> >> So Nir, Laurent (and the many others who are putting their hands up), >> perhaps we should collaborate and not just "casually". OpenJFX is, after >> all, "open" so perhaps a more formally coordinated team of motivated >> community members can pool our resources and skills and "Just do it" (with >> or without Oracle's help). >> >> I like what you are suggesting and what Sverre is requesting and what >> numerous others are wanting, and I for one *want* them to become realities. >> >> Quite frankly, I don't see these changes and innovations (especially) >> actually being realised any other way. >> >> Comments? >> >> Graciously, >> >> John-Val Rose >> Chief Scientist/Architect >> Rosethorn Technology >> >>> On 10 Sep 2017, at 23:13, Nir Lisker wrote: >>> >>> I don't want to hijack the WebGL discussion but since it rolled into the >> 3D >>> library territory anyway I'll give my 2 cents. >>> >>> 3D enhancement are indeed not planned for Java10 (at the minimum) and >>> indeed you can't bring your own shader (asked already at >>> https://stackoverflow.com/questions/43622856/can-we- >> implement-our-own-materials-in-javafx), >>> but I agree with Mike - you can, maybe somewhat surprisingly, do quite a >>> lot with what there is. >>> >>> Perhaps the most limiting feature is not supporting industry standards of >>> 3D modeling via converters (import/export). It has been suggested ( >>> https://bugs.openjdk.java.net/browse/JDK-8091851) but last activity was >> 5 >>> years ago. As for shaders (materials), lightings etc., from what I >> remember >>> by looking around in the source, it will take some effort to rewrite the >>> API to be able to accept custom ones but it's far from impossible. If >> Phong >>> is implemented there's little reason reason others won't fit (maybe >>> reflective surfaces don't work). Similarly a directional light can be >> based >>> on the implemented point light be using a cone instead of a sphere. >>> >>> We've employed some clever tricks to get adequate "advanced features" >>> results and considering that all of it can be single-handedly run on iOS >>> and Android with Gluon Mobile (specifically JavaFXPorts) I think there >> *is* >>> a future in this direction and I'm willing to team up with whomever is >>> interested provided we can get minimal support from the Oracle team. >> From johan.vos at gluonhq.com Mon Sep 11 10:02:51 2017 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 11 Sep 2017 10:02:51 +0000 Subject: Innovation (Was: WebView and WebGL) In-Reply-To: References: Message-ID: >From experience, I can tell you that if you do the work and write high-quality code that makes OpenJFX better, I'm sure it will be possible to integrate it. - Johan On Mon, Sep 11, 2017 at 3:00 AM John-Val Rose wrote: > Thanks Nir. > > I am very aware of the formal processes involved but also cognisant of the > considerable time/delays and "red tape" that can be an undesirable > consequence of such formality. > > I'm also not a "hope for the best" kinda guy. > > I think first we really need (and really hope) someone from Oracle to make > an official comment on all these matters to ensure, as you suggest, that > any or all of our efforts are "successful". > > There are multiple ways for a "lack of success" to result that have > nothing to do with the quality, correctness, efficiency or even the "value" > of our contributions. > > There's absolutely no point in devoting one nanosecond of anyone's time to > a project doomed to fail for reasons beyond our control. > > Oracle: can you please comment on these issues and the various ways to > expedite implementation of both resolutions and (especially) increase the > velocity of innovation? > > Graciously, > > John-Val Rose > > > On 11 Sep 2017, at 10:25, Nir Lisker wrote: > > > > I don't mind giving it a go but I wouldn't like doing the work and then > it > > not getting implemented (if the result is a success). > > > > Personally, I think that the first thing we should do is make a list of > > what exactly it is we are trying to do if only to get a sense of the > > magnitude and be sure we have enough of the right people to finish it. > Then > > we would, in all probability, need to write a JEP ( > > http://openjdk.java.net/jeps/1) which also means we will need a project > > lead. Then follow the JEP road and hope for the best I guess. > > > > On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose > > wrote: > > > >> Nir, > >> > >> You're not "hijacking" anything - I think it's been established that > this > >> a broader "3D API support" issue. In fact, even broader than that. > >> > >> I'm only new on the JavaFX "scene" but I've looked through the history > and > >> tried to analyse the present and anticipate the future. > >> > >> It seems that there are 2 main groups of JavaFX users: one that takes it > >> as it is and makes the most of it, sometimes in stunning and amazing > ways > >> but they don't seem to like to rock the boat or try to force the > >> improvement of JavaFX itself so much. > >> > >> Then there's the others who get frustrated, ask for change, offer to > >> enable change or put on their boots and make change. A lot of them seem > to > >> get "burned". > >> > >> We need people from both camps: one to showcase what can be done with > what > >> we have in surprising ways and the others to drive innovation. > >> > >> I'm clearly in the 2nd group and I'm finding that there are quite a few > of > >> us. I'm not so afraid of "getting burned" as we all take risks in life > and > >> if you are passionate about something, you just go with it. > >> > >> But, the most disappointing aspect is that Oracle staff are often > "M.I.A." > >> when discussing innovation and the future feature plans. As in this > thread, > >> Oracle haven't exactly been chiming-in (and yes, I know a lot of it has > > I don't mind giving it a go but I wouldn't like doing the work and then > it > > not getting implemented (if the result is a success). > > > > Personally, I think that the first thing we should do is make a list of > > what exactly it is we are trying to do if only to get a sense of the > > magnitude and be sure we have enough of the right people to finish it. > Then > > we would, in all probability, need to write a JEP ( > > http://openjdk.java.net/jeps/1) which also means we will need a project > > lead. Then follow the JEP road and hope for the best I guess. > > > > On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose > > wrote: > > > >> Nir, > >> > >> You're not "hijacking" anything - I think it's been established that > this > >> a broader "3D API support" issue. In fact, even broader than that. > >> > >> I'm only new on the JavaFX "scene" but I've looked through the history > and > >> tried to analyse the present and anticipate the future. > >> > >> It seems that there are 2 main groups of JavaFX users: one that takes it > >> as it is and makes the most of it, sometimes in stunning and amazing > ways > >> but they don't seem to like to rock the boat or try to force the > >> improvement of JavaFX itself so much. > >> > >> Then there's the others who get frustrated, ask for change, offer to > >> enable change or put on their boots and make change. A lot of them seem > to > >> get "burned". > >> > >> We need people from both camps: one to showcase what can be done with > what > >> we have in surprising ways and the others to drive innovation. > >> > >> I'm clearly in the 2nd group and I'm finding that there are quite a few > of > >> us. I'm not so afraid of "getting burned" as we all take risks in life > and > >> if you are passionate about something, you just go with it. > >> > >> But, the most disappointing aspect is that Oracle staff are often > "M.I.A." > >> when discussing innovation and the future feature plans. As in this > thread, > >> Oracle haven't exactly been chiming-in (and yes, I know a lot of it has > >> occurred outside of normal working hours). > >> > >> So Nir, Laurent (and the many others who are putting their hands up), > >> perhaps we should collaborate and not just "casually". OpenJFX is, after > >> all, "open" so perhaps a more formally coordinated team of motivated > >> community members can pool our resources and skills and "Just do it" > (with > >> or without Oracle's help). > >> > >> I like what you are suggesting and what Sverre is requesting and what > >> numerous others are wanting, and I for one *want* them to become > realities. > >> > >> Quite frankly, I don't see these changes and innovations (especially) > >> actually being realised any other way. > >> > >> Comments? > >> > >> Graciously, > >> > >> John-Val Rose > >> Chief Scientist/Architect > >> Rosethorn Technology > >> > >>> On 10 Sep 2017, at 23:13, Nir Lisker wrote: > >>> > >>> I don't want to hijack the WebGL discussion but since it rolled into > the > >> 3D > >>> library territory anyway I'll give my 2 cents. > >>> > >>> 3D enhancement are indeed not planned for Java10 (at the minimum) and > >>> indeed you can't bring your own shader (asked already at > >>> https://stackoverflow.com/questions/43622856/can-we- > >> implement-our-own-materials-in-javafx), > >>> but I agree with Mike - you can, maybe somewhat surprisingly, do quite > a > >>> lot with what there is. > >>> > >>> Perhaps the most limiting feature is not supporting industry standards > of > >>> 3D modeling via converters (import/export). It has been suggested ( > >>> https://bugs.openjdk.java.net/browse/JDK-8091851) but last activity > was > >> 5 > >>> years ago. As for shaders (materials), lightings etc., from what I > >> remember > >>> by looking around in the source, it will take some effort to rewrite > the > >>> API to be able to accept custom ones but it's far from impossible. If > >> Phong > >>> is implemented there's little reason reason others won't fit (maybe > >>> reflective surfaces don't work). Similarly a directional light can be > >> based > >>> on the implemented point light be using a cone instead of a sphere. > >>> > >>> We've employed some clever tricks to get adequate "advanced features" > >>> results and considering that all of it can be single-handedly run on > iOS > >>> and Android with Gluon Mobile (specifically JavaFXPorts) I think there > >> *is* > >>> a future in this direction and I'm willing to team up with whomever is > >>> interested provided we can get minimal support from the Oracle team. > >> > From johnvalrose at gmail.com Mon Sep 11 10:25:50 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Mon, 11 Sep 2017 20:25:50 +1000 Subject: Innovation (Was: WebView and WebGL) In-Reply-To: References: Message-ID: <558194B0-D317-4D31-8562-8BDB50645865@gmail.com> Well, you would certainly know - thanks. That's very encouraging :-) > On 11 Sep 2017, at 20:02, Johan Vos wrote: > > From experience, I can tell you that if you do the work and write high-quality code that makes OpenJFX better, I'm sure it will be possible to integrate it. > > - Johan > > >> On Mon, Sep 11, 2017 at 3:00 AM John-Val Rose wrote: >> Thanks Nir. >> >> I am very aware of the formal processes involved but also cognisant of the considerable time/delays and "red tape" that can be an undesirable consequence of such formality. >> >> I'm also not a "hope for the best" kinda guy. >> >> I think first we really need (and really hope) someone from Oracle to make an official comment on all these matters to ensure, as you suggest, that any or all of our efforts are "successful". >> >> There are multiple ways for a "lack of success" to result that have nothing to do with the quality, correctness, efficiency or even the "value" of our contributions. >> >> There's absolutely no point in devoting one nanosecond of anyone's time to a project doomed to fail for reasons beyond our control. >> >> Oracle: can you please comment on these issues and the various ways to expedite implementation of both resolutions and (especially) increase the velocity of innovation? >> >> Graciously, >> >> John-Val Rose >> >> > On 11 Sep 2017, at 10:25, Nir Lisker wrote: >> > >> > I don't mind giving it a go but I wouldn't like doing the work and then it >> > not getting implemented (if the result is a success). >> > >> > Personally, I think that the first thing we should do is make a list of >> > what exactly it is we are trying to do if only to get a sense of the >> > magnitude and be sure we have enough of the right people to finish it. Then >> > we would, in all probability, need to write a JEP ( >> > http://openjdk.java.net/jeps/1) which also means we will need a project >> > lead. Then follow the JEP road and hope for the best I guess. >> > >> > On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose >> > wrote: >> > >> >> Nir, >> >> >> >> You're not "hijacking" anything - I think it's been established that this >> >> a broader "3D API support" issue. In fact, even broader than that. >> >> >> >> I'm only new on the JavaFX "scene" but I've looked through the history and >> >> tried to analyse the present and anticipate the future. >> >> >> >> It seems that there are 2 main groups of JavaFX users: one that takes it >> >> as it is and makes the most of it, sometimes in stunning and amazing ways >> >> but they don't seem to like to rock the boat or try to force the >> >> improvement of JavaFX itself so much. >> >> >> >> Then there's the others who get frustrated, ask for change, offer to >> >> enable change or put on their boots and make change. A lot of them seem to >> >> get "burned". >> >> >> >> We need people from both camps: one to showcase what can be done with what >> >> we have in surprising ways and the others to drive innovation. >> >> >> >> I'm clearly in the 2nd group and I'm finding that there are quite a few of >> >> us. I'm not so afraid of "getting burned" as we all take risks in life and >> >> if you are passionate about something, you just go with it. >> >> >> >> But, the most disappointing aspect is that Oracle staff are often "M.I.A." >> >> when discussing innovation and the future feature plans. As in this thread, >> >> Oracle haven't exactly been chiming-in (and yes, I know a lot of it has >> > I don't mind giving it a go but I wouldn't like doing the work and then it >> > not getting implemented (if the result is a success). >> > >> > Personally, I think that the first thing we should do is make a list of >> > what exactly it is we are trying to do if only to get a sense of the >> > magnitude and be sure we have enough of the right people to finish it. Then >> > we would, in all probability, need to write a JEP ( >> > http://openjdk.java.net/jeps/1) which also means we will need a project >> > lead. Then follow the JEP road and hope for the best I guess. >> > >> > On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose >> > wrote: >> > >> >> Nir, >> >> >> >> You're not "hijacking" anything - I think it's been established that this >> >> a broader "3D API support" issue. In fact, even broader than that. >> >> >> >> I'm only new on the JavaFX "scene" but I've looked through the history and >> >> tried to analyse the present and anticipate the future. >> >> >> >> It seems that there are 2 main groups of JavaFX users: one that takes it >> >> as it is and makes the most of it, sometimes in stunning and amazing ways >> >> but they don't seem to like to rock the boat or try to force the >> >> improvement of JavaFX itself so much. >> >> >> >> Then there's the others who get frustrated, ask for change, offer to >> >> enable change or put on their boots and make change. A lot of them seem to >> >> get "burned". >> >> >> >> We need people from both camps: one to showcase what can be done with what >> >> we have in surprising ways and the others to drive innovation. >> >> >> >> I'm clearly in the 2nd group and I'm finding that there are quite a few of >> >> us. I'm not so afraid of "getting burned" as we all take risks in life and >> >> if you are passionate about something, you just go with it. >> >> >> >> But, the most disappointing aspect is that Oracle staff are often "M.I.A." >> >> when discussing innovation and the future feature plans. As in this thread, >> >> Oracle haven't exactly been chiming-in (and yes, I know a lot of it has >> >> occurred outside of normal working hours). >> >> >> >> So Nir, Laurent (and the many others who are putting their hands up), >> >> perhaps we should collaborate and not just "casually". OpenJFX is, after >> >> all, "open" so perhaps a more formally coordinated team of motivated >> >> community members can pool our resources and skills and "Just do it" (with >> >> or without Oracle's help). >> >> >> >> I like what you are suggesting and what Sverre is requesting and what >> >> numerous others are wanting, and I for one *want* them to become realities. >> >> >> >> Quite frankly, I don't see these changes and innovations (especially) >> >> actually being realised any other way. >> >> >> >> Comments? >> >> >> >> Graciously, >> >> >> >> John-Val Rose >> >> Chief Scientist/Architect >> >> Rosethorn Technology >> >> >> >>> On 10 Sep 2017, at 23:13, Nir Lisker wrote: >> >>> >> >>> I don't want to hijack the WebGL discussion but since it rolled into the >> >> 3D >> >>> library territory anyway I'll give my 2 cents. >> >>> >> >>> 3D enhancement are indeed not planned for Java10 (at the minimum) and >> >>> indeed you can't bring your own shader (asked already at >> >>> https://stackoverflow.com/questions/43622856/can-we- >> >> implement-our-own-materials-in-javafx), >> >>> but I agree with Mike - you can, maybe somewhat surprisingly, do quite a >> >>> lot with what there is. >> >>> >> >>> Perhaps the most limiting feature is not supporting industry standards of >> >>> 3D modeling via converters (import/export). It has been suggested ( >> >>> https://bugs.openjdk.java.net/browse/JDK-8091851) but last activity was >> >> 5 >> >>> years ago. As for shaders (materials), lightings etc., from what I >> >> remember >> >>> by looking around in the source, it will take some effort to rewrite the >> >>> API to be able to accept custom ones but it's far from impossible. If >> >> Phong >> >>> is implemented there's little reason reason others won't fit (maybe >> >>> reflective surfaces don't work). Similarly a directional light can be >> >> based >> >>> on the implemented point light be using a cone instead of a sphere. >> >>> >> >>> We've employed some clever tricks to get adequate "advanced features" >> >>> results and considering that all of it can be single-handedly run on iOS >> >>> and Android with Gluon Mobile (specifically JavaFXPorts) I think there >> >> *is* >> >>> a future in this direction and I'm willing to team up with whomever is >> >>> interested provided we can get minimal support from the Oracle team. >> >> From kevin.rushforth at oracle.com Mon Sep 11 14:45:40 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 11 Sep 2017 07:45:40 -0700 Subject: WebView and WebGL In-Reply-To: <59B46345.3050003@oracle.com> References: <38ED8BFC-C134-48C9-8D6F-D385987E5181@gmail.com> <59B46345.3050003@oracle.com> Message-ID: <59B6A194.8000007@oracle.com> Yes, and this is primary reason that ANGLE exists, and is used to implement WebGL on Windows by translating GL calls to Direct3D. -- Kevin Philip Race wrote: > FWIW Java 2D ships OGL support on Windows (turned on by a flag) and > our SQE > have occasionally dutifully run tests in that mode and regularly turn up > bugs that look like driver bugs. As a consequence FX decided to not > ship it. > So although FX builds OGL support on all platforms it is excluded from > the > windows product distribution. > > -phil. > > On 9/9/17, 9:51 AM, Sten Nordstrom wrote: >> Having done some GL work on windows I've to agree with Mike. Windows GL >> drivers can be a disaster. If you are able to specify hardware for your >> users it's fine but if you take a random win-machine you are most >> likely in >> trouble. So something like angle would probably be the safest way to get >> EGL to work, especially as FX seems to use Direct3D on windows anyway. >> >> And yes, doing it as Mike proposes one would get an EGL node on the >> way to >> webgl. >> >> -- Sten From tomas.mikula at gmail.com Sun Sep 10 13:21:40 2017 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Sun, 10 Sep 2017 15:21:40 +0200 Subject: RichTextFX and Flowless looking for new maintainers (and home) Message-ID: Hi everyone, since I don't work with JavaFX (or GUI applications, or that matter) anymore, it is hard for me to keep up with the maintenance of my JavaFX projects. I am therefore looking for new maintainers (and possibly new home) of my most active JavaFX project, RichTextFX ( https://github.com/TomasMikula/RichTextFX/), and its essential dependency, Flowless (https://github.com/TomasMikula/Flowless/). I want to thank Jordan Martinez, who has been doing the bulk of fixing bugs and reviewing pull requests for the past two years. I am hoping that either some bigger user of RichTextFX, or a UI framework for which RichTextFX would be an attractive addition to the portfolio, would step forward and take it up. Jordan and I are happy to help with the transfer. Best regards, Tomas From j.tosovsky at email.cz Mon Sep 11 18:51:59 2017 From: j.tosovsky at email.cz (Jan Tosovsky) Date: Mon, 11 Sep 2017 20:51:59 +0200 Subject: WebView and WebGL In-Reply-To: References: Message-ID: <015f01d32b2f$0cec5af0$26c510d0$@tosovsky@email.cz> On 2017-09-10 Nir Lisker wrote: > > 3D enhancement are indeed not planned for Java10 (at the minimum) ... > but I agree with Mike - you can, maybe somewhat surprisingly, do quite > a lot with what there is. > > ... > > We've employed some clever tricks to get adequate "advanced features" > results and considering that all of it can be single-handedly run on > iOS and Android with Gluon Mobile (specifically JavaFXPorts) I think > there *is* a future in this direction ... Just for my curiosity, what is the main driver for developers to integrate 3D into JavaFX apps? Why not create apps utilizing WebGL directly in (full-featured) browsers using JavaScript bundled as GUI apps (via e.g. Meteor or CEF)? Is it about reusing Java knowledge, unique Java libraries, something else? Thanks for clarifying, Jan From johnvalrose at gmail.com Tue Sep 12 19:51:38 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Wed, 13 Sep 2017 05:51:38 +1000 Subject: WebView and WebGL In-Reply-To: <015f01d32b2f$0cec5af0$26c510d0$@tosovsky@email.cz> References: <015f01d32b2f$0cec5af0$26c510d0$@tosovsky@email.cz> Message-ID: <514E99F8-1853-4A83-9F24-E0A6AC24AB67@gmail.com> Hi Jan, I have to say that I find your question rather "curious"! Imagine asking a Qt developer "Why do you need 3D in Qt?". They'd probably look at you a bit strangely and then reply "Is this a trick question?". If there weren't the (advanced) 3D features in Qt then most C++ developers would simply ignore it! We've moved a long, long way on from "simple forms based applications" into an exciting new world of visualisations, animations, games, big data, 3D charting etc. Or, have we? Well, most developers and businesses have... unless you're a Java shop. There, you're most likely to still be using Swing because it has an enormous range of controls (all of which are much easier to customise than JavaFX controls) and you have a range of high-quality GUI builders and a wealth of trained, skilled and experienced staff resources to find if you need them. And guess what? Two of the most advanced and utilised IDEs (JetBrains IntelliJ and Google Android SDK) are *Swing* applications! But, you're still basically just "doing forms" and while that may be adequate for many types of companies, it is also significantly impeding their technology progress and limiting their developer's potential. No, they don't want to throw away all their Java domain models and business logic, retrain everyone in C++ and then spend years rewriting a massive codebase only to find years later that they have spent millions on building a bug-infested shiny new toy that does little or nothing more than what they started with. And they don't want to buy into the "HTML5 hype" either. They're going to face a complete brick wall trying to do what I just described by shifting to browser-based technologies. My suggestion of implementing WebGL in WebView was merely a quick way to at least permit decent 3D functionality to finally "creep" into JavaFX and then hopefully kickstart a full-blown injection of advanced 3D features. Besides, if you're going to embed a browser in your JavaFX app (which is actually a very common and valid requirement), wouldn't you want it to be at least able to use Google Maps properly? JavaFX is at a crossroads. Please, let's take the right road... Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology > On 12 Sep 2017, at 04:51, Jan Tosovsky wrote: > >> On 2017-09-10 Nir Lisker wrote: >> >> 3D enhancement are indeed not planned for Java10 (at the minimum) ... >> but I agree with Mike - you can, maybe somewhat surprisingly, do quite >> a lot with what there is. >> >> ... >> >> We've employed some clever tricks to get adequate "advanced features" >> results and considering that all of it can be single-handedly run on >> iOS and Android with Gluon Mobile (specifically JavaFXPorts) I think >> there *is* a future in this direction ... > > > Just for my curiosity, what is the main driver for developers to integrate 3D into JavaFX apps? > > Why not create apps utilizing WebGL directly in (full-featured) browsers using JavaScript bundled as GUI apps (via e.g. Meteor or CEF)? > > Is it about reusing Java knowledge, unique Java libraries, something else? > > Thanks for clarifying, > > Jan > > > > > From lennart.borjeson at cinnober.com Wed Sep 13 09:33:07 2017 From: lennart.borjeson at cinnober.com (=?iso-8859-1?Q?Lennart_B=F6rjeson?=) Date: Wed, 13 Sep 2017 09:33:07 +0000 Subject: Error building on Mac: compileDecoraNativeShadersMac fails Message-ID: <2DC54FAD-FF96-4302-97B9-619EE45BF134@cinnober.com> I'm trying to build OpenJFX on my Mac in order to integrate with openjdk 10 (the shenandoah project; I know the vanilla jdk 9 has javafx built-in). I believe I've followed the build instructions, but building still fails with: FAILURE: Build failed with an exception. * What went wrong: A problem was found with the configuration of task ':graphics:compileDecoraNativeShadersMac'. > Directory '/Users/lennartb/RaT/openJDK/javafx-9/modules/javafx.graphics/build/gensrc/headers/javafx.graphics' specified for property 'headers' does not exist. I've tried building both OpenJFX 9 and 10, with the same results. I have MacOS 10.12, gradle 3.1, jdk 9 b181, and Xcode installed. I've installed Qt 5.9, but I can't see that picked up by 'gradle projects'? Please advise. /Lennart From prasanta.sadhukhan at oracle.com Wed Sep 13 10:11:17 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 13 Sep 2017 15:41:17 +0530 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: References: Message-ID: Hi Sergey, I have modified the fix to not use SecondaryLoop and not to create one thread per dispatch http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/ Regards Prasanta On 8/30/2017 11:41 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > Can you please provide some description on how the SecondaryLoop will work when it will run on Appkit thread? Is it possible to get a deadlock here, since appkit will be blocked? > >> sequence, ie if the event is not first in sequence, then it will made >> to >> wait till it is the first event or till it is disposed. > Note that the new code (unlike lines 139-150) also waits 1 second, so we can get a situation when only one event will be dispatched per second, which is not we want to do. > I am not sure how often we create SequencedEvent but creating one thread per dispatch look inefficient. > > >> Modified webrev >> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/ >> >> Regards >> Prasanta >> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> >>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote: >>>> Now, since here FX App thread itself is the dispatch thread, we can >>>> be sure the events are dispatched in sequence and dispose is >> checked >>>> below after EDT. >>> Why we can sure about this? If the SequencedEvents were created in >> one >>> order but dispatch() for each were called in other order then the >>> sequenced will not be preserved? >>> >>>> I have tested with couple of singleThread testcase without any >> issue. >>>> Regards >>>> Prasanta >>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: >>>>> Hi, Prasanta, Kevin. >>>>> >>>>> I have two notes. >>>>> ? - Does this option is really supported? If it is supported we >>>>> should evaluate all usage of EventDispatchThread because in this >>>>> mode the dispatch thread is not EDT. For example I am not sure >> that >>>>> we can skip the code which expects EventDispatchThread. >>>>> ? - We have the similar pattern: "EventQueue.isDispatchThread() -> >>>>> cast(EventDispatchThread)" in some other places like in >>>>> DefaultKeyboardFocusManager. >>>>> >>>>> -----prasanta.sadhukhan at oracle.com? wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> Please review this fix >>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >>>>>> for an fx issue >>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132 >>>>>> >>>>>> More info in JBS. >>>>>> >>>>>> Regards >>>>>> Prasanta >>> From jeffhain at rocketmail.com Wed Sep 13 22:14:43 2017 From: jeffhain at rocketmail.com (Jeff Hain) Date: Wed, 13 Sep 2017 22:14:43 +0000 (UTC) Subject: snapshot and freeze References: <520527018.2657418.1505340883306.ref@mail.yahoo.com> Message-ID: <520527018.2657418.1505340883306@mail.yahoo.com> Hello. I encountered a (recoverable) freeze issue related to Canvas.snapshot(...), when either width or height (or both) used for Scene constructor is zero (I don't know scene width/height at construction time), even though it's not indicated as an invalid value. Using JDK 1.8.0_144, on Windows 7 64. With negative values, which are considered as uninitialized, the problem doesn't occur, so considering 0 as uninitialized as well might fix it, even though it might not address some deeper issue making such a freeze possible. The following code allows to reproduce it, as well as some workarounds: /** ?* Action: click multiple times on the canvas. ?* Expected: content is copy-shift-pasted each time. ?*/ public class JfxSnapshotMain extends Application { ??? /* ???? * Programmatic workarounds. ???? * NB: Resizing the stage manually ???? * (but not programmatically) also works, ???? * but not iconifying/deiconifying it. ???? */ ??? private static final boolean WORKAROUND_1 = false; ??? private static final boolean WORKAROUND_2 = false; ??? public static void main(String[] args) { ??????? launch(args); ??? } ??? @Override ??? public void start(Stage stage) { ??????? Pane root = new Pane(); ??????? double initWidth = 0.1; ??????? double initHeight = (WORKAROUND_1 ? 0.1 : 0.0); ??????? Scene scene = new Scene(root, initWidth, initHeight); ??????? double width = 200.0; ??????? double height = 100.0; ??????? Canvas canvas = new Canvas(width, height); ??????? canvas.addEventHandler( ??????????????? MouseEvent.MOUSE_PRESSED, ??????????????? new EventHandler() { ??????????? @Override ??????????? public void handle(MouseEvent event) { ??????????????? System.out.println("handle(" + event + ")"); ??????????????? takeSnapshotAndDrawShifted(canvas); ??????????????? if (WORKAROUND_2) { stage.hide(); stage.show(); } ??????????? } ??????? }); ??????? root.getChildren().add(canvas); ??????? stage.setWidth(width); ??????? stage.setHeight(height); ??????? stage.setScene(scene); ??????? drawStuffs(canvas); ??????? stage.show(); ??? } ??? private static void drawStuffs(Canvas canvas) { ??????? GraphicsContext gc = canvas.getGraphicsContext2D(); ??????? gc.setStroke(Color.BLACK); ??????? gc.strokeText("Click This", 10.0, 10.0); ??? } ??? private static void takeSnapshotAndDrawShifted(Canvas canvas) { ??????? WritableImage img = canvas.snapshot(null, null); ??????? canvas.getGraphicsContext2D().drawImage(img, 10.0, 10.0); ??? } } -Jeff From mike at plan99.net Thu Sep 14 09:24:04 2017 From: mike at plan99.net (Mike Hearn) Date: Thu, 14 Sep 2017 10:24:04 +0100 Subject: WebView and WebGL In-Reply-To: <59b6db8c.9248ca0a.f630a.9495SMTPIN_ADDED_BROKEN@mx.google.com> References: <59b6db8c.9248ca0a.f630a.9495SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: > > Is it about reusing Java knowledge, unique Java libraries, something else? > You seem to be asking "why write desktop apps" in general. For my own projects there have been two different drivers (for different programs): 1. Peer to peer networks and the web don't mix well. If you want to write a P2P app, it's going to be a desktop app. 2. Security The latter is not something that's talked about much but my company is not the only one that is motivated by security. I was talking to someone a few days ago who works at a very large, well known software firm and he told me they have a department that handles sensitive documents. Their admin and control plane apps are all desktop apps (not JavaFX though) because they want the additional security. Why more secure? No XSS, no XSRF, no clickjacking, no injection-prone text based protocols (if you do it right) etc. The web is a fundamentally insecure platform because it's entirely text based, so buffer boundaries are marked in-band instead of using length prefixes. This design choice is so systemic the web essentially cannot be fixed. Managed desktop apps using traditional widget toolkits, with binary protocols between client and server (e.g. protobufs) eliminate entire classes of vulnerabilities and the few classes that remain are easily understood and caught via audit or code review. From j.tosovsky at email.cz Thu Sep 14 20:18:31 2017 From: j.tosovsky at email.cz (Jan Tosovsky) Date: Thu, 14 Sep 2017 22:18:31 +0200 Subject: WebView and WebGL In-Reply-To: <514E99F8-1853-4A83-9F24-E0A6AC24AB67@gmail.com> References: <015f01d32b2f$0cec5af0$26c510d0$@tosovsky@email.cz> <514E99F8-1853-4A83-9F24-E0A6AC24AB67@gmail.com> Message-ID: <01c501d32d96$a3036790$e90a36b0$@tosovsky@email.cz> Thanks for your valuable input. I appreciate it. To clarify my point of view: (1) There are no resources to implement Java based HTML renderer to be on par with major rendering engines. (2) Any integrated 3rd party engine will bring some limitations. In sum, to avoid any technology limits for any app heavily dependent on web technologies (like WebGL) I'd rather choose browser-based solution directly. Moreover, in my eyes WebKit lags behind Blink (and I expect this gets even worse in near future). (Just my feeling, do not ask for sources of such theories). As a end user you can switch to another browser if the current one doesn't support something you need. As a Java user with integrated engine you are stick to that engine. There is no choice. So I was curious why people insist on that, from my POV, dangerous way ;-) I think this quote gives me an answer: > ... if you're going to embed a browser in your JavaFX app (which > is actually a very common and valid requirement), wouldn't you want it > to be at least able to use Google Maps properly? Jan > -----Original Message----- > From: John-Val Rose [mailto:johnvalrose at gmail.com] > Sent: Tuesday, September 12, 2017 9:52 PM > To: Jan Tosovsky > Cc: openjfx-dev at openjdk.java.net > Subject: Re: WebView and WebGL > > Hi Jan, > > I have to say that I find your question rather "curious"! > > Imagine asking a Qt developer "Why do you need 3D in Qt?". They'd > probably look at you a bit strangely and then reply "Is this a trick > question?". > > If there weren't the (advanced) 3D features in Qt then most C++ > developers would simply ignore it! We've moved a long, long way on from > "simple forms based applications" into an exciting new world of > visualisations, animations, games, big data, 3D charting etc. > > Or, have we? > > Well, most developers and businesses have... unless you're a Java shop. > There, you're most likely to still be using Swing because it has an > enormous range of controls (all of which are much easier to customise > than JavaFX controls) and you have a range of high-quality GUI builders > and a wealth of trained, skilled and experienced staff resources to > find if you need them. > > And guess what? Two of the most advanced and utilised IDEs (JetBrains > IntelliJ and Google Android SDK) are *Swing* applications! > > But, you're still basically just "doing forms" and while that may be > adequate for many types of companies, it is also significantly impeding > their technology progress and limiting their developer's potential. > > No, they don't want to throw away all their Java domain models and > business logic, retrain everyone in C++ and then spend years rewriting > a massive codebase only to find years later that they have spent > millions on building a bug-infested shiny new toy that does little or > nothing more than what they started with. > > And they don't want to buy into the "HTML5 hype" either. They're going > to face a complete brick wall trying to do what I just described by > shifting to browser-based technologies. > > My suggestion of implementing WebGL in WebView was merely a quick way > to at least permit decent 3D functionality to finally "creep" into > JavaFX and then hopefully kickstart a full-blown injection of advanced > 3D features. > > Besides, if you're going to embed a browser in your JavaFX app (which > is actually a very common and valid requirement), wouldn't you want it > to be at least able to use Google Maps properly? > > JavaFX is at a crossroads. > > Please, let's take the right road... > > Graciously, > > John-Val Rose > Chief Scientist/Architect > Rosethorn Technology > > > On 12 Sep 2017, at 04:51, Jan Tosovsky wrote: > > > >> On 2017-09-10 Nir Lisker wrote: > >> > >> 3D enhancement are indeed not planned for Java10 (at the minimum) > ... > >> but I agree with Mike - you can, maybe somewhat surprisingly, do > quite > >> a lot with what there is. > >> > >> ... > >> > >> We've employed some clever tricks to get adequate "advanced > features" > >> results and considering that all of it can be single-handedly run on > >> iOS and Android with Gluon Mobile (specifically JavaFXPorts) I think > >> there *is* a future in this direction ... > > > > > > Just for my curiosity, what is the main driver for developers to > integrate 3D into JavaFX apps? > > > > Why not create apps utilizing WebGL directly in (full-featured) > browsers using JavaScript bundled as GUI apps (via e.g. Meteor or CEF)? > > > > Is it about reusing Java knowledge, unique Java libraries, something > else? > > > > Thanks for clarifying, > > > > Jan > > > > > > > > > > From jeffhain at rocketmail.com Thu Sep 14 20:36:22 2017 From: jeffhain at rocketmail.com (Jeff Hain) Date: Thu, 14 Sep 2017 20:36:22 +0000 (UTC) Subject: snapshot and freeze References: <334320095.3890742.1505421382668.ref@mail.yahoo.com> Message-ID: <334320095.3890742.1505421382668@mail.yahoo.com> Just submitted a bug for it. From ambarish.rapte at oracle.com Fri Sep 15 04:46:48 2017 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Fri, 15 Sep 2017 04:46:48 +0000 (UTC) Subject: RFR JDK-8177633: [MenuButton] Add setOn* APIs to set event handlers for show/hide event types. Message-ID: Hi All, Request you to review a fix: Fix : http://cr.openjdk.java.net/~arapte/fx/8177633/webrev.00/ Bug : https://bugs.openjdk.java.net/browse/JDK-8177633 Regards, Ambarish From ajit.ghaisas at oracle.com Mon Sep 18 12:31:11 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 18 Sep 2017 05:31:11 -0700 (PDT) Subject: [10] Review request : JDK-8089265 : [ProgressIndicator] behaves itself wrong, when aligned Message-ID: Hi Jonathan, Request you to review following fix : Issue : https://bugs.openjdk.java.net/browse/JDK-8089265 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8089265/webrev.0/ Regards, Ajit From Sergey.Bylokhov at oracle.com Mon Sep 18 18:27:50 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 18 Sep 2017 11:27:50 -0700 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: References: Message-ID: Hi, Prasanta. - In this version it is unclear what is a purpose of the "fxCheckSequenceThread.start()". This code will start the thread and will continue execution, it will not wait when the thread will stop. - The DefaultKeyboardFocusManager also should check for "javafx.embed.singleThread" On 9/13/17 03:11, Prasanta Sadhukhan wrote: > Hi Sergey, > > I have modified the fix to not use SecondaryLoop and not to create one > thread per dispatch > http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/ > > Regards > Prasanta > On 8/30/2017 11:41 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> Can you please provide some description on how the SecondaryLoop will >> work when it will run on Appkit thread? Is it possible to get a >> deadlock here, since appkit will be blocked? >> >>> sequence, ie if the event is not first in sequence, then it will made >>> to >>> wait till it is the first event or till it is disposed. >> Note that the new code (unlike lines 139-150) also waits 1 second, so >> we can get a situation when only one event will be dispatched per >> second, which is not we want to do. >> I am not sure how often we create SequencedEvent but creating one >> thread per dispatch look inefficient. >> >> >>> Modified webrev >>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/ >>> >>> Regards >>> Prasanta >>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote: >>>> Hi, Prasanta. >>>> >>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote: >>>>> Now, since here FX App thread itself is the dispatch thread, we can >>>>> be sure the events are dispatched in sequence and dispose is >>> checked >>>>> below after EDT. >>>> Why we can sure about this? If the SequencedEvents were created in >>> one >>>> order but dispatch() for each were called in other order then the >>>> sequenced will not be preserved? >>>> >>>>> I have tested with couple of singleThread testcase without any >>> issue. >>>>> Regards >>>>> Prasanta >>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: >>>>>> Hi, Prasanta, Kevin. >>>>>> >>>>>> I have two notes. >>>>>> ?? - Does this option is really supported? If it is supported we >>>>>> should evaluate all usage of EventDispatchThread because in this >>>>>> mode the dispatch thread is not EDT. For example I am not sure >>> that >>>>>> we can skip the code which expects EventDispatchThread. >>>>>> ?? - We have the similar pattern: "EventQueue.isDispatchThread() -> >>>>>> cast(EventDispatchThread)" in some other places like in >>>>>> DefaultKeyboardFocusManager. >>>>>> >>>>>> -----prasanta.sadhukhan at oracle.com? wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Please review this fix >>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >>>>>>> for an fx issue >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132 >>>>>>> >>>>>>> More info in JBS. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Wed Sep 20 05:26:31 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 20 Sep 2017 10:56:31 +0530 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: References: Message-ID: Hi Sergey, On 9/18/2017 11:57 PM, Sergey Bylokhov wrote: > Hi, Prasanta. > ?- In this version it is unclear what is a purpose of the > "fxCheckSequenceThread.start()". This code will start the thread and > will continue execution, it will not wait when the thread will stop. > ?- The DefaultKeyboardFocusManager also should check for > "javafx.embed.singleThread" > Please find modified webrev catering to both comments http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/ Regards Prasanta > > On 9/13/17 03:11, Prasanta Sadhukhan wrote: >> Hi Sergey, >> >> I have modified the fix to not use SecondaryLoop and not to create >> one thread per dispatch >> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/ >> >> Regards >> Prasanta >> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote: >>> Hi, Prasanta. >>> Can you please provide some description on how the SecondaryLoop >>> will work when it will run on Appkit thread? Is it possible to get a >>> deadlock here, since appkit will be blocked? >>> >>>> sequence, ie if the event is not first in sequence, then it will made >>>> to >>>> wait till it is the first event or till it is disposed. >>> Note that the new code (unlike lines 139-150) also waits 1 second, >>> so we can get a situation when only one event will be dispatched per >>> second, which is not we want to do. >>> I am not sure how often we create SequencedEvent but creating one >>> thread per dispatch look inefficient. >>> >>> >>>> Modified webrev >>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/ >>>> >>>> Regards >>>> Prasanta >>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote: >>>>> Hi, Prasanta. >>>>> >>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote: >>>>>> Now, since here FX App thread itself is the dispatch thread, we can >>>>>> be sure the events are dispatched in sequence and dispose is >>>> checked >>>>>> below after EDT. >>>>> Why we can sure about this? If the SequencedEvents were created in >>>> one >>>>> order but dispatch() for each were called in other order then the >>>>> sequenced will not be preserved? >>>>> >>>>>> I have tested with couple of singleThread testcase without any >>>> issue. >>>>>> Regards >>>>>> Prasanta >>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Prasanta, Kevin. >>>>>>> >>>>>>> I have two notes. >>>>>>> ?? - Does this option is really supported? If it is supported we >>>>>>> should evaluate all usage of EventDispatchThread because in this >>>>>>> mode the dispatch thread is not EDT. For example I am not sure >>>> that >>>>>>> we can skip the code which expects EventDispatchThread. >>>>>>> ?? - We have the similar pattern: "EventQueue.isDispatchThread() -> >>>>>>> cast(EventDispatchThread)" in some other places like in >>>>>>> DefaultKeyboardFocusManager. >>>>>>> >>>>>>> -----prasanta.sadhukhan at oracle.com? wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Please review this fix >>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >>>>>>>> for an fx issue >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132 >>>>>>>> >>>>>>>> More info in JBS. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>> >> > > From rajath.kamath at oracle.com Wed Sep 20 09:34:32 2017 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Wed, 20 Sep 2017 02:34:32 -0700 (PDT) Subject: [webkit][10] Review request - 8187671: Drag and Drop of text or html results in an image Message-ID: Hi all, Please review a bug fix done for `Drag and Drop use case in WebView` explained in the JBS JBS : https://bugs.openjdk.java.net/browse/JDK-8187671 WebRev : http://cr.openjdk.java.net/~ghb/rkamath/8187671/webrev.00/ Thanks, Rajath From mimac2 at gmail.com Wed Sep 20 16:34:53 2017 From: mimac2 at gmail.com (Milan Fabian) Date: Wed, 20 Sep 2017 18:34:53 +0200 Subject: [PATCH] 8182572 Numpad keys not working with JavaFX Monocle Message-ID: Hello, I have prepared patch (attached) for bug JDK-8182572 (http://bugs.java.com/ bugdatabase/view_bug.do?bug_id=JDK-8182572). The keys on numpad are now correctly mapped to KeyEvents. The patch was tested on Raspberry Pi with various builds OpenJDK 8 and various keyboards. I don't have any other device which supports Monocle, if anybody has such device, I would be glad if you could test it on it as well. As this is my first patch submitted to OpenJDK, is there anything else I should add? Best Regards Milan Fabian -------------- next part -------------- diff --git a/modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxKeyProcessor.java b/modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxKeyProcessor.java --- a/modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxKeyProcessor.java +++ b/modules/graphics/src/main/java/com/sun/glass/ui/monocle/LinuxKeyProcessor.java @@ -76,6 +76,16 @@ } else if (linuxKeyCode >= LinuxInput.KEY_F13 && linuxKeyCode <= LinuxInput.KEY_F24) { return linuxKeyCode - LinuxInput.KEY_F13 + KeyEvent.VK_F13; } else switch (linuxKeyCode) { + case LinuxInput.KEY_KP0: return KeyEvent.VK_NUMPAD0; + case LinuxInput.KEY_KP1: return KeyEvent.VK_NUMPAD1; + case LinuxInput.KEY_KP2: return KeyEvent.VK_NUMPAD2; + case LinuxInput.KEY_KP3: return KeyEvent.VK_NUMPAD3; + case LinuxInput.KEY_KP4: return KeyEvent.VK_NUMPAD4; + case LinuxInput.KEY_KP5: return KeyEvent.VK_NUMPAD5; + case LinuxInput.KEY_KP6: return KeyEvent.VK_NUMPAD6; + case LinuxInput.KEY_KP7: return KeyEvent.VK_NUMPAD7; + case LinuxInput.KEY_KP8: return KeyEvent.VK_NUMPAD8; + case LinuxInput.KEY_KP9: return KeyEvent.VK_NUMPAD9; case LinuxInput.KEY_0: return KeyEvent.VK_0; case LinuxInput.KEY_A: return KeyEvent.VK_A; case LinuxInput.KEY_B: return KeyEvent.VK_B; @@ -110,7 +120,9 @@ case LinuxInput.KEY_CAPSLOCK: return KeyEvent.VK_CAPS_LOCK; case LinuxInput.KEY_TAB: return KeyEvent.VK_TAB; case LinuxInput.KEY_GRAVE: return KeyEvent.VK_BACK_QUOTE; + case LinuxInput.KEY_KPMINUS: case LinuxInput.KEY_MINUS: return KeyEvent.VK_MINUS; + case LinuxInput.KEY_KPPLUS: return KeyEvent.VK_PLUS; case LinuxInput.KEY_EQUAL: return KeyEvent.VK_EQUALS; case LinuxInput.KEY_BACKSPACE: return KeyEvent.VK_BACKSPACE; case LinuxInput.KEY_LEFTBRACE: return KeyEvent.VK_BRACELEFT; @@ -119,7 +131,9 @@ case LinuxInput.KEY_SEMICOLON: return KeyEvent.VK_SEMICOLON; case LinuxInput.KEY_APOSTROPHE: return KeyEvent.VK_QUOTE; case LinuxInput.KEY_COMMA: return KeyEvent.VK_COMMA; + case LinuxInput.KEY_KPDOT: case LinuxInput.KEY_DOT: return KeyEvent.VK_PERIOD; + case LinuxInput.KEY_KPSLASH: case LinuxInput.KEY_SLASH: return KeyEvent.VK_SLASH; case LinuxInput.KEY_LEFTALT: case LinuxInput.KEY_RIGHTALT: return KeyEvent.VK_ALT; @@ -127,6 +141,7 @@ case LinuxInput.KEY_RIGHTMETA: return KeyEvent.VK_COMMAND; case LinuxInput.KEY_SPACE: return KeyEvent.VK_SPACE; case LinuxInput.KEY_MENU: return KeyEvent.VK_CONTEXT_MENU; + case LinuxInput.KEY_KPENTER: case LinuxInput.KEY_ENTER: return KeyEvent.VK_ENTER; case LinuxInput.KEY_LEFT: return KeyEvent.VK_LEFT; case LinuxInput.KEY_RIGHT: return KeyEvent.VK_RIGHT; @@ -141,6 +156,7 @@ case LinuxInput.KEY_NUMLOCK: return KeyEvent.VK_NUM_LOCK; case LinuxInput.KEY_ESC: return KeyEvent.VK_ESCAPE; case LinuxInput.KEY_NUMERIC_STAR: return KeyEvent.VK_MULTIPLY; + case LinuxInput.KEY_KPASTERISK: return KeyEvent.VK_ASTERISK; default: return KeyEvent.VK_UNDEFINED; } } From rajath.kamath at oracle.com Thu Sep 21 09:02:39 2017 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Thu, 21 Sep 2017 02:02:39 -0700 (PDT) Subject: [webkit][10] Review request - 8187726: Copy and Paste of Image not resulting in expected behavior Message-ID: <7368440c-cdfd-47e5-84b5-29145fe11219@default> Hi all, Please review a patch for fixing Copy and Paste functionality in FX WebView. Details in JBS. JBS : https://bugs.openjdk.java.net/browse/JDK-8187726 WebRev : http://cr.openjdk.java.net/~ghb/rkamath/8187726/webrev.00/ Thanks, Rajath From johan.vos at gluonhq.com Thu Sep 21 10:12:19 2017 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 21 Sep 2017 10:12:19 +0000 Subject: [PATCH] 8182572 Numpad keys not working with JavaFX Monocle In-Reply-To: References: Message-ID: That patch looks ok for me, and it doesn't break anything in the Android build (the other consumer of Monocle). - Johan On Wed, Sep 20, 2017 at 6:45 PM Milan Fabian wrote: > Hello, > > I have prepared patch (attached) for bug JDK-8182572 ( > http://bugs.java.com/ > bugdatabase/view_bug.do?bug_id=JDK-8182572 > ). The > keys on numpad are now > correctly mapped to KeyEvents. > > The patch was tested on Raspberry Pi with various builds OpenJDK 8 and > various keyboards. I don't have any other device which supports Monocle, if > anybody has such device, I would be glad if you could test it on it as > well. > > As this is my first patch submitted to OpenJDK, is there anything else I > should add? > > Best Regards > Milan Fabian > From alexander.zvegintsev at oracle.com Thu Sep 21 10:38:09 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 21 Sep 2017 16:08:09 +0530 Subject: [10] Review request for 185634: Java Fx-Swing dialogs appearing behind main stage Message-ID: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8185634 -- Thanks, Alexander. From neacsu.cristianstefan at gmail.com Thu Sep 21 12:32:40 2017 From: neacsu.cristianstefan at gmail.com (Neacsu Cristian) Date: Thu, 21 Sep 2017 15:32:40 +0300 Subject: Is it a clean way to short-circuit the render path? Message-ID: Hello, I am not sure that there is the proper place to ask this, but I spent a lot of time reading documentations, looking at presentations and debugging the source code. Please accept my apologizes if I post this in the wrong place. Thank you. Let's imagine this structure: Pane - scene pane Pane - button pane ImageView - image of the button TextView - text of the button Therefore we have a root scene pane and a button. In the moment when I hover the button, I will change the ImageView. Therefore the default render path returned will be [Scene pane, Button Pane, Image View] shown with -Dprism.printrendergraph=true. The main problem is that for certain scenarios I do not need to render the complete path. In other words, I do not need to render anything above (parent, grand parent etc.) Button Pane, because I know already that my button is an opaque rectangle image. The current behavior (as far as I was able to debug) of the View Painter: First is determine the dirtyRegionContainer. Then is calling the root path regions (getRootPath) and is going to try to see which elements are overlapping the dirty region. In our case is going from the scene root, is seeing that it will overlap therefore will be rendered (marking the culling bits to DIRTY_REGION_INTERSECTS_NODE_BOUNDS), than is looking for all the children, than is picking those which intersect/contains the dirty region and so on. But there is no need (at least in the current scenario) to render those NGNodes that do not contain the dirty region. Or much simpler, the root path should start with the node that is the source of the dirty region (in the current case, the Button Pane, excluding the Scene pane). Is it a clean way to achieve this? Thank you in advance, Cristian-Stefan From philip.race at oracle.com Thu Sep 21 16:55:27 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 21 Sep 2017 09:55:27 -0700 Subject: [10] Review request for 185634: Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> Message-ID: Some procedural comments : Since 90% of this is in AWT code, I'd have thought awt-dev should be included here. I've added that list. And apart from needing separate bug ids, I don't see why the bug below is confidential. I agree with what Kevin pointed out off-line that as in the dialog case, the FX side of the code can use reflection and simply be a harmless non-functional no-op if the SwingAccessor does not provide the new method. BTW 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } should be "dd" not "d". -phil. On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: > Hello, > > please review the fix > > http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ > > for the issue > > https://bugs.openjdk.java.net/browse/JDK-8185634 > From alexander.zvegintsev at oracle.com Fri Sep 22 05:56:04 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Fri, 22 Sep 2017 11:26:04 +0530 Subject: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage In-Reply-To: References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> Message-ID: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> Hi Phil, Please review the updated fix with reflection incorporated http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ New issue created JDK-8187803 as JDK counterpart of this issue. Thanks, Alexander. On 21/09/2017 22:25, Phil Race wrote: > Some procedural comments : > Since 90% of this is in AWT code, I'd have thought awt-dev should be > included here. > I've added that list. > > And apart from needing separate bug ids, I don't see why the bug below > is confidential. > > > I agree with what Kevin pointed out off-line that as in the dialog > case, the FX side > of the code can use reflection and simply be a harmless non-functional > no-op > if the SwingAccessor does not provide the new method. > > BTW > 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } > should be "dd" not "d". > > -phil. > > On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: >> Hello, >> >> please review the fix >> >> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ >> >> for the issue >> >> https://bugs.openjdk.java.net/browse/JDK-8185634 >> > From nlisker at gmail.com Fri Sep 22 12:38:48 2017 From: nlisker at gmail.com (Nir Lisker) Date: Fri, 22 Sep 2017 15:38:48 +0300 Subject: OpenJFX initiative Message-ID: I didn't see any update on the idea for our initiative. Are we still waiting for a reply from Oracle or do we go with Johan Vos's experience? I think that the least we can do without putting any work into this is have a semi-formal list of people who would like to work on this and a list of what features we would be working on. I feel that I still don't know the scope of what we are trying to do, only pieces of it. From prasanta.sadhukhan at oracle.com Fri Sep 22 16:52:16 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 22 Sep 2017 22:22:16 +0530 Subject: [10] JDK-8187781: "InvalidDnDOperationException: Drag and drop in progress" while running javafx application with option -Djavafx.embed.singleThread=true Message-ID: <1e904390-1ba1-f104-326b-ec41e41a2477@oracle.com> Hi All, Please review a fix http://cr.openjdk.java.net/~psadhukhan/fx/8187781/webrev.00/ for fx issue https://bugs.openjdk.java.net/browse/JDK-8187781 More info in JBS. Regards Prasanta From johnvalrose at gmail.com Fri Sep 22 21:08:09 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 23 Sep 2017 07:08:09 +1000 Subject: OpenJFX initiative In-Reply-To: References: Message-ID: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> The concept of ?innovation? no longer seems to apply to JavaFX, at least not from Oracle?s perspective. If you read the official list of changes in the just-released Java 9, AWT (yes, AWT) has more changes than JavaFX and even then the only significant change is to make it Jigsaw compatible. A product like this needs a very clear ?roadmap? of development and introduction of new features but the link on the Oracle JavaFX Documentation page for ?roadmap? leads to a place known as ?404?. I hope that?s not a room number in ?Hotel California?. So, innovation for JavaFX falls back as a community responsibility but is very difficult without any cooperation from Oracle themselves. I personally have not been able to get any response from them except ?float your ideas on the mailing list to see what interest there is?. Note, that ?interest? is only from the community itself... and then what? What do you mean by ?go with Johan Vos?s experience?? Yes, he and Gluon are fantastic innovators and have built a small company of top-notch talent and are able to crank-out new products and enhancements with impressive frequency. Are you suggesting we all start similar companies? Johan is a former Oracle employee and probably has a well-established relationship with them and access to knowledge that others don?t. Personally, I love what he?s doing and hope Gluon expands rapidly to enable as much innovation as possible. But what about the rest of us? What are we supposed to do? How do we get large-scale changes to happen? Well, I don?t know. But we?re better as a team than a bunch of individuals each trying to get some feature implemented in an uncoordinated fashion. The other real issue is that everyone seems to have their own perspective on exactly what JavaFX is or should be. That makes the community ineffective unless someone manages innovation for JavaFX in general. I?d be happy to be that person but sadly, it?s not for me to make that call. Johan is like the de facto ?Head of Innovation for JavaFX? at the moment but he has his own agenda (mainly in the mobile space) and monetises his efforts. That?s what businesses do. So, I think we need to firstly establish just what JavaFX is *now* (even this is not clear) and also what it *should be* (where we coalesce everyone?s own ideas) so we can move forward. That is of course *if* JavaFX is actually going to ?move forward? rather than ?sideways?. Honestly though, if you?re not moving forward, you are really going backward as you watch the rest of the world disappear over the horizon... Graciously, John-Val Rose > On 22 Sep 2017, at 22:38, Nir Lisker wrote: > > I didn't see any update on the idea for our initiative. Are we still waiting for a reply from Oracle or do we go with Johan Vos's experience? > > I think that the least we can do without putting any work into this is have a semi-formal list of people who would like to work on this and a list of what features we would be working on. I feel that I still don't know the scope of what we are trying to do, only pieces of it. From philip.race at oracle.com Fri Sep 22 22:05:40 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Sep 2017 15:05:40 -0700 Subject: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> Message-ID: <213a2fbf-6d66-7e8b-adda-289374f09e3f@oracle.com> I need to look more closely but at a quick glance I don't see any problems so a tentative +1 .. but a final +1 will go in the bug. Have you tested the various configurations .. running this on top of current JDK (not FX) 10 both with and without the FX changes ? -phil. On 09/21/2017 10:56 PM, Alexander Zvegintsev wrote: > > Hi Phil, > > Please review the updated fix with reflection incorporated > http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ > > New issue created JDK-8187803 > as JDK counterpart > of this issue. > > Thanks, > Alexander. > On 21/09/2017 22:25, Phil Race wrote: >> Some procedural comments : >> Since 90% of this is in AWT code, I'd have thought awt-dev should be >> included here. >> I've added that list. >> >> And apart from needing separate bug ids, I don't see why the bug >> below is confidential. >> >> >> I agree with what Kevin pointed out off-line that as in the dialog >> case, the FX side >> of the code can use reflection and simply be a harmless >> non-functional no-op >> if the SwingAccessor does not provide the new method. >> >> BTW >> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } >> should be "dd" not "d". >> >> -phil. >> >> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: >>> Hello, >>> >>> please review the fix >>> >>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ >>> >>> for the issue >>> >>> https://bugs.openjdk.java.net/browse/JDK-8185634 >>> >> > From nlisker at gmail.com Fri Sep 22 23:08:30 2017 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 23 Sep 2017 02:08:30 +0300 Subject: OpenJFX initiative In-Reply-To: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> References: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> Message-ID: > What do you mean by ?go with Johan Vos?s experience?? What he said here: http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-September/020801.html . On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose wrote: > The concept of ?innovation? no longer seems to apply to JavaFX, at least > not from Oracle?s perspective. > > If you read the official list of changes in the just-released Java 9, AWT > (yes, AWT) has more changes than JavaFX and even then the only significant > change is to make it Jigsaw compatible. > > A product like this needs a very clear ?roadmap? of development and > introduction of new features but the link on the Oracle JavaFX > Documentation page for ?roadmap? leads to a place known as ?404?. I hope > that?s not a room number in ?Hotel California?. > > So, innovation for JavaFX falls back as a community responsibility but is > very difficult without any cooperation from Oracle themselves. > > I personally have not been able to get any response from them except > ?float your ideas on the mailing list to see what interest there is?. Note, > that ?interest? is only from the community itself... and then what? > > What do you mean by ?go with Johan Vos?s experience?? Yes, he and Gluon > are fantastic innovators and have built a small company of top-notch talent > and are able to crank-out new products and enhancements with impressive > frequency. > > Are you suggesting we all start similar companies? Johan is a former > Oracle employee and probably has a well-established relationship with them > and access to knowledge that others don?t. Personally, I love what he?s > doing and hope Gluon expands rapidly to enable as much innovation as > possible. > > But what about the rest of us? What are we supposed to do? How do we get > large-scale changes to happen? > > Well, I don?t know. But we?re better as a team than a bunch of individuals > each trying to get some feature implemented in an uncoordinated fashion. > > The other real issue is that everyone seems to have their own perspective > on exactly what JavaFX is or should be. That makes the community > ineffective unless someone manages innovation for JavaFX in general. > > I?d be happy to be that person but sadly, it?s not for me to make that > call. Johan is like the de facto ?Head of Innovation for JavaFX? at the > moment but he has his own agenda (mainly in the mobile space) and monetises > his efforts. > > That?s what businesses do. > > So, I think we need to firstly establish just what JavaFX is *now* (even > this is not clear) and also what it *should be* (where we coalesce > everyone?s own ideas) so we can move forward. > > That is of course *if* JavaFX is actually going to ?move forward? rather > than ?sideways?. > > Honestly though, if you?re not moving forward, you are really going > backward as you watch the rest of the world disappear over the horizon... > > Graciously, > > John-Val Rose > > > On 22 Sep 2017, at 22:38, Nir Lisker wrote: > > > > I didn't see any update on the idea for our initiative. Are we still > waiting for a reply from Oracle or do we go with Johan Vos's experience? > > > > I think that the least we can do without putting any work into this is > have a semi-formal list of people who would like to work on this and a > list of what features we would be working on. I feel that I still don't > know the scope of what we are trying to do, only pieces of it. > From johnvalrose at gmail.com Sat Sep 23 00:19:54 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 23 Sep 2017 10:19:54 +1000 Subject: OpenJFX initiative In-Reply-To: References: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> Message-ID: Yes, well I'm sure there's a lot of truth to that as Johan has demonstrated. But, I think it's a bit of an over simplification. How do I know if *my* innovation (of say 9 months of effort) is "high-quality code that makes OpenJFX better"? I can do my best to write high-quality code but what exactly does "make OpenJFX better" mean? *I* might think it's better with WebGL and advanced 3D features but it seems most people disagree or are ambivalent towards such functionality. Who gets to say what does or doesn't get integrated? And, how do I know *before* I potentially waste my effort whether it will or won't "make OpenJFX better" or be integrated? ?? Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology Australia On 23 September 2017 at 09:08, Nir Lisker wrote: > > What do you mean by ?go with Johan Vos?s experience?? > > What he said here: http://mail.openjdk.java.net/pipermail/openjfx- > dev/2017-September/020801.html. > > On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose > wrote: > >> The concept of ?innovation? no longer seems to apply to JavaFX, at least >> not from Oracle?s perspective. >> >> If you read the official list of changes in the just-released Java 9, AWT >> (yes, AWT) has more changes than JavaFX and even then the only significant >> change is to make it Jigsaw compatible. >> >> A product like this needs a very clear ?roadmap? of development and >> introduction of new features but the link on the Oracle JavaFX >> Documentation page for ?roadmap? leads to a place known as ?404?. I hope >> that?s not a room number in ?Hotel California?. >> >> So, innovation for JavaFX falls back as a community responsibility but is >> very difficult without any cooperation from Oracle themselves. >> >> I personally have not been able to get any response from them except >> ?float your ideas on the mailing list to see what interest there is?. Note, >> that ?interest? is only from the community itself... and then what? >> >> What do you mean by ?go with Johan Vos?s experience?? Yes, he and Gluon >> are fantastic innovators and have built a small company of top-notch talent >> and are able to crank-out new products and enhancements with impressive >> frequency. >> >> Are you suggesting we all start similar companies? Johan is a former >> Oracle employee and probably has a well-established relationship with them >> and access to knowledge that others don?t. Personally, I love what he?s >> doing and hope Gluon expands rapidly to enable as much innovation as >> possible. >> >> But what about the rest of us? What are we supposed to do? How do we get >> large-scale changes to happen? >> >> Well, I don?t know. But we?re better as a team than a bunch of >> individuals each trying to get some feature implemented in an uncoordinated >> fashion. >> >> The other real issue is that everyone seems to have their own perspective >> on exactly what JavaFX is or should be. That makes the community >> ineffective unless someone manages innovation for JavaFX in general. >> >> I?d be happy to be that person but sadly, it?s not for me to make that >> call. Johan is like the de facto ?Head of Innovation for JavaFX? at the >> moment but he has his own agenda (mainly in the mobile space) and monetises >> his efforts. >> >> That?s what businesses do. >> >> So, I think we need to firstly establish just what JavaFX is *now* (even >> this is not clear) and also what it *should be* (where we coalesce >> everyone?s own ideas) so we can move forward. >> >> That is of course *if* JavaFX is actually going to ?move forward? rather >> than ?sideways?. >> >> Honestly though, if you?re not moving forward, you are really going >> backward as you watch the rest of the world disappear over the horizon... >> >> Graciously, >> >> John-Val Rose >> >> > On 22 Sep 2017, at 22:38, Nir Lisker wrote: >> > >> > I didn't see any update on the idea for our initiative. Are we still >> waiting for a reply from Oracle or do we go with Johan Vos's experience? >> > >> > I think that the least we can do without putting any work into this is >> have a semi-formal list of people who would like to work on this and a >> list of what features we would be working on. I feel that I still don't >> know the scope of what we are trying to do, only pieces of it. >> > > From nlisker at gmail.com Sat Sep 23 00:24:30 2017 From: nlisker at gmail.com (Nir Lisker) Date: Sat, 23 Sep 2017 03:24:30 +0300 Subject: OpenJFX initiative In-Reply-To: References: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> Message-ID: I don't have any answer to those questions. A JEP is the only thing I can think of. On Sat, Sep 23, 2017 at 3:19 AM, John-Val Rose wrote: > Yes, well I'm sure there's a lot of truth to that as Johan has > demonstrated. > > But, I think it's a bit of an over simplification. > > How do I know if *my* innovation (of say 9 months of effort) is "high-quality > code that makes OpenJFX better"? > > I can do my best to write high-quality code but what exactly does "make > OpenJFX better" mean? *I* might think it's better with WebGL and advanced > 3D features but it seems most people disagree or are ambivalent towards > such functionality. > > Who gets to say what does or doesn't get integrated? And, how do I know > *before* I potentially waste my effort whether it will or won't "make > OpenJFX better" or be integrated? > > ?? > Graciously, > > John-Val Rose > Chief Scientist/Architect > Rosethorn Technology > Australia > > On 23 September 2017 at 09:08, Nir Lisker wrote: > >> > What do you mean by ?go with Johan Vos?s experience?? >> >> What he said here: http://mail.openjdk.java.net/pipermail/openjfx-dev/ >> 2017-September/020801.html. >> >> On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose >> wrote: >> >>> The concept of ?innovation? no longer seems to apply to JavaFX, at least >>> not from Oracle?s perspective. >>> >>> If you read the official list of changes in the just-released Java 9, >>> AWT (yes, AWT) has more changes than JavaFX and even then the only >>> significant change is to make it Jigsaw compatible. >>> >>> A product like this needs a very clear ?roadmap? of development and >>> introduction of new features but the link on the Oracle JavaFX >>> Documentation page for ?roadmap? leads to a place known as ?404?. I hope >>> that?s not a room number in ?Hotel California?. >>> >>> So, innovation for JavaFX falls back as a community responsibility but >>> is very difficult without any cooperation from Oracle themselves. >>> >>> I personally have not been able to get any response from them except >>> ?float your ideas on the mailing list to see what interest there is?. Note, >>> that ?interest? is only from the community itself... and then what? >>> >>> What do you mean by ?go with Johan Vos?s experience?? Yes, he and Gluon >>> are fantastic innovators and have built a small company of top-notch talent >>> and are able to crank-out new products and enhancements with impressive >>> frequency. >>> >>> Are you suggesting we all start similar companies? Johan is a former >>> Oracle employee and probably has a well-established relationship with them >>> and access to knowledge that others don?t. Personally, I love what he?s >>> doing and hope Gluon expands rapidly to enable as much innovation as >>> possible. >>> >>> But what about the rest of us? What are we supposed to do? How do we get >>> large-scale changes to happen? >>> >>> Well, I don?t know. But we?re better as a team than a bunch of >>> individuals each trying to get some feature implemented in an uncoordinated >>> fashion. >>> >>> The other real issue is that everyone seems to have their own >>> perspective on exactly what JavaFX is or should be. That makes the >>> community ineffective unless someone manages innovation for JavaFX in >>> general. >>> >>> I?d be happy to be that person but sadly, it?s not for me to make that >>> call. Johan is like the de facto ?Head of Innovation for JavaFX? at the >>> moment but he has his own agenda (mainly in the mobile space) and monetises >>> his efforts. >>> >>> That?s what businesses do. >>> >>> So, I think we need to firstly establish just what JavaFX is *now* (even >>> this is not clear) and also what it *should be* (where we coalesce >>> everyone?s own ideas) so we can move forward. >>> >>> That is of course *if* JavaFX is actually going to ?move forward? rather >>> than ?sideways?. >>> >>> Honestly though, if you?re not moving forward, you are really going >>> backward as you watch the rest of the world disappear over the horizon... >>> >>> Graciously, >>> >>> John-Val Rose >>> >>> > On 22 Sep 2017, at 22:38, Nir Lisker wrote: >>> > >>> > I didn't see any update on the idea for our initiative. Are we still >>> waiting for a reply from Oracle or do we go with Johan Vos's experience? >>> > >>> > I think that the least we can do without putting any work into this is >>> have a semi-formal list of people who would like to work on this and a >>> list of what features we would be working on. I feel that I still don't >>> know the scope of what we are trying to do, only pieces of it. >>> >> >> > From johnvalrose at gmail.com Sat Sep 23 00:31:26 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sat, 23 Sep 2017 10:31:26 +1000 Subject: OpenJFX initiative In-Reply-To: References: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> Message-ID: Probably, but JEPs can take a lot of time from start to finish and time is itself perhaps the biggest enemy that JavaFX is facing. And how many JEPs are being initiated by the Oracle JavaFX team themselves? I mean for the specific purpose of *true* innovation? On 23 September 2017 at 10:24, Nir Lisker wrote: > I don't have any answer to those questions. A JEP is the only thing I can > think of. > > On Sat, Sep 23, 2017 at 3:19 AM, John-Val Rose > wrote: > >> Yes, well I'm sure there's a lot of truth to that as Johan has >> demonstrated. >> >> But, I think it's a bit of an over simplification. >> >> How do I know if *my* innovation (of say 9 months of effort) is "high-quality >> code that makes OpenJFX better"? >> >> I can do my best to write high-quality code but what exactly does "make >> OpenJFX better" mean? *I* might think it's better with WebGL and advanced >> 3D features but it seems most people disagree or are ambivalent towards >> such functionality. >> >> Who gets to say what does or doesn't get integrated? And, how do I know >> *before* I potentially waste my effort whether it will or won't "make >> OpenJFX better" or be integrated? >> >> ?? >> Graciously, >> >> John-Val Rose >> Chief Scientist/Architect >> Rosethorn Technology >> Australia >> >> On 23 September 2017 at 09:08, Nir Lisker wrote: >> >>> > What do you mean by ?go with Johan Vos?s experience?? >>> >>> What he said here: http://mail.openjdk.java >>> .net/pipermail/openjfx-dev/2017-September/020801.html. >>> >>> On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose >>> wrote: >>> >>>> The concept of ?innovation? no longer seems to apply to JavaFX, at >>>> least not from Oracle?s perspective. >>>> >>>> If you read the official list of changes in the just-released Java 9, >>>> AWT (yes, AWT) has more changes than JavaFX and even then the only >>>> significant change is to make it Jigsaw compatible. >>>> >>>> A product like this needs a very clear ?roadmap? of development and >>>> introduction of new features but the link on the Oracle JavaFX >>>> Documentation page for ?roadmap? leads to a place known as ?404?. I hope >>>> that?s not a room number in ?Hotel California?. >>>> >>>> So, innovation for JavaFX falls back as a community responsibility but >>>> is very difficult without any cooperation from Oracle themselves. >>>> >>>> I personally have not been able to get any response from them except >>>> ?float your ideas on the mailing list to see what interest there is?. Note, >>>> that ?interest? is only from the community itself... and then what? >>>> >>>> What do you mean by ?go with Johan Vos?s experience?? Yes, he and Gluon >>>> are fantastic innovators and have built a small company of top-notch talent >>>> and are able to crank-out new products and enhancements with impressive >>>> frequency. >>>> >>>> Are you suggesting we all start similar companies? Johan is a former >>>> Oracle employee and probably has a well-established relationship with them >>>> and access to knowledge that others don?t. Personally, I love what he?s >>>> doing and hope Gluon expands rapidly to enable as much innovation as >>>> possible. >>>> >>>> But what about the rest of us? What are we supposed to do? How do we >>>> get large-scale changes to happen? >>>> >>>> Well, I don?t know. But we?re better as a team than a bunch of >>>> individuals each trying to get some feature implemented in an uncoordinated >>>> fashion. >>>> >>>> The other real issue is that everyone seems to have their own >>>> perspective on exactly what JavaFX is or should be. That makes the >>>> community ineffective unless someone manages innovation for JavaFX in >>>> general. >>>> >>>> I?d be happy to be that person but sadly, it?s not for me to make that >>>> call. Johan is like the de facto ?Head of Innovation for JavaFX? at the >>>> moment but he has his own agenda (mainly in the mobile space) and monetises >>>> his efforts. >>>> >>>> That?s what businesses do. >>>> >>>> So, I think we need to firstly establish just what JavaFX is *now* >>>> (even this is not clear) and also what it *should be* (where we coalesce >>>> everyone?s own ideas) so we can move forward. >>>> >>>> That is of course *if* JavaFX is actually going to ?move forward? >>>> rather than ?sideways?. >>>> >>>> Honestly though, if you?re not moving forward, you are really going >>>> backward as you watch the rest of the world disappear over the horizon... >>>> >>>> Graciously, >>>> >>>> John-Val Rose >>>> >>>> > On 22 Sep 2017, at 22:38, Nir Lisker wrote: >>>> > >>>> > I didn't see any update on the idea for our initiative. Are we still >>>> waiting for a reply from Oracle or do we go with Johan Vos's experience? >>>> > >>>> > I think that the least we can do without putting any work into this >>>> is have a semi-formal list of people who would like to work on this and a >>>> list of what features we would be working on. I feel that I still don't >>>> know the scope of what we are trying to do, only pieces of it. >>>> >>> >>> >> > From Sergey.Bylokhov at oracle.com Sat Sep 23 02:22:24 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 22 Sep 2017 19:22:24 -0700 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: References: Message-ID: <98abeab4-f831-a724-dae0-6745df63dfc0@oracle.com> Hi, Prasanta. On 9/19/17 22:26, Prasanta Sadhukhan wrote: >> Hi, Prasanta. >> ?- In this version it is unclear what is a purpose of the >> "fxCheckSequenceThread.start()". This code will start the thread and >> will continue execution, it will not wait when the thread will stop. >> ?- The DefaultKeyboardFocusManager also should check for >> "javafx.embed.singleThread" >> > Please find modified webrev catering to both comments > http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/ The new code in DefaultKeyboardFocusManager also will not wait when the thread will stop. > > Regards > Prasanta >> >> On 9/13/17 03:11, Prasanta Sadhukhan wrote: >>> Hi Sergey, >>> >>> I have modified the fix to not use SecondaryLoop and not to create >>> one thread per dispatch >>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/ >>> >>> Regards >>> Prasanta >>> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote: >>>> Hi, Prasanta. >>>> Can you please provide some description on how the SecondaryLoop >>>> will work when it will run on Appkit thread? Is it possible to get a >>>> deadlock here, since appkit will be blocked? >>>> >>>>> sequence, ie if the event is not first in sequence, then it will made >>>>> to >>>>> wait till it is the first event or till it is disposed. >>>> Note that the new code (unlike lines 139-150) also waits 1 second, >>>> so we can get a situation when only one event will be dispatched per >>>> second, which is not we want to do. >>>> I am not sure how often we create SequencedEvent but creating one >>>> thread per dispatch look inefficient. >>>> >>>> >>>>> Modified webrev >>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote: >>>>>> Hi, Prasanta. >>>>>> >>>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote: >>>>>>> Now, since here FX App thread itself is the dispatch thread, we can >>>>>>> be sure the events are dispatched in sequence and dispose is >>>>> checked >>>>>>> below after EDT. >>>>>> Why we can sure about this? If the SequencedEvents were created in >>>>> one >>>>>> order but dispatch() for each were called in other order then the >>>>>> sequenced will not be preserved? >>>>>> >>>>>>> I have tested with couple of singleThread testcase without any >>>>> issue. >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: >>>>>>>> Hi, Prasanta, Kevin. >>>>>>>> >>>>>>>> I have two notes. >>>>>>>> ?? - Does this option is really supported? If it is supported we >>>>>>>> should evaluate all usage of EventDispatchThread because in this >>>>>>>> mode the dispatch thread is not EDT. For example I am not sure >>>>> that >>>>>>>> we can skip the code which expects EventDispatchThread. >>>>>>>> ?? - We have the similar pattern: "EventQueue.isDispatchThread() -> >>>>>>>> cast(EventDispatchThread)" in some other places like in >>>>>>>> DefaultKeyboardFocusManager. >>>>>>>> >>>>>>>> -----prasanta.sadhukhan at oracle.com? wrote: >>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Please review this fix >>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >>>>>>>>> for an fx issue >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132 >>>>>>>>> >>>>>>>>> More info in JBS. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>> >>> >> >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Sep 23 02:31:35 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 22 Sep 2017 19:31:35 -0700 Subject: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> Message-ID: <7c868789-6c1e-28c9-af7a-057d551e0dfe@oracle.com> Hi, Alexander. How can we be sure that the parent frame will not be disposed while we use a pointer? long ownerWindowPtr = peer.getOverridenWindowHandle(); <<<<< Dispose the peer if (ownerWindowPtr != 0) { //Place window above JavaFX stage CWrapper.NSWindow.addChildWindow( ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove); <<<<< Boom } On 9/21/17 22:56, Alexander Zvegintsev wrote: > Hi Phil, > > Please review the updated fix with reflection incorporated > http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ > > New issue created JDK-8187803 > as JDK counterpart of > this issue. > > Thanks, > Alexander. > > On 21/09/2017 22:25, Phil Race wrote: >> Some procedural comments : >> Since 90% of this is in AWT code, I'd have thought awt-dev should be >> included here. >> I've added that list. >> >> And apart from needing separate bug ids, I don't see why the bug below >> is confidential. >> >> >> I agree with what Kevin pointed out off-line that as in the dialog >> case, the FX side >> of the code can use reflection and simply be a harmless non-functional >> no-op >> if the SwingAccessor does not provide the new method. >> >> BTW >> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } >> should be "dd" not "d". >> >> -phil. >> >> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: >>> Hello, >>> >>> please review the fix >>> >>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ >>> >>> for the issue >>> >>> https://bugs.openjdk.java.net/browse/JDK-8185634 >>> >> > -- Best regards, Sergey. From prasanta.sadhukhan at oracle.com Sat Sep 23 07:03:32 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 23 Sep 2017 12:33:32 +0530 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: <98abeab4-f831-a724-dae0-6745df63dfc0@oracle.com> References: <98abeab4-f831-a724-dae0-6745df63dfc0@oracle.com> Message-ID: <2df0d688-5111-3320-d287-d3500dd3ffaa@oracle.com> Hi Sergey, Please find modified webrev catering to DefaultKeyboardFocusManager also http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.05/ Regards Prasanta On 9/23/2017 7:52 AM, Sergey Bylokhov wrote: > Hi, Prasanta. > > On 9/19/17 22:26, Prasanta Sadhukhan wrote: >>> Hi, Prasanta. >>> ?- In this version it is unclear what is a purpose of the >>> "fxCheckSequenceThread.start()". This code will start the thread and >>> will continue execution, it will not wait when the thread will stop. >>> ?- The DefaultKeyboardFocusManager also should check for >>> "javafx.embed.singleThread" >>> >> Please find modified webrev catering to both comments >> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/ > > The new code in DefaultKeyboardFocusManager also will not wait when > the thread will stop. > >> >> Regards >> Prasanta >>> >>> On 9/13/17 03:11, Prasanta Sadhukhan wrote: >>>> Hi Sergey, >>>> >>>> I have modified the fix to not use SecondaryLoop and not to create >>>> one thread per dispatch >>>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/ >>>> >>>> Regards >>>> Prasanta >>>> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote: >>>>> Hi, Prasanta. >>>>> Can you please provide some description on how the SecondaryLoop >>>>> will work when it will run on Appkit thread? Is it possible to get >>>>> a deadlock here, since appkit will be blocked? >>>>> >>>>>> sequence, ie if the event is not first in sequence, then it will >>>>>> made >>>>>> to >>>>>> wait till it is the first event or till it is disposed. >>>>> Note that the new code (unlike lines 139-150) also waits 1 second, >>>>> so we can get a situation when only one event will be dispatched >>>>> per second, which is not we want to do. >>>>> I am not sure how often we create SequencedEvent but creating one >>>>> thread per dispatch look inefficient. >>>>> >>>>> >>>>>> Modified webrev >>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/ >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Prasanta. >>>>>>> >>>>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote: >>>>>>>> Now, since here FX App thread itself is the dispatch thread, we >>>>>>>> can >>>>>>>> be sure the events are dispatched in sequence and dispose is >>>>>> checked >>>>>>>> below after EDT. >>>>>>> Why we can sure about this? If the SequencedEvents were created in >>>>>> one >>>>>>> order but dispatch() for each were called in other order then the >>>>>>> sequenced will not be preserved? >>>>>>> >>>>>>>> I have tested with couple of singleThread testcase without any >>>>>> issue. >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: >>>>>>>>> Hi, Prasanta, Kevin. >>>>>>>>> >>>>>>>>> I have two notes. >>>>>>>>> ?? - Does this option is really supported? If it is supported we >>>>>>>>> should evaluate all usage of EventDispatchThread because in this >>>>>>>>> mode the dispatch thread is not EDT. For example I am not sure >>>>>> that >>>>>>>>> we can skip the code which expects EventDispatchThread. >>>>>>>>> ?? - We have the similar pattern: >>>>>>>>> "EventQueue.isDispatchThread() -> >>>>>>>>> cast(EventDispatchThread)" in some other places like in >>>>>>>>> DefaultKeyboardFocusManager. >>>>>>>>> >>>>>>>>> -----prasanta.sadhukhan at oracle.com? wrote: >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Please review this fix >>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >>>>>>>>>> for an fx issue >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132 >>>>>>>>>> >>>>>>>>>> More info in JBS. >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> Prasanta >>>>>>> >>>> >>> >>> >> > > From phidias51 at gmail.com Sat Sep 23 14:14:15 2017 From: phidias51 at gmail.com (Mark Fortner) Date: Sat, 23 Sep 2017 07:14:15 -0700 Subject: OpenJFX initiative In-Reply-To: References: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> Message-ID: I must have missed the bit where you described a proposed roadmap. I think for the most part I've seen JavaFX used as a means of keeping older Swing-based projects alive. In the enterprise, those projects are dwindling, in part because people just rebuild them as web applications. It's easier to find that kind of talent, than it is to find desktop developers. The applications that remain desktop applications tend to require either access to your desktop OS, or need near realtime access to streams of audio, video, telemetry or financial data, which makes them ill-suited to be web apps. The reason that there's little interest in WebGL or 3d is because it doesn't fit into one of the enterprise app buckets listed above. I'm still surprised when people tell me that they have to write mobile apps in Java and Swift and maintain two codebases, and when I point them to JavaFX they admit they've never heard of it. There needs to be better promotion of JavaFX in the Java developer community. People need to compare the degree of complexity of web component and PWA development against JavaFX to see the advantages. And there needs to be a better deployment story than web start. A lot of that is simply promotion. It means reaching out to web development and mobile development communities, and giving talks and demos. Mark On 22 Sep 2017 5:32 p.m., "John-Val Rose" wrote: Probably, but JEPs can take a lot of time from start to finish and time is itself perhaps the biggest enemy that JavaFX is facing. And how many JEPs are being initiated by the Oracle JavaFX team themselves? I mean for the specific purpose of *true* innovation? On 23 September 2017 at 10:24, Nir Lisker wrote: > I don't have any answer to those questions. A JEP is the only thing I can > think of. > > On Sat, Sep 23, 2017 at 3:19 AM, John-Val Rose > wrote: > >> Yes, well I'm sure there's a lot of truth to that as Johan has >> demonstrated. >> >> But, I think it's a bit of an over simplification. >> >> How do I know if *my* innovation (of say 9 months of effort) is "high-quality >> code that makes OpenJFX better"? >> >> I can do my best to write high-quality code but what exactly does "make >> OpenJFX better" mean? *I* might think it's better with WebGL and advanced >> 3D features but it seems most people disagree or are ambivalent towards >> such functionality. >> >> Who gets to say what does or doesn't get integrated? And, how do I know >> *before* I potentially waste my effort whether it will or won't "make >> OpenJFX better" or be integrated? >> >> ?? >> Graciously, >> >> John-Val Rose >> Chief Scientist/Architect >> Rosethorn Technology >> Australia >> >> On 23 September 2017 at 09:08, Nir Lisker wrote: >> >>> > What do you mean by ?go with Johan Vos?s experience?? >>> >>> What he said here: http://mail.openjdk.java >>> .net/pipermail/openjfx-dev/2017-September/020801.html. >>> >>> On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose >>> wrote: >>> >>>> The concept of ?innovation? no longer seems to apply to JavaFX, at >>>> least not from Oracle?s perspective. >>>> >>>> If you read the official list of changes in the just-released Java 9, >>>> AWT (yes, AWT) has more changes than JavaFX and even then the only >>>> significant change is to make it Jigsaw compatible. >>>> >>>> A product like this needs a very clear ?roadmap? of development and >>>> introduction of new features but the link on the Oracle JavaFX >>>> Documentation page for ?roadmap? leads to a place known as ?404?. I hope >>>> that?s not a room number in ?Hotel California?. >>>> >>>> So, innovation for JavaFX falls back as a community responsibility but >>>> is very difficult without any cooperation from Oracle themselves. >>>> >>>> I personally have not been able to get any response from them except >>>> ?float your ideas on the mailing list to see what interest there is?. Note, >>>> that ?interest? is only from the community itself... and then what? >>>> >>>> What do you mean by ?go with Johan Vos?s experience?? Yes, he and Gluon >>>> are fantastic innovators and have built a small company of top-notch talent >>>> and are able to crank-out new products and enhancements with impressive >>>> frequency. >>>> >>>> Are you suggesting we all start similar companies? Johan is a former >>>> Oracle employee and probably has a well-established relationship with them >>>> and access to knowledge that others don?t. Personally, I love what he?s >>>> doing and hope Gluon expands rapidly to enable as much innovation as >>>> possible. >>>> >>>> But what about the rest of us? What are we supposed to do? How do we >>>> get large-scale changes to happen? >>>> >>>> Well, I don?t know. But we?re better as a team than a bunch of >>>> individuals each trying to get some feature implemented in an uncoordinated >>>> fashion. >>>> >>>> The other real issue is that everyone seems to have their own >>>> perspective on exactly what JavaFX is or should be. That makes the >>>> community ineffective unless someone manages innovation for JavaFX in >>>> general. >>>> >>>> I?d be happy to be that person but sadly, it?s not for me to make that >>>> call. Johan is like the de facto ?Head of Innovation for JavaFX? at the >>>> moment but he has his own agenda (mainly in the mobile space) and monetises >>>> his efforts. >>>> >>>> That?s what businesses do. >>>> >>>> So, I think we need to firstly establish just what JavaFX is *now* >>>> (even this is not clear) and also what it *should be* (where we coalesce >>>> everyone?s own ideas) so we can move forward. >>>> >>>> That is of course *if* JavaFX is actually going to ?move forward? >>>> rather than ?sideways?. >>>> >>>> Honestly though, if you?re not moving forward, you are really going >>>> backward as you watch the rest of the world disappear over the horizon... >>>> >>>> Graciously, >>>> >>>> John-Val Rose >>>> >>>> > On 22 Sep 2017, at 22:38, Nir Lisker wrote: >>>> > >>>> > I didn't see any update on the idea for our initiative. Are we still >>>> waiting for a reply from Oracle or do we go with Johan Vos's experience? >>>> > >>>> > I think that the least we can do without putting any work into this >>>> is have a semi-formal list of people who would like to work on this and a >>>> list of what features we would be working on. I feel that I still don't >>>> know the scope of what we are trying to do, only pieces of it. >>>> >>> >>> >> > From dmitry.markov at oracle.com Sat Sep 23 15:51:04 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Sat, 23 Sep 2017 16:51:04 +0100 Subject: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> Message-ID: Hi Alexander, In CPlatformWindow class you call CWrapper.NSWindow.addChildWindow() to place a window above JavaFX stage. The usage of addChilWindow() or/and removeChildWindow() may cause ?jumping window issue? in multi-monitor environment, see JDK-8080729 for more details. To avoid possible problems in multi monitor set-up I suggest that you should replace addChildWindow() with orderWindow() or use some another approach to locate the window above the stage. Thanks, Dmitry > On 22 Sep 2017, at 06:56, Alexander Zvegintsev wrote: > > Hi Phil, > > Please review the updated fix with reflection incorporated > http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ > > New issue created JDK-8187803 as JDK counterpart of this issue. > > Thanks, > Alexander. > > On 21/09/2017 22:25, Phil Race wrote: >> Some procedural comments : >> Since 90% of this is in AWT code, I'd have thought awt-dev should be included here. >> I've added that list. >> >> And apart from needing separate bug ids, I don't see why the bug below is confidential. >> >> >> I agree with what Kevin pointed out off-line that as in the dialog case, the FX side >> of the code can use reflection and simply be a harmless non-functional no-op >> if the SwingAccessor does not provide the new method. >> >> BTW >> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } >> should be "dd" not "d". >> >> -phil. >> >> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: >>> Hello, >>> >>> please review the fix >>> >>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ >>> >>> for the issue >>> >>> https://bugs.openjdk.java.net/browse/JDK-8185634 >>> >> > From johnvalrose at gmail.com Sun Sep 24 10:39:20 2017 From: johnvalrose at gmail.com (John-Val Rose) Date: Sun, 24 Sep 2017 20:39:20 +1000 Subject: OpenJFX initiative In-Reply-To: References: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> Message-ID: Hi Mark, I didn't actually "describe a proposed roadmap"; I merely questioned why there doesn't appear to be one. What does that mean? Well, it could mean that one exists but that Oracle prefers to not make it public. It could mean that their still developing one. Or it could mean that the roadmap is an "all roads lead to Rome" scenario where "Rome" is a euphemism for obsolescence. If you look back the other way, i.e. the path travelled so far, you see that there was one major change in the architecture of JavaFX between versions 1 and 2. Then they went straight to 8 (when they decided to align the version numbers with JDK versions) but the changes were not really that significant. Sure, they introduced *some* 3D features which are now basically frozen and a couple of new controls etc. but mostly JavaFX 8 was better than 2 because we got to use all the nifty new Java 8 language features like lambdas and streams. Then, if you look at JavaFX 9, it seems to be little more than a "jigsawed" version of Java 8. Now, look more closely at the time elapsed from JavaFX 2 to 9 and you discover that between 2011 and 2017, there has been extremely limited innovation and no significant changes or major new features. Quite frankly, I have never seen a product of this kind evolve so slowly. Further, given that JavaFX entered the market and commenced it's slow evolutionary path years (if not decades) behind established competitors, this is the real *main* issue with JavaFX: it can't compete with something like Qt on *any* basis including features, cross-platform support, performance, professional support or user base, and that "gap" widens every day. (Forget about the web and HTML5. They/it are not a competitor to JavaFX). So, as for you idea about "promotion" of JavaFX, you must factor in that if you are trying to sell a product on the basis of any of the factors I just mentioned, then Qt (and others like Xamarin) will trump JavaFX on every one of them. Further, both Qt and Xamarin (now owned and heavily financed by Microsoft) have large companies behind them that actually generate revenue from them (which is a GOOD thing because it ensures their survival and enables rapid innovation). Also, it is yet to be seen if JavaFX is even viable on mobile/tablet platforms. We will only know when Gluon release their Gluon VM. So, it's probably not wise to go around now promoting what is (at least right now) still basically "vapourware". (N.B. I *do* have full confidence in Johan Vos and Gluon to deliver on their promise of a "blisteringly fast Java experience on iOS and Android" - I just need to get my hands on it, as do all JavaFX developers). As for me, well, all I want to do is contribute whatever I can to improve JavaFX. My comments are not meant as an "attack" on JavaFX (which is actually something I love), but more a shot of reality and a "battle cry". It's not too late for JavaFX but a lot of things need to change and change soon for it be viable long term. We have a vibrant community and I believe we need a mechanism to coordinate all the passion and talent into an army of JavaFX soldiers, all with the unified vision to "make JavaFX great again" (only without the fake news, alternate facts, rhetoric, gaffes and, of course... no comb-overs). Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology Australia On 24 September 2017 at 00:14, Mark Fortner wrote: > I must have missed the bit where you described a proposed roadmap. > > I think for the most part I've seen JavaFX used as a means of keeping > older Swing-based projects alive. In the enterprise, those projects are > dwindling, in part because people just rebuild them as web applications. > It's easier to find that kind of talent, than it is to find desktop > developers. > > The applications that remain desktop applications tend to require either > access to your desktop OS, or need near realtime access to streams of > audio, video, telemetry or financial data, which makes them ill-suited to > be web apps. > > The reason that there's little interest in WebGL or 3d is because it > doesn't fit into one of the enterprise app buckets listed above. > > I'm still surprised when people tell me that they have to write mobile > apps in Java and Swift and maintain two codebases, and when I point them to > JavaFX they admit they've never heard of it. > > There needs to be better promotion of JavaFX in the Java developer > community. People need to compare the degree of complexity of web component > and PWA development against JavaFX to see the advantages. And there needs > to be a better deployment story than web start. > > A lot of that is simply promotion. It means reaching out to web > development and mobile development communities, and giving talks and demos. > > Mark > > > On 22 Sep 2017 5:32 p.m., "John-Val Rose" wrote: > > Probably, but JEPs can take a lot of time from start to finish and time is > itself perhaps the biggest enemy that JavaFX is facing. > > And how many JEPs are being initiated by the Oracle JavaFX team > themselves? I mean for the specific purpose of *true* innovation? > > On 23 September 2017 at 10:24, Nir Lisker wrote: > > > I don't have any answer to those questions. A JEP is the only thing I can > > think of. > > > > On Sat, Sep 23, 2017 at 3:19 AM, John-Val Rose > > wrote: > > > >> Yes, well I'm sure there's a lot of truth to that as Johan has > >> demonstrated. > >> > >> But, I think it's a bit of an over simplification. > >> > >> How do I know if *my* innovation (of say 9 months of effort) is > "high-quality > >> code that makes OpenJFX better"? > >> > >> I can do my best to write high-quality code but what exactly does "make > >> OpenJFX better" mean? *I* might think it's better with WebGL and > advanced > >> 3D features but it seems most people disagree or are ambivalent towards > >> such functionality. > >> > >> Who gets to say what does or doesn't get integrated? And, how do I know > >> *before* I potentially waste my effort whether it will or won't "make > >> OpenJFX better" or be integrated? > >> > >> ?? > >> Graciously, > >> > >> John-Val Rose > >> Chief Scientist/Architect > >> Rosethorn Technology > >> Australia > >> > >> On 23 September 2017 at 09:08, Nir Lisker wrote: > >> > >>> > What do you mean by ?go with Johan Vos?s experience?? > >>> > >>> What he said here: http://mail.openjdk.java > >>> .net/pipermail/openjfx-dev/2017-September/020801.html. > >>> > >>> On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose > > >>> wrote: > >>> > >>>> The concept of ?innovation? no longer seems to apply to JavaFX, at > >>>> least not from Oracle?s perspective. > >>>> > >>>> If you read the official list of changes in the just-released Java 9, > >>>> AWT (yes, AWT) has more changes than JavaFX and even then the only > >>>> significant change is to make it Jigsaw compatible. > >>>> > >>>> A product like this needs a very clear ?roadmap? of development and > >>>> introduction of new features but the link on the Oracle JavaFX > >>>> Documentation page for ?roadmap? leads to a place known as ?404?. I > hope > >>>> that?s not a room number in ?Hotel California?. > >>>> > >>>> So, innovation for JavaFX falls back as a community responsibility but > >>>> is very difficult without any cooperation from Oracle themselves. > >>>> > >>>> I personally have not been able to get any response from them except > >>>> ?float your ideas on the mailing list to see what interest there is?. > Note, > >>>> that ?interest? is only from the community itself... and then what? > >>>> > >>>> What do you mean by ?go with Johan Vos?s experience?? Yes, he and > Gluon > >>>> are fantastic innovators and have built a small company of top-notch > talent > >>>> and are able to crank-out new products and enhancements with > impressive > >>>> frequency. > >>>> > >>>> Are you suggesting we all start similar companies? Johan is a former > >>>> Oracle employee and probably has a well-established relationship with > them > >>>> and access to knowledge that others don?t. Personally, I love what > he?s > >>>> doing and hope Gluon expands rapidly to enable as much innovation as > >>>> possible. > >>>> > >>>> But what about the rest of us? What are we supposed to do? How do we > >>>> get large-scale changes to happen? > >>>> > >>>> Well, I don?t know. But we?re better as a team than a bunch of > >>>> individuals each trying to get some feature implemented in an > uncoordinated > >>>> fashion. > >>>> > >>>> The other real issue is that everyone seems to have their own > >>>> perspective on exactly what JavaFX is or should be. That makes the > >>>> community ineffective unless someone manages innovation for JavaFX in > >>>> general. > >>>> > >>>> I?d be happy to be that person but sadly, it?s not for me to make that > >>>> call. Johan is like the de facto ?Head of Innovation for JavaFX? at > the > >>>> moment but he has his own agenda (mainly in the mobile space) and > monetises > >>>> his efforts. > >>>> > >>>> That?s what businesses do. > >>>> > >>>> So, I think we need to firstly establish just what JavaFX is *now* > >>>> (even this is not clear) and also what it *should be* (where we > coalesce > >>>> everyone?s own ideas) so we can move forward. > >>>> > >>>> That is of course *if* JavaFX is actually going to ?move forward? > >>>> rather than ?sideways?. > >>>> > >>>> Honestly though, if you?re not moving forward, you are really going > >>>> backward as you watch the rest of the world disappear over the > horizon... > >>>> > >>>> Graciously, > >>>> > >>>> John-Val Rose > >>>> > >>>> > On 22 Sep 2017, at 22:38, Nir Lisker wrote: > >>>> > > >>>> > I didn't see any update on the idea for our initiative. Are we still > >>>> waiting for a reply from Oracle or do we go with Johan Vos's > experience? > >>>> > > >>>> > I think that the least we can do without putting any work into this > >>>> is have a semi-formal list of people who would like to work on this > and a > >>>> list of what features we would be working on. I feel that I still > don't > >>>> know the scope of what we are trying to do, only pieces of it. > >>>> > >>> > >>> > >> > > > > > From Thorsten_Fischer at gmx.de Sun Sep 24 11:39:43 2017 From: Thorsten_Fischer at gmx.de (Thorsten Fischer) Date: Sun, 24 Sep 2017 13:39:43 +0200 Subject: AW: OpenJFX initiative In-Reply-To: References: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> Message-ID: <0M2tKM-1d3ZhO2EJ4-00scwF@mail.gmx.com> +1 I?d too like to see some (coordinated) movement in the JavaFX area. Greetings & have a nice weekend, Thorsten Von: John-Val Rose Gesendet: Sonntag, 24. September 2017 12:43 An: Mark Fortner Cc: Nir Lisker; openjfx-dev at openjdk.java.net Mailing Betreff: Re: OpenJFX initiative Hi Mark, I didn't actually "describe a proposed roadmap"; I merely questioned why there doesn't appear to be one. What does that mean? Well, it could mean that one exists but that Oracle prefers to not make it public. It could mean that their still developing one. Or it could mean that the roadmap is an "all roads lead to Rome" scenario where "Rome" is a euphemism for obsolescence. If you look back the other way, i.e. the path travelled so far, you see that there was one major change in the architecture of JavaFX between versions 1 and 2. Then they went straight to 8 (when they decided to align the version numbers with JDK versions) but the changes were not really that significant. Sure, they introduced *some* 3D features which are now basically frozen and a couple of new controls etc. but mostly JavaFX 8 was better than 2 because we got to use all the nifty new Java 8 language features like lambdas and streams. Then, if you look at JavaFX 9, it seems to be little more than a "jigsawed" version of Java 8. Now, look more closely at the time elapsed from JavaFX 2 to 9 and you discover that between 2011 and 2017, there has been extremely limited innovation and no significant changes or major new features. Quite frankly, I have never seen a product of this kind evolve so slowly. Further, given that JavaFX entered the market and commenced it's slow evolutionary path years (if not decades) behind established competitors, this is the real *main* issue with JavaFX: it can't compete with something like Qt on *any* basis including features, cross-platform support, performance, professional support or user base, and that "gap" widens every day. (Forget about the web and HTML5. They/it are not a competitor to JavaFX). So, as for you idea about "promotion" of JavaFX, you must factor in that if you are trying to sell a product on the basis of any of the factors I just mentioned, then Qt (and others like Xamarin) will trump JavaFX on every one of them. Further, both Qt and Xamarin (now owned and heavily financed by Microsoft) have large companies behind them that actually generate revenue from them (which is a GOOD thing because it ensures their survival and enables rapid innovation). Also, it is yet to be seen if JavaFX is even viable on mobile/tablet platforms. We will only know when Gluon release their Gluon VM. So, it's probably not wise to go around now promoting what is (at least right now) still basically "vapourware". (N.B. I *do* have full confidence in Johan Vos and Gluon to deliver on their promise of a "blisteringly fast Java experience on iOS and Android" - I just need to get my hands on it, as do all JavaFX developers). As for me, well, all I want to do is contribute whatever I can to improve JavaFX. My comments are not meant as an "attack" on JavaFX (which is actually something I love), but more a shot of reality and a "battle cry". It's not too late for JavaFX but a lot of things need to change and change soon for it be viable long term. We have a vibrant community and I believe we need a mechanism to coordinate all the passion and talent into an army of JavaFX soldiers, all with the unified vision to "make JavaFX great again" (only without the fake news, alternate facts, rhetoric, gaffes and, of course... no comb-overs). Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology Australia On 24 September 2017 at 00:14, Mark Fortner wrote: > I must have missed the bit where you described a proposed roadmap. > > I think for the most part I've seen JavaFX used as a means of keeping > older Swing-based projects alive. In the enterprise, those projects are > dwindling, in part because people just rebuild them as web applications. > It's easier to find that kind of talent, than it is to find desktop > developers. > > The applications that remain desktop applications tend to require either > access to your desktop OS, or need near realtime access to streams of > audio, video, telemetry or financial data, which makes them ill-suited to > be web apps. > > The reason that there's little interest in WebGL or 3d is because it > doesn't fit into one of the enterprise app buckets listed above. > > I'm still surprised when people tell me that they have to write mobile > apps in Java and Swift and maintain two codebases, and when I point them to > JavaFX they admit they've never heard of it. > > There needs to be better promotion of JavaFX in the Java developer > community. People need to compare the degree of complexity of web component > and PWA development against JavaFX to see the advantages. And there needs > to be a better deployment story than web start. > > A lot of that is simply promotion. It means reaching out to web > development and mobile development communities, and giving talks and demos. > > Mark > > > On 22 Sep 2017 5:32 p.m., "John-Val Rose" wrote: > > Probably, but JEPs can take a lot of time from start to finish and time is > itself perhaps the biggest enemy that JavaFX is facing. > > And how many JEPs are being initiated by the Oracle JavaFX team > themselves? I mean for the specific purpose of *true* innovation? > > On 23 September 2017 at 10:24, Nir Lisker wrote: > > > I don't have any answer to those questions. A JEP is the only thing I can > > think of. > > > > On Sat, Sep 23, 2017 at 3:19 AM, John-Val Rose > > wrote: > > > >> Yes, well I'm sure there's a lot of truth to that as Johan has > >> demonstrated. > >> > >> But, I think it's a bit of an over simplification. > >> > >> How do I know if *my* innovation (of say 9 months of effort) is > "high-quality > >> code that makes OpenJFX better"? > >> > >> I can do my best to write high-quality code but what exactly does "make > >> OpenJFX better" mean? *I* might think it's better with WebGL and > advanced > >> 3D features but it seems most people disagree or are ambivalent towards > >> such functionality. > >> > >> Who gets to say what does or doesn't get integrated? And, how do I know > >> *before* I potentially waste my effort whether it will or won't "make > >> OpenJFX better" or be integrated? > >> > >> ?? > >> Graciously, > >> > >> John-Val Rose > >> Chief Scientist/Architect > >> Rosethorn Technology > >> Australia > >> > >> On 23 September 2017 at 09:08, Nir Lisker wrote: > >> > >>> > What do you mean by ?go with Johan Vos?s experience?? > >>> > >>> What he said here: http://mail.openjdk.java > >>> .net/pipermail/openjfx-dev/2017-September/020801.html. > >>> > >>> On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose > > >>> wrote: > >>> > >>>> The concept of ?innovation? no longer seems to apply to JavaFX, at > >>>> least not from Oracle?s perspective. > >>>> > >>>> If you read the official list of changes in the just-released Java 9, > >>>> AWT (yes, AWT) has more changes than JavaFX and even then the only > >>>> significant change is to make it Jigsaw compatible. > >>>> > >>>> A product like this needs a very clear ?roadmap? of development and > >>>> introduction of new features but the link on the Oracle JavaFX > >>>> Documentation page for ?roadmap? leads to a place known as ?404?. I > hope > >>>> that?s not a room number in ?Hotel California?. > >>>> > >>>> So, innovation for JavaFX falls back as a community responsibility but > >>>> is very difficult without any cooperation from Oracle themselves. > >>>> > >>>> I personally have not been able to get any response from them except > >>>> ?float your ideas on the mailing list to see what interest there is?. > Note, > >>>> that ?interest? is only from the community itself... and then what? > >>>> > >>>> What do you mean by ?go with Johan Vos?s experience?? Yes, he and > Gluon > >>>> are fantastic innovators and have built a small company of top-notch > talent > >>>> and are able to crank-out new products and enhancements with > impressive > >>>> frequency. > >>>> > >>>> Are you suggesting we all start similar companies? Johan is a former > >>>> Oracle employee and probably has a well-established relationship with > them > >>>> and access to knowledge that others don?t. Personally, I love what > he?s > >>>> doing and hope Gluon expands rapidly to enable as much innovation as > >>>> possible. > >>>> > >>>> But what about the rest of us? What are we supposed to do? How do we > >>>> get large-scale changes to happen? > >>>> > >>>> Well, I don?t know. But we?re better as a team than a bunch of > >>>> individuals each trying to get some feature implemented in an > uncoordinated > >>>> fashion. > >>>> > >>>> The other real issue is that everyone seems to have their own > >>>> perspective on exactly what JavaFX is or should be. That makes the > >>>> community ineffective unless someone manages innovation for JavaFX in > >>>> general. > >>>> > >>>> I?d be happy to be that person but sadly, it?s not for me to make that > >>>> call. Johan is like the de facto ?Head of Innovation for JavaFX? at > the > >>>> moment but he has his own agenda (mainly in the mobile space) and > monetises > >>>> his efforts. > >>>> > >>>> That?s what businesses do. > >>>> > >>>> So, I think we need to firstly establish just what JavaFX is *now* > >>>> (even this is not clear) and also what it *should be* (where we > coalesce > >>>> everyone?s own ideas) so we can move forward. > >>>> > >>>> That is of course *if* JavaFX is actually going to ?move forward? > >>>> rather than ?sideways?. > >>>> > >>>> Honestly though, if you?re not moving forward, you are really going > >>>> backward as you watch the rest of the world disappear over the > horizon... > >>>> > >>>> Graciously, > >>>> > >>>> John-Val Rose > >>>> > >>>> > On 22 Sep 2017, at 22:38, Nir Lisker wrote: > >>>> > > >>>> > I didn't see any update on the idea for our initiative. Are we still > >>>> waiting for a reply from Oracle or do we go with Johan Vos's > experience? > >>>> > > >>>> > I think that the least we can do without putting any work into this > >>>> is have a semi-formal list of people who would like to work on this > and a > >>>> list of what features we would be working on. I feel that I still > don't > >>>> know the scope of what we are trying to do, only pieces of it. > >>>> > >>> > >>> > >> > > > > > From mp at jugs.org Sun Sep 24 15:11:41 2017 From: mp at jugs.org (Michael Paus) Date: Sun, 24 Sep 2017 17:11:41 +0200 Subject: OpenJFX initiative In-Reply-To: References: <6CF96EEA-1CD0-44A3-BF0F-C313288E29B0@gmail.com> Message-ID: <22933eb9-b24d-f26b-9bd6-b76ee8823dbc@jugs.org> Am 23.09.17 um 16:14 schrieb Mark Fortner: > I must have missed the bit where you described a proposed roadmap. Me too. > > I think for the most part I've seen JavaFX used as a means of keeping older > Swing-based projects alive. In the enterprise, those projects are > dwindling, in part because people just rebuild them as web applications. > It's easier to find that kind of talent, than it is to find desktop > developers. > > The applications that remain desktop applications tend to require either > access to your desktop OS, or need near realtime access to streams of > audio, video, telemetry or financial data, which makes them ill-suited to > be web apps. > > The reason that there's little interest in WebGL or 3d is because it > doesn't fit into one of the enterprise app buckets listed above. I think there is a big misunderstanding here. At least for me the main reason for asking for WebGL/OpenGL support is not an interest in fancy 3D animations or such. For me it is just a matter of performance. Many modern web pages heavily use WebGL for truly hardware accelerated 2D graphics. Just compare the performance of the JavaFX WebView with the performance of any other browser on the same machine when you display Google maps for example. In WebView you end up in some castrated "light mode" with a bad user experience just because WebView does not support WebGL. > > I'm still surprised when people tell me that they have to write mobile apps > in Java and Swift and maintain two codebases, and when I point them to > JavaFX they admit they've never heard of it. > > There needs to be better promotion of JavaFX in the Java developer > community. People need to compare the degree of complexity of web component > and PWA development against JavaFX to see the advantages. And there needs > to be a better deployment story than web start. Definitely yes. But the community also has to realize the importance of a proper system integration of programs written in JavaFX. For example it is still not possible to get a proper system menu bar in JavaFX on the Mac. You have to resort to external libraries for this like this: https://github.com/codecentric/NSMenuFX People also expect to get software in a certain system specific way they are used to (installers etc.). Now what does JavaFX do? The latest and greatest and long awaited Java 9 is delivered with a broken packager for the Mac although this regression has been known for many months. https://bugs.openjdk.java.net/browse/JDK-8179033 I can't package my app anymore for distribution which is quite frustrating when you have spent a lot of time to overcome the other Java 9 hurdles. > > A lot of that is simply promotion. It means reaching out to web development > and mobile development communities, and giving talks and demos. > > Mark > > > On 22 Sep 2017 5:32 p.m., "John-Val Rose" wrote: > > Probably, but JEPs can take a lot of time from start to finish and time is > itself perhaps the biggest enemy that JavaFX is facing. > > And how many JEPs are being initiated by the Oracle JavaFX team > themselves? I mean for the specific purpose of *true* innovation? > > On 23 September 2017 at 10:24, Nir Lisker wrote: > >> I don't have any answer to those questions. A JEP is the only thing I can >> think of. >> >> On Sat, Sep 23, 2017 at 3:19 AM, John-Val Rose >> wrote: >> >>> Yes, well I'm sure there's a lot of truth to that as Johan has >>> demonstrated. >>> >>> But, I think it's a bit of an over simplification. >>> >>> How do I know if *my* innovation (of say 9 months of effort) is > "high-quality >>> code that makes OpenJFX better"? >>> >>> I can do my best to write high-quality code but what exactly does "make >>> OpenJFX better" mean? *I* might think it's better with WebGL and advanced >>> 3D features but it seems most people disagree or are ambivalent towards >>> such functionality. >>> >>> Who gets to say what does or doesn't get integrated? And, how do I know >>> *before* I potentially waste my effort whether it will or won't "make >>> OpenJFX better" or be integrated? >>> >>> ?? >>> Graciously, >>> >>> John-Val Rose >>> Chief Scientist/Architect >>> Rosethorn Technology >>> Australia >>> >>> On 23 September 2017 at 09:08, Nir Lisker wrote: >>> >>>>> What do you mean by ?go with Johan Vos?s experience?? >>>> What he said here: http://mail.openjdk.java >>>> .net/pipermail/openjfx-dev/2017-September/020801.html. >>>> >>>> On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose >>>> wrote: >>>> >>>>> The concept of ?innovation? no longer seems to apply to JavaFX, at >>>>> least not from Oracle?s perspective. >>>>> >>>>> If you read the official list of changes in the just-released Java 9, >>>>> AWT (yes, AWT) has more changes than JavaFX and even then the only >>>>> significant change is to make it Jigsaw compatible. >>>>> >>>>> A product like this needs a very clear ?roadmap? of development and >>>>> introduction of new features but the link on the Oracle JavaFX >>>>> Documentation page for ?roadmap? leads to a place known as ?404?. I > hope >>>>> that?s not a room number in ?Hotel California?. >>>>> >>>>> So, innovation for JavaFX falls back as a community responsibility but >>>>> is very difficult without any cooperation from Oracle themselves. >>>>> >>>>> I personally have not been able to get any response from them except >>>>> ?float your ideas on the mailing list to see what interest there is?. > Note, >>>>> that ?interest? is only from the community itself... and then what? >>>>> >>>>> What do you mean by ?go with Johan Vos?s experience?? Yes, he and Gluon >>>>> are fantastic innovators and have built a small company of top-notch > talent >>>>> and are able to crank-out new products and enhancements with impressive >>>>> frequency. >>>>> >>>>> Are you suggesting we all start similar companies? Johan is a former >>>>> Oracle employee and probably has a well-established relationship with > them >>>>> and access to knowledge that others don?t. Personally, I love what he?s >>>>> doing and hope Gluon expands rapidly to enable as much innovation as >>>>> possible. >>>>> >>>>> But what about the rest of us? What are we supposed to do? How do we >>>>> get large-scale changes to happen? >>>>> >>>>> Well, I don?t know. But we?re better as a team than a bunch of >>>>> individuals each trying to get some feature implemented in an > uncoordinated >>>>> fashion. >>>>> >>>>> The other real issue is that everyone seems to have their own >>>>> perspective on exactly what JavaFX is or should be. That makes the >>>>> community ineffective unless someone manages innovation for JavaFX in >>>>> general. >>>>> >>>>> I?d be happy to be that person but sadly, it?s not for me to make that >>>>> call. Johan is like the de facto ?Head of Innovation for JavaFX? at the >>>>> moment but he has his own agenda (mainly in the mobile space) and > monetises >>>>> his efforts. >>>>> >>>>> That?s what businesses do. >>>>> >>>>> So, I think we need to firstly establish just what JavaFX is *now* >>>>> (even this is not clear) and also what it *should be* (where we > coalesce >>>>> everyone?s own ideas) so we can move forward. >>>>> >>>>> That is of course *if* JavaFX is actually going to ?move forward? >>>>> rather than ?sideways?. >>>>> >>>>> Honestly though, if you?re not moving forward, you are really going >>>>> backward as you watch the rest of the world disappear over the > horizon... >>>>> Graciously, >>>>> >>>>> John-Val Rose >>>>> >>>>>> On 22 Sep 2017, at 22:38, Nir Lisker wrote: >>>>>> >>>>>> I didn't see any update on the idea for our initiative. Are we still >>>>> waiting for a reply from Oracle or do we go with Johan Vos's > experience? >>>>>> I think that the least we can do without putting any work into this >>>>> is have a semi-formal list of people who would like to work on this > and a >>>>> list of what features we would be working on. I feel that I still don't >>>>> know the scope of what we are trying to do, only pieces of it. >>>>> >>>> From alexander.zvegintsev at oracle.com Mon Sep 25 12:05:11 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 25 Sep 2017 17:35:11 +0530 Subject: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage In-Reply-To: References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> Message-ID: Hi Dmitry, From my understanding JavaFX stage can't be easily integrated in JDK to support orderWindow() approach, addChildWindow() is a native(and the simplest) way to maintain one window above other one, should be called only once. IIUC the main concert of JDK-8080729 that child windows jumping to parent's display upon focus receiving, this is not an issue with current fix, because addChildWindow() will be called only upon dialog creation in case of JavaFX-Swing interop. Jump may happen if user want to create a child swing dialog on display other than JavaFX stage's one, but such rare scenario can be easily workarounded on a user side by calling setLocation() right after setVisible() call. So I would prefer to use addChildWindow() to make this fix as simple as possible. Thanks, Alexander. On 23/09/2017 21:21, Dmitry Markov wrote: > Hi Alexander, > > In CPlatformWindow class you call CWrapper.NSWindow.addChildWindow() to place a window above JavaFX stage. The usage of addChilWindow() or/and removeChildWindow() may cause ?jumping window issue? in multi-monitor environment, see JDK-8080729 for more details. > > To avoid possible problems in multi monitor set-up I suggest that you should replace addChildWindow() with orderWindow() or use some another approach to locate the window above the stage. > > Thanks, > Dmitry >> On 22 Sep 2017, at 06:56, Alexander Zvegintsev wrote: >> >> Hi Phil, >> >> Please review the updated fix with reflection incorporated >> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ >> >> New issue created JDK-8187803 as JDK counterpart of this issue. >> >> Thanks, >> Alexander. >> >> On 21/09/2017 22:25, Phil Race wrote: >>> Some procedural comments : >>> Since 90% of this is in AWT code, I'd have thought awt-dev should be included here. >>> I've added that list. >>> >>> And apart from needing separate bug ids, I don't see why the bug below is confidential. >>> >>> >>> I agree with what Kevin pointed out off-line that as in the dialog case, the FX side >>> of the code can use reflection and simply be a harmless non-functional no-op >>> if the SwingAccessor does not provide the new method. >>> >>> BTW >>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } >>> should be "dd" not "d". >>> >>> -phil. >>> >>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: >>>> Hello, >>>> >>>> please review the fix >>>> >>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ >>>> >>>> for the issue >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8185634 >>>> From alexander.zvegintsev at oracle.com Mon Sep 25 12:06:43 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 25 Sep 2017 17:36:43 +0530 Subject: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <7c868789-6c1e-28c9-af7a-057d551e0dfe@oracle.com> References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> <7c868789-6c1e-28c9-af7a-057d551e0dfe@oracle.com> Message-ID: <14319a76-ca8c-c0a9-008e-cfe950b9df33@oracle.com> Hi Sergey, Thanks for catching this, this is an issue which should be addressed. Thanks, Alexander. On 23/09/2017 08:01, Sergey Bylokhov wrote: > Hi, Alexander. > How can we be sure that the parent frame will not be disposed while we > use a pointer? > > long ownerWindowPtr = peer.getOverridenWindowHandle(); > <<<<< Dispose the peer > if (ownerWindowPtr != 0) { > ??? //Place window above JavaFX stage > ??? CWrapper.NSWindow.addChildWindow( > ??? ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove); > <<<<< Boom > } > > > On 9/21/17 22:56, Alexander Zvegintsev wrote: >> Hi Phil, >> >> Please review the updated fix with reflection incorporated >> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ >> >> New issue created JDK-8187803 >> as JDK counterpart >> of this issue. >> >> Thanks, >> Alexander. >> >> On 21/09/2017 22:25, Phil Race wrote: >>> Some procedural comments : >>> Since 90% of this is in AWT code, I'd have thought awt-dev should be >>> included here. >>> I've added that list. >>> >>> And apart from needing separate bug ids, I don't see why the bug >>> below is confidential. >>> >>> >>> I agree with what Kevin pointed out off-line that as in the dialog >>> case, the FX side >>> of the code can use reflection and simply be a harmless >>> non-functional no-op >>> if the SwingAccessor does not provide the new method. >>> >>> BTW >>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } >>> should be "dd" not "d". >>> >>> -phil. >>> >>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: >>>> Hello, >>>> >>>> please review the fix >>>> >>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ >>>> >>>> for the issue >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8185634 >>>> >>> >> > > From ketchxup at googlemail.com Mon Sep 25 12:18:39 2017 From: ketchxup at googlemail.com (David Bimamisa) Date: Mon, 25 Sep 2017 14:18:39 +0200 Subject: Gradle test fail; DLLS are missing (Windows 10) Message-ID: Hi all, I'm trying to build OpenJFX-8u on a Windows 10 machine and I stuck in the test task of the fxpackager module. I'm getting the following exception: com.oracle.tools.packager.APITest > testRuntimes FAILED java.lang.RuntimeException: Not found MSVC dlls at com.oracle.tools.packager.windows.WinAppBundler.copyMSVCDLLs(WinAppBundler.java:320) at com.oracle.tools.packager.windows.WinAppBundler.doBundle(WinAppBundler.java:277) at com.oracle.tools.packager.windows.WinAppBundler.execute(WinAppBundler.java:586) at com.oracle.tools.packager.APITest.testRuntimes(APITest.java:135) It seems that some DLLs (e.g. file:/[..]/modules/fxpackager/build/classes/test/com/oracle/tools/packager/windows//vcruntime100.dll) are missing. Can you give some hints on how to solve this problem? Best regards David From semyon.sadetsky at oracle.com Mon Sep 25 15:36:47 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 25 Sep 2017 08:36:47 -0700 Subject: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> Message-ID: <596225fc-d924-8bab-bbd1-5bb73398d32d@oracle.com> Hi Alexander, On the Windows platform you've only modified the dialog native peer while on other platforms all window types are modified to use FX window as a parent. Shouldn't the frame native peer be modified too on the Windows platform? --Semyon On 09/21/2017 10:56 PM, Alexander Zvegintsev wrote: > > Hi Phil, > > Please review the updated fix with reflection incorporated > http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ > > New issue created JDK-8187803 > as JDK counterpart > of this issue. > > Thanks, > Alexander. > On 21/09/2017 22:25, Phil Race wrote: >> Some procedural comments : >> Since 90% of this is in AWT code, I'd have thought awt-dev should be >> included here. >> I've added that list. >> >> And apart from needing separate bug ids, I don't see why the bug >> below is confidential. >> >> >> I agree with what Kevin pointed out off-line that as in the dialog >> case, the FX side >> of the code can use reflection and simply be a harmless >> non-functional no-op >> if the SwingAccessor does not provide the new method. >> >> BTW >> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } >> should be "dd" not "d". >> >> -phil. >> >> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: >>> Hello, >>> >>> please review the fix >>> >>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ >>> >>> for the issue >>> >>> https://bugs.openjdk.java.net/browse/JDK-8185634 >>> >> > From Sergey.Bylokhov at oracle.com Mon Sep 25 16:21:31 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 25 Sep 2017 09:21:31 -0700 Subject: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode In-Reply-To: <2df0d688-5111-3320-d287-d3500dd3ffaa@oracle.com> References: <98abeab4-f831-a724-dae0-6745df63dfc0@oracle.com> <2df0d688-5111-3320-d287-d3500dd3ffaa@oracle.com> Message-ID: From the AWT point of view the fix looks fine. On 9/23/17 00:03, Prasanta Sadhukhan wrote: > Hi Sergey, > > Please find modified webrev catering to DefaultKeyboardFocusManager also > http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.05/ > > Regards > Prasanta > On 9/23/2017 7:52 AM, Sergey Bylokhov wrote: >> Hi, Prasanta. >> >> On 9/19/17 22:26, Prasanta Sadhukhan wrote: >>>> Hi, Prasanta. >>>> ?- In this version it is unclear what is a purpose of the >>>> "fxCheckSequenceThread.start()". This code will start the thread and >>>> will continue execution, it will not wait when the thread will stop. >>>> ?- The DefaultKeyboardFocusManager also should check for >>>> "javafx.embed.singleThread" >>>> >>> Please find modified webrev catering to both comments >>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/ >> >> The new code in DefaultKeyboardFocusManager also will not wait when >> the thread will stop. >> >>> >>> Regards >>> Prasanta >>>> >>>> On 9/13/17 03:11, Prasanta Sadhukhan wrote: >>>>> Hi Sergey, >>>>> >>>>> I have modified the fix to not use SecondaryLoop and not to create >>>>> one thread per dispatch >>>>> http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 8/30/2017 11:41 AM, Sergey Bylokhov wrote: >>>>>> Hi, Prasanta. >>>>>> Can you please provide some description on how the SecondaryLoop >>>>>> will work when it will run on Appkit thread? Is it possible to get >>>>>> a deadlock here, since appkit will be blocked? >>>>>> >>>>>>> sequence, ie if the event is not first in sequence, then it will >>>>>>> made >>>>>>> to >>>>>>> wait till it is the first event or till it is disposed. >>>>>> Note that the new code (unlike lines 139-150) also waits 1 second, >>>>>> so we can get a situation when only one event will be dispatched >>>>>> per second, which is not we want to do. >>>>>> I am not sure how often we create SequencedEvent but creating one >>>>>> thread per dispatch look inefficient. >>>>>> >>>>>> >>>>>>> Modified webrev >>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/ >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 8/23/2017 9:31 PM, Sergey Bylokhov wrote: >>>>>>>> Hi, Prasanta. >>>>>>>> >>>>>>>> On 16.08.2017 3:33, Prasanta Sadhukhan wrote: >>>>>>>>> Now, since here FX App thread itself is the dispatch thread, we >>>>>>>>> can >>>>>>>>> be sure the events are dispatched in sequence and dispose is >>>>>>> checked >>>>>>>>> below after EDT. >>>>>>>> Why we can sure about this? If the SequencedEvents were created in >>>>>>> one >>>>>>>> order but dispatch() for each were called in other order then the >>>>>>>> sequenced will not be preserved? >>>>>>>> >>>>>>>>> I have tested with couple of singleThread testcase without any >>>>>>> issue. >>>>>>>>> Regards >>>>>>>>> Prasanta >>>>>>>>> On 8/14/2017 10:07 PM, Sergey Bylokhov wrote: >>>>>>>>>> Hi, Prasanta, Kevin. >>>>>>>>>> >>>>>>>>>> I have two notes. >>>>>>>>>> ?? - Does this option is really supported? If it is supported we >>>>>>>>>> should evaluate all usage of EventDispatchThread because in this >>>>>>>>>> mode the dispatch thread is not EDT. For example I am not sure >>>>>>> that >>>>>>>>>> we can skip the code which expects EventDispatchThread. >>>>>>>>>> ?? - We have the similar pattern: >>>>>>>>>> "EventQueue.isDispatchThread() -> >>>>>>>>>> cast(EventDispatchThread)" in some other places like in >>>>>>>>>> DefaultKeyboardFocusManager. >>>>>>>>>> >>>>>>>>>> -----prasanta.sadhukhan at oracle.com? wrote: >>>>>>>>>> >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> Please review this fix >>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/ >>>>>>>>>>> for an fx issue >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8088132 >>>>>>>>>>> >>>>>>>>>>> More info in JBS. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> Prasanta >>>>>>>> >>>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From dmitry.markov at oracle.com Mon Sep 25 20:31:08 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Mon, 25 Sep 2017 21:31:08 +0100 Subject: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage In-Reply-To: References: <234563d7-7f68-296a-523c-c005cf4ca9a5@oracle.com> <26bddfb0-3dfa-92ac-b476-abe5a6bda1e1@oracle.com> Message-ID: Hi Alexander, Sounds reasonable. I am OK with usage of addChildWindow() in this case. Thanks, Dmitry > On 25 Sep 2017, at 13:05, Alexander Zvegintsev wrote: > > Hi Dmitry, > > From my understanding JavaFX stage can't be easily integrated in JDK to support orderWindow() approach, > > addChildWindow() is a native(and the simplest) way to maintain one window above other one, should be called only once. > > IIUC the main concert of JDK-8080729 that child windows jumping to parent's display upon focus receiving, this is not an issue with current fix, > > because addChildWindow() will be called only upon dialog creation in case of JavaFX-Swing interop. > > Jump may happen if user want to create a child swing dialog on display other than JavaFX stage's one, > > but such rare scenario can be easily workarounded on a user side by calling setLocation() right after setVisible() call. > > So I would prefer to use addChildWindow() to make this fix as simple as possible. > > > Thanks, > Alexander. > > On 23/09/2017 21:21, Dmitry Markov wrote: >> Hi Alexander, >> >> In CPlatformWindow class you call CWrapper.NSWindow.addChildWindow() to place a window above JavaFX stage. The usage of addChilWindow() or/and removeChildWindow() may cause ?jumping window issue? in multi-monitor environment, see JDK-8080729 for more details. >> >> To avoid possible problems in multi monitor set-up I suggest that you should replace addChildWindow() with orderWindow() or use some another approach to locate the window above the stage. >> >> Thanks, >> Dmitry >>> On 22 Sep 2017, at 06:56, Alexander Zvegintsev wrote: >>> >>> Hi Phil, >>> >>> Please review the updated fix with reflection incorporated >>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/ >>> >>> New issue created JDK-8187803 as JDK counterpart of this issue. >>> >>> Thanks, >>> Alexander. >>> >>> On 21/09/2017 22:25, Phil Race wrote: >>>> Some procedural comments : >>>> Since 90% of this is in AWT code, I'd have thought awt-dev should be included here. >>>> I've added that list. >>>> >>>> And apart from needing separate bug ids, I don't see why the bug below is confidential. >>>> >>>> >>>> I agree with what Kevin pointed out off-line that as in the dialog case, the FX side >>>> of the code can use reflection and simply be a harmless non-functional no-op >>>> if the SwingAccessor does not provide the new method. >>>> >>>> BTW >>>> 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; } >>>> should be "dd" not "d". >>>> >>>> -phil. >>>> >>>> On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote: >>>>> Hello, >>>>> >>>>> please review the fix >>>>> >>>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/ >>>>> >>>>> for the issue >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8185634 >>>>> > From ketchxup at googlemail.com Tue Sep 26 13:37:42 2017 From: ketchxup at googlemail.com (David Bimamisa) Date: Tue, 26 Sep 2017 15:37:42 +0200 Subject: Gradle test fail; DLLS are missing (Windows 10) In-Reply-To: References: Message-ID: Hi all, I solve this problem after stumbling over the following comments in the *buildSrc/genVSproperties.bat* file: *"The current officially supported Visual Studio version is 15.0 * *Handling of 11.0 and 14.0 is excluded here"* Thus, installing Visual Studio 2017 (VS 15.0) on the Windows 10 machine -- instead of VS 2010 Express as recommended in the wiki -- works for me. Maybe the comments above should be added to the wiki. Regards David 2017-09-25 14:18 GMT+02:00 David Bimamisa : > Hi all, > > I'm trying to build OpenJFX-8u on a Windows 10 machine and I stuck in the > test task of the fxpackager module. I'm getting the following exception: > > com.oracle.tools.packager.APITest > testRuntimes FAILED > java.lang.RuntimeException: Not found MSVC dlls at > com.oracle.tools.packager.windows.WinAppBundler. > copyMSVCDLLs(WinAppBundler.java:320) > at com.oracle.tools.packager.windows.WinAppBundler. > doBundle(WinAppBundler.java:277) > at com.oracle.tools.packager.windows.WinAppBundler.execute( > WinAppBundler.java:586) > at com.oracle.tools.packager.APITest.testRuntimes(APITest. > java:135) > > It seems that some DLLs (e.g. file:/[..]/modules/fxpackager/ > build/classes/test/com/oracle/tools/packager/windows//vcruntime100.dll) > are missing. > > Can you give some hints on how to solve this problem? > > Best regards > David > From ketchxup at googlemail.com Tue Sep 26 16:05:34 2017 From: ketchxup at googlemail.com (David Bimamisa) Date: Tue, 26 Sep 2017 18:05:34 +0200 Subject: Gradle test fail; DLLS are missing (Windows 10) In-Reply-To: References: Message-ID: Now I'm having issues when running unit tests of the webkit module. :web:test # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000069c6f73d, pid=8240, tid=0x000000000000337c # # JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build 1.8.0_144-b01) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode windows-amd64 compressed oops) # Problematic frame: # V [jvm.dll+0x14f73d] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # C:\Users\~\Documents\projects-shaka-in_process\rt\modules\web\hs_err_pid8240.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Exception in thread "JavaFX Application Thread" Unexpected exception thrown. org.gradle.messaging.remote.internal.MessageIOException: Could not write message [EndOfStream] to '/127.0.0.1:64074'. at org.gradle.messaging.remote.internal.inet.SocketConnection.dispatch(SocketConnection.java:115) at org.gradle.messaging.remote.internal.hub.MessageHub$ConnectionDispatch.run(MessageHub.java:279) at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) And the corresponding report file: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000069c6f73d, pid=4728, tid=0x0000000000002690 # # JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build 1.8.0_144-b01) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode windows-amd64 compressed oops) # Problematic frame: # V [jvm.dll+0x14f73d] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x000000001ec34800): JavaThread "JavaFX Application Thread" [_thread_in_vm, id=9872, stack(0x0000000021800000,0x0000000021900000)] siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000000 Registers: RAX=0x0000000000000000, RBX=0x000000001ec34800, RCX=0x0000000000000480, RDX=0x000000001dd9dd68 RSP=0x00000000218fcca0, RBP=0x00000000218fcd98, RSI=0x0000000000000000, RDI=0x000000001ec349f8 R8 =0x0000000000000000, R9 =0x00000000218fcd98, R10=0x000000001b25bc60, R11=0x000000000262a970 R12=0x000000001dd9dd68, R13=0x0000000000000000, R14=0x000000001ec349f8, R15=0x0000000020f915a0 RIP=0x0000000069c6f73d, EFLAGS=0x0000000000010246 Top of Stack: (sp=0x00000000218fcca0) 0x00000000218fcca0: 00000000218fcc89 0000000800000001 0x00000000218fccb0: 0000000000000000 00000006c53eff70 0x00000000218fccc0: 000036cea0d95ca8 0000000000000001 0x00000000218fccd0: 000000006b322620 0000000069c648fd 0x00000000218fcce0: 000000001e5bc888 000000006a126ee0 0x00000000218fccf0: 000000001ec34800 0000000000000000 0x00000000218fcd00: 000000000262a6d0 000000001ec34800 0x00000000218fcd10: 000000000000000e 0000000069c64a0b 0x00000000218fcd20: 0000000020f915a0 000000001ec349f8 0x00000000218fcd30: 0000000000000000 0000000000000000 0x00000000218fcd40: 0000000000000000 0000000067c2b55c 0x00000000218fcd50: 000000001ec349f8 00000000685f7ae0 0x00000000218fcd60: 00000000009d5450 000000001f247978 0x00000000218fcd70: 000000001ec349f8 0000000067c4ee80 0x00000000218fcd80: 00000000685f7ae0 000000001ec349f8 0x00000000218fcd90: 0000000000000000 000000001f247978 Instructions: (pc=0x0000000069c6f73d) 0x0000000069c6f71d: 00 48 83 7b 08 00 48 89 5c 24 50 48 c7 44 24 58 0x0000000069c6f72d: 00 00 00 00 74 0a 48 8d 4c 24 50 e8 63 c6 12 00 0x0000000069c6f73d: 48 8b 06 c7 44 24 40 0e 00 00 00 48 8d 4c 24 70 0x0000000069c6f74d: 48 8b 50 08 0f b7 42 24 48 8b 52 08 48 8b 54 c2 Register to memory mapping: RAX=0x0000000000000000 is an unknown value RBX=0x000000001ec34800 is a thread RCX=0x0000000000000480 is an unknown value RDX=0x000000001dd9dd68 is a global jni handle RSP=0x00000000218fcca0 is pointing into the stack for thread: 0x000000001ec34800 RBP=0x00000000218fcd98 is pointing into the stack for thread: 0x000000001ec34800 RSI=0x0000000000000000 is an unknown value RDI=0x000000001ec349f8 is an unknown value R8 =0x0000000000000000 is an unknown value R9 =0x00000000218fcd98 is pointing into the stack for thread: 0x000000001ec34800 R10={method} {0x000000001b25bc68} 'printStackTrace' '()V' in 'java/lang/Throwable' R11=0x000000000262a970 is an unknown value R12=0x000000001dd9dd68 is a global jni handle R13=0x0000000000000000 is an unknown value R14=0x000000001ec349f8 is an unknown value R15=0x0000000020f915a0 is an unknown value Stack: [0x0000000021800000,0x0000000021900000], sp=0x00000000218fcca0, free space=1011k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x14f73d] C [jfxwebkit.dll+0x8cb55c] C [jfxwebkit.dll+0x8eee80] C [jfxwebkit.dll+0x5a80e8] C [jfxwebkit.dll+0x8e6371] C [jfxwebkit.dll+0x8ee37e] C [jfxwebkit.dll+0x4eae04] C [jfxwebkit.dll+0x4ebacf] C [jfxwebkit.dll+0x6cf2ac] C [jfxwebkit.dll+0x6cd2c6] C [jfxwebkit.dll+0x6cfcd5] C [jfxwebkit.dll+0x3bf35c] C [jfxwebkit.dll+0x7e3a54] C [jfxwebkit.dll+0x7e3514] C [jfxwebkit.dll+0x7e39fd] C [jfxwebkit.dll+0x7e3514] C [jfxwebkit.dll+0x7e39fd] C [jfxwebkit.dll+0x7e6021] C [jfxwebkit.dll+0x7e5804] C [jfxwebkit.dll+0x7e5340] C [jfxwebkit.dll+0x2894d6] C [jfxwebkit.dll+0x290755] C [jfxwebkit.dll+0x283698] C [jfxwebkit.dll+0x4b4847] C [jfxwebkit.dll+0x4f2d92] C [jfxwebkit.dll+0x4da3e9] C [jfxwebkit.dll+0x4d968c] C [jfxwebkit.dll+0x4d5d46] C [jfxwebkit.dll+0x8f419f] C [jfxwebkit.dll+0x8f5801] C 0x00000000027d7f74 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j com.sun.webkit.network.URLLoader.twkDidFail(ILjava/lang/String;Ljava/lang/String;J)V+0 j com.sun.webkit.network.URLLoader.notifyDidFail(ILjava/lang/String;Ljava/lang/String;)V+102 j com.sun.webkit.network.URLLoader.lambda$didFail$6(ILjava/lang/String;Ljava/lang/String;)V+11 j com.sun.webkit.network.URLLoader$$Lambda$273.run()V+16 j com.sun.javafx.application.PlatformImpl.lambda$null$5(Ljava/lang/Runnable;)Ljava/lang/Void;+1 j com.sun.javafx.application.PlatformImpl$$Lambda$54.run()Ljava/lang/Object;+4 v ~StubRoutines::call_stub J 2338 java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object; (0 bytes) @ 0x0000000002f57066 [0x0000000002f57000+0x66] j com.sun.javafx.application.PlatformImpl.lambda$runLater$6(Ljava/lang/Runnable;Ljava/security/AccessControlContext;)V+7 j com.sun.javafx.application.PlatformImpl$$Lambda$53.run()V+8 j com.sun.glass.ui.monocle.RunnableProcessor.runLoop()Ljava/lang/Object;+36 j com.sun.glass.ui.monocle.RunnableProcessor.run()V+1 j java.lang.Thread.run()V+11 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x000000001e8b9800 JavaThread "URL-Loader-14" daemon [_thread_blocked, id=11888, stack(0x0000000066e80000,0x0000000066f80000)] 0x000000001ec33000 JavaThread "URL-Loader-13" daemon [_thread_blocked, id=3596, stack(0x0000000066d80000,0x0000000066e80000)] 0x000000001ec31800 JavaThread "URL-Loader-12" daemon [_thread_blocked, id=7936, stack(0x0000000066c80000,0x0000000066d80000)] 0x000000001ec32800 JavaThread "Prism Font Disposer" daemon [_thread_blocked, id=11704, stack(0x0000000063010000,0x0000000063110000)] 0x000000001ec36000 JavaThread "Disposer" daemon [_thread_blocked, id=8516, stack(0x0000000061c10000,0x0000000061d10000)] 0x000000001ec35800 JavaThread "Timer-0" daemon [_thread_blocked, id=5244, stack(0x0000000021900000,0x0000000021a00000)] =>0x000000001ec34800 JavaThread "JavaFX Application Thread" [_thread_in_vm, id=9872, stack(0x0000000021800000,0x0000000021900000)] 0x000000001ec30000 JavaThread "QuantumRenderer-0" daemon [_thread_blocked, id=11256, stack(0x00000000211c0000,0x00000000212c0000)] 0x000000001ec2f800 JavaThread "Test worker" [_thread_blocked, id=12732, stack(0x000000001fbc0000,0x000000001fcc0000)] 0x000000001e7cc000 JavaThread "socket connection at /127.0.0.1:63555 with /127.0.0.1:63554 workers Thread 2" [_thread_in_native, id=220, stack(0x000000001f8c0000,0x000000001f9c0000)] 0x000000001e378800 JavaThread "socket connection at /127.0.0.1:63555 with /127.0.0.1:63554 workers" [_thread_blocked, id=2340, stack(0x000000001f7c0000,0x000000001f8c0000)] 0x000000001d0fb800 JavaThread "Service Thread" daemon [_thread_blocked, id=6244, stack(0x000000001dab0000,0x000000001dbb0000)] 0x000000001bc27000 JavaThread "C1 CompilerThread2" daemon [_thread_blocked, id=9788, stack(0x000000001d9b0000,0x000000001dab0000)] 0x000000001bc1d800 JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=12764, stack(0x000000001d8b0000,0x000000001d9b0000)] 0x000000001bc1b000 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=10040, stack(0x000000001d7b0000,0x000000001d8b0000)] 0x000000001bc19000 JavaThread "Attach Listener" daemon [_thread_blocked, id=8576, stack(0x000000001d6b0000,0x000000001d7b0000)] 0x000000001bbfe000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=6112, stack(0x000000001d5b0000,0x000000001d6b0000)] 0x000000001bbca800 JavaThread "Finalizer" daemon [_thread_blocked, id=7616, stack(0x000000001ce30000,0x000000001cf30000)] 0x00000000026d1000 JavaThread "Reference Handler" daemon [_thread_blocked, id=1768, stack(0x000000001cd30000,0x000000001ce30000)] 0x00000000027be000 JavaThread "main" [_thread_blocked, id=7848, stack(0x00000000024c0000,0x00000000025c0000)] Other Threads: 0x000000001bba8000 VMThread [stack: 0x000000001cc30000,0x000000001cd30000] [id=11656] 0x000000001d12a800 WatcherThread [stack: 0x000000001dbb0000,0x000000001dcb0000] [id=12444] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap: PSYoungGen total 243200K, used 33029K [0x000000076c300000, 0x000000077f400000, 0x00000007c0000000) eden space 237056K, 13% used [0x000000076c300000,0x000000076e341780,0x000000077aa80000) from space 6144K, 0% used [0x000000077c500000,0x000000077c500000,0x000000077cb00000) to space 27136K, 0% used [0x000000077aa80000,0x000000077aa80000,0x000000077c500000) ParOldGen total 132096K, used 39085K [0x00000006c4800000, 0x00000006cc900000, 0x000000076c300000) object space 132096K, 29% used [0x00000006c4800000,0x00000006c6e2b6b8,0x00000006cc900000) Metaspace used 21147K, capacity 22320K, committed 22400K, reserved 1069056K class space used 2831K, capacity 3123K, committed 3200K, reserved 1048576K Card table byte_map: [0x0000000011b80000,0x0000000012360000] byte_map_base: 0x000000000e55c000 Marking Bits: (ParMarkBitMap*) 0x000000006a33d850 Begin Bits: [0x0000000012ca0000, 0x0000000016b80000) End Bits: [0x0000000016b80000, 0x000000001aa60000) Polling page: 0x0000000000cd0000 CodeCache: size=245760Kb used=8377Kb max_used=8377Kb free=237382Kb bounds [0x00000000027c0000, 0x0000000003010000, 0x00000000117c0000] total_blobs=3204 nmethods=2570 adapters=546 compilation: enabled Compilation events (10 events): Event: 65.613 Thread 0x000000001bc27000 nmethod 3018 0x0000000002d5c110 code [0x0000000002d5c260, 0x0000000002d5c3f0] Event: 65.613 Thread 0x000000001bc27000 3019 3 com.sun.javafx.iio.png.PNGImageLoader2::paethPr (56 bytes) Event: 65.613 Thread 0x000000001bc27000 nmethod 3019 0x0000000002d824d0 code [0x0000000002d82660, 0x0000000002d82a70] Event: 65.615 Thread 0x000000001bc27000 3021 3 org.gradle.util.LineBufferingOutputStream::endsWithLineSeparator (61 bytes) Event: 65.615 Thread 0x000000001bc27000 nmethod 3021 0x0000000002d81f10 code [0x0000000002d82080, 0x0000000002d82370] Event: 65.615 Thread 0x000000001bc27000 3020 3 org.gradle.util.LineBufferingOutputStream::write (97 bytes) Event: 65.616 Thread 0x000000001bc27000 nmethod 3020 0x0000000002d716d0 code [0x0000000002d71880, 0x0000000002d71d58] Event: 65.616 Thread 0x000000001bc27000 3022 1 sun.nio.cs.SingleByte$Decoder::decode (11 bytes) Event: 65.616 Thread 0x000000001bc27000 nmethod 3022 0x0000000002d71350 code [0x0000000002d714a0, 0x0000000002d715f0] Event: 65.616 Thread 0x000000001bc27000 3023 3 java.nio.ByteBuffer::arrayOffset (35 bytes) GC Heap History (10 events): Event: 1.965 GC heap before {Heap before GC invocations=3 (full 0): PSYoungGen total 75264K, used 67890K [0x000000076c300000, 0x0000000775600000, 0x00000007c0000000) eden space 64512K, 99% used [0x000000076c300000,0x00000007701e5008,0x0000000770200000) from space 10752K, 32% used [0x0000000770c80000,0x0000000770fe7a50,0x0000000771700000) to space 10752K, 0% used [0x0000000770200000,0x0000000770200000,0x0000000770c80000) ParOldGen total 172032K, used 24K [0x00000006c4800000, 0x00000006cf000000, 0x000000076c300000) object space 172032K, 0% used [0x00000006c4800000,0x00000006c4806000,0x00000006cf000000) Metaspace used 10666K, capacity 10994K, committed 11264K, reserved 1058816K class space used 1346K, capacity 1457K, committed 1536K, reserved 1048576K Event: 1.969 GC heap after Heap after GC invocations=3 (full 0): PSYoungGen total 75264K, used 3525K [0x000000076c300000, 0x0000000775600000, 0x00000007c0000000) eden space 64512K, 0% used [0x000000076c300000,0x000000076c300000,0x0000000770200000) from space 10752K, 32% used [0x0000000770200000,0x0000000770571788,0x0000000770c80000) to space 10752K, 0% used [0x0000000774b80000,0x0000000774b80000,0x0000000775600000) ParOldGen total 172032K, used 32K [0x00000006c4800000, 0x00000006cf000000, 0x000000076c300000) object space 172032K, 0% used [0x00000006c4800000,0x00000006c4808000,0x00000006cf000000) Metaspace used 10666K, capacity 10994K, committed 11264K, reserved 1058816K class space used 1346K, capacity 1457K, committed 1536K, reserved 1048576K } Event: 1.986 GC heap before {Heap before GC invocations=4 (full 0): PSYoungGen total 75264K, used 68000K [0x000000076c300000, 0x0000000775600000, 0x00000007c0000000) eden space 64512K, 99% used [0x000000076c300000,0x00000007701f69f0,0x0000000770200000) from space 10752K, 32% used [0x0000000770200000,0x0000000770571788,0x0000000770c80000) to space 10752K, 0% used [0x0000000774b80000,0x0000000774b80000,0x0000000775600000) ParOldGen total 172032K, used 32K [0x00000006c4800000, 0x00000006cf000000, 0x000000076c300000) object space 172032K, 0% used [0x00000006c4800000,0x00000006c4808000,0x00000006cf000000) Metaspace used 10666K, capacity 10994K, committed 11264K, reserved 1058816K class space used 1346K, capacity 1457K, committed 1536K, reserved 1048576K Event: 1.990 GC heap after Heap after GC invocations=4 (full 0): PSYoungGen total 139776K, used 3570K [0x000000076c300000, 0x0000000775600000, 0x00000007c0000000) eden space 129024K, 0% used [0x000000076c300000,0x000000076c300000,0x0000000774100000) from space 10752K, 33% used [0x0000000774b80000,0x0000000774efc958,0x0000000775600000) to space 10752K, 0% used [0x0000000774100000,0x0000000774100000,0x0000000774b80000) ParOldGen total 172032K, used 40K [0x00000006c4800000, 0x00000006cf000000, 0x000000076c300000) object space 172032K, 0% used [0x00000006c4800000,0x00000006c480a000,0x00000006cf000000) Metaspace used 10666K, capacity 10994K, committed 11264K, reserved 1058816K class space used 1346K, capacity 1457K, committed 1536K, reserved 1048576K } Event: 4.018 GC heap before {Heap before GC invocations=5 (full 0): PSYoungGen total 139776K, used 132594K [0x000000076c300000, 0x0000000775600000, 0x00000007c0000000) eden space 129024K, 100% used [0x000000076c300000,0x0000000774100000,0x0000000774100000) from space 10752K, 33% used [0x0000000774b80000,0x0000000774efc958,0x0000000775600000) to space 10752K, 0% used [0x0000000774100000,0x0000000774100000,0x0000000774b80000) ParOldGen total 172032K, used 40K [0x00000006c4800000, 0x00000006cf000000, 0x000000076c300000) object space 172032K, 0% used [0x00000006c4800000,0x00000006c480a000,0x00000006cf000000) Metaspace used 10916K, capacity 11256K, committed 11520K, reserved 1058816K class space used 1362K, capacity 1458K, committed 1536K, reserved 1048576K Event: 4.024 GC heap after Heap after GC invocations=5 (full 0): PSYoungGen total 139776K, used 3991K [0x000000076c300000, 0x000000077cb00000, 0x00000007c0000000) eden space 129024K, 0% used [0x000000076c300000,0x000000076c300000,0x0000000774100000) from space 10752K, 37% used [0x0000000774100000,0x00000007744e5de8,0x0000000774b80000) to space 6144K, 0% used [0x000000077c500000,0x000000077c500000,0x000000077cb00000) ParOldGen total 172032K, used 48K [0x00000006c4800000, 0x00000006cf000000, 0x000000076c300000) object space 172032K, 0% used [0x00000006c4800000,0x00000006c480c000,0x00000006cf000000) Metaspace used 10916K, capacity 11256K, committed 11520K, reserved 1058816K class space used 1362K, capacity 1458K, committed 1536K, reserved 1048576K } Event: 6.305 GC heap before {Heap before GC invocations=6 (full 0): PSYoungGen total 139776K, used 88628K [0x000000076c300000, 0x000000077cb00000, 0x00000007c0000000) eden space 129024K, 65% used [0x000000076c300000,0x00000007715a7218,0x0000000774100000) from space 10752K, 37% used [0x0000000774100000,0x00000007744e5de8,0x0000000774b80000) to space 6144K, 0% used [0x000000077c500000,0x000000077c500000,0x000000077cb00000) ParOldGen total 172032K, used 48K [0x00000006c4800000, 0x00000006cf000000, 0x000000076c300000) object space 172032K, 0% used [0x00000006c4800000,0x00000006c480c000,0x00000006cf000000) Metaspace used 20354K, capacity 21286K, committed 21296K, reserved 1067008K class space used 2728K, capacity 2937K, committed 2944K, reserved 1048576K Event: 6.330 GC heap after Heap after GC invocations=6 (full 0): PSYoungGen total 243200K, used 6143K [0x000000076c300000, 0x000000077f400000, 0x00000007c0000000) eden space 237056K, 0% used [0x000000076c300000,0x000000076c300000,0x000000077aa80000) from space 6144K, 99% used [0x000000077c500000,0x000000077caffce0,0x000000077cb00000) to space 27136K, 0% used [0x000000077aa80000,0x000000077aa80000,0x000000077c500000) ParOldGen total 172032K, used 36077K [0x00000006c4800000, 0x00000006cf000000, 0x000000076c300000) object space 172032K, 20% used [0x00000006c4800000,0x00000006c6b3b7d8,0x00000006cf000000) Metaspace used 20354K, capacity 21286K, committed 21296K, reserved 1067008K class space used 2728K, capacity 2937K, committed 2944K, reserved 1048576K } Event: 6.330 GC heap before {Heap before GC invocations=7 (full 1): PSYoungGen total 243200K, used 6143K [0x000000076c300000, 0x000000077f400000, 0x00000007c0000000) eden space 237056K, 0% used [0x000000076c300000,0x000000076c300000,0x000000077aa80000) from space 6144K, 99% used [0x000000077c500000,0x000000077caffce0,0x000000077cb00000) to space 27136K, 0% used [0x000000077aa80000,0x000000077aa80000,0x000000077c500000) ParOldGen total 172032K, used 36077K [0x00000006c4800000, 0x00000006cf000000, 0x000000076c300000) object space 172032K, 20% used [0x00000006c4800000,0x00000006c6b3b7d8,0x00000006cf000000) Metaspace used 20354K, capacity 21286K, committed 21296K, reserved 1067008K class space used 2728K, capacity 2937K, committed 2944K, reserved 1048576K Event: 6.387 GC heap after Heap after GC invocations=7 (full 1): PSYoungGen total 243200K, used 0K [0x000000076c300000, 0x000000077f400000, 0x00000007c0000000) eden space 237056K, 0% used [0x000000076c300000,0x000000076c300000,0x000000077aa80000) from space 6144K, 0% used [0x000000077c500000,0x000000077c500000,0x000000077cb00000) to space 27136K, 0% used [0x000000077aa80000,0x000000077aa80000,0x000000077c500000) ParOldGen total 132096K, used 39085K [0x00000006c4800000, 0x00000006cc900000, 0x000000076c300000) object space 132096K, 29% used [0x00000006c4800000,0x00000006c6e2b6b8,0x00000006cc900000) Metaspace used 20354K, capacity 21286K, committed 21296K, reserved 1067008K class space used 2728K, capacity 2937K, committed 2944K, reserved 1048576K } Deoptimization events (10 events): Event: 65.470 Thread 0x000000001e378800 Uncommon trap: reason=unstable_if action=reinterpret pc=0x0000000002b8fde0 method=java.io.ObjectOutputStream$BlockDataOutputStream.getUTFLength(Ljava/lang/String;)J @ 73 Event: 65.470 Thread 0x000000001e378800 Uncommon trap: reason=unstable_if action=reinterpret pc=0x0000000002dfcbe8 method=java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(Ljava/lang/String;J)V @ 29 Event: 65.590 Thread 0x000000001ec34800 Uncommon trap: reason=bimorphic action=maybe_recompile pc=0x0000000002de4958 method=java.util.regex.Pattern$Curly.match0(Ljava/util/regex/Matcher;IILjava/lang/CharSequence;)Z @ 141 Event: 65.590 Thread 0x000000001ec34800 Uncommon trap: reason=unstable_if action=reinterpret pc=0x0000000002ff5550 method=java.util.Formatter$Flags.parse(Ljava/lang/String;)Ljava/util/Formatter$Flags; @ 19 Event: 65.590 Thread 0x000000001ec34800 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000002f61ba0 method=java.util.Formatter$FormatSpecifier.printInteger(Ljava/lang/Object;Ljava/util/Locale;)V @ 58 Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=unstable_if action=reinterpret pc=0x0000000002c3332c method=java.io.ByteArrayInputStream.read()I @ 8 Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000002c3b630 method=java.io.FilterInputStream.read()I @ 4 Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000002c3b630 method=java.io.FilterInputStream.read()I @ 4 Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000002c3b630 method=java.io.FilterInputStream.read()I @ 4 Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000002c3b630 method=java.io.FilterInputStream.read()I @ 4 Internal exceptions (10 events): Event: 65.561 Thread 0x000000001ec34800 Exception (0x000000076ca68530) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, line 709] Event: 65.568 Thread 0x000000001ec34800 Exception (0x000000076ca6a7f0) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\runtime\reflection.cpp, line 1092] Event: 65.568 Thread 0x000000001ec34800 Exception (0x000000076ca6ac10) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jvm.cpp, line 1390] Event: 65.568 Thread 0x000000001ec34800 Exception (0x000000076ca6aeb0) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, line 709] Event: 65.575 Thread 0x000000001ec34800 Exception (0x000000076ca70f10) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, line 709] Event: 65.578 Thread 0x000000001ec34800 Exception (0x000000076ca71c38) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, line 709] Event: 65.588 Thread 0x000000001e8b9800 Exception (0x000000076decde80) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, line 709] Event: 65.588 Thread 0x000000001e8b9800 Exception (0x000000076dece590) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, line 709] Event: 65.596 Thread 0x000000001e378800 Exception > (0x000000076d0e8c68) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, line 1613] Event: 65.614 Thread 0x000000001ec34800 Exception (0x000000076e0eaf80) thrown at [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, line 1613] Events (10 events): Event: 65.612 loading class com/sun/javafx/iio/ImageMetadata Event: 65.612 loading class com/sun/javafx/iio/ImageMetadata done Event: 65.613 loading class com/sun/javafx/iio/ImageFrame Event: 65.613 loading class com/sun/javafx/iio/ImageFrame done Event: 65.614 loading class com/sun/javafx/iio/ImageStorage$ImageType Event: 65.614 loading class com/sun/javafx/iio/ImageStorage$ImageType done Event: 65.614 loading class java/lang/Throwable$WrappedPrintStream Event: 65.614 loading class java/lang/Throwable$WrappedPrintStream done Event: 65.614 loading class java/util/IdentityHashMap$KeySet Event: 65.614 loading class java/util/IdentityHashMap$KeySet done Dynamic libraries: 0x00007ff600290000 - 0x00007ff6002c7000 C:\Program Files\Java\jdk1.8.0_144\bin\java.exe 0x00007ffc2b5f0000 - 0x00007ffc2b7cb000 C:\WINDOWS\SYSTEM32\ntdll.dll 0x00007ffc2a0a0000 - 0x00007ffc2a14e000 C:\WINDOWS\System32\KERNEL32.DLL 0x00007ffc28050000 - 0x00007ffc28299000 C:\WINDOWS\System32\KERNELBASE.dll 0x00007ffc26110000 - 0x00007ffc2618e000 C:\WINDOWS\SYSTEM32\apphelp.dll 0x00007ffc29740000 - 0x00007ffc297e1000 C:\WINDOWS\System32\ADVAPI32.dll 0x00007ffc28e40000 - 0x00007ffc28edd000 C:\WINDOWS\System32\msvcrt.dll 0x00007ffc2a150000 - 0x00007ffc2a1a9000 C:\WINDOWS\System32\sechost.dll 0x00007ffc28b50000 - 0x00007ffc28c75000 C:\WINDOWS\System32\RPCRT4.dll 0x00007ffc29910000 - 0x00007ffc29a5a000 C:\WINDOWS\System32\USER32.dll 0x00007ffc27ce0000 - 0x00007ffc27cfe000 C:\WINDOWS\System32\win32u.dll 0x00007ffc29fb0000 - 0x00007ffc29fd7000 C:\WINDOWS\System32\GDI32.dll 0x00007ffc27d70000 - 0x00007ffc27ef8000 C:\WINDOWS\System32\gdi32full.dll 0x00007ffc27fb0000 - 0x00007ffc2804a000 C:\WINDOWS\System32\msvcp_win.dll 0x00007ffc28a50000 - 0x00007ffc28b46000 C:\WINDOWS\System32\ucrtbase.dll 0x00007ffc1a7e0000 - 0x00007ffc1aa47000 C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.15063.483_none_26002d27e7c744a2\COMCTL32.dll 0x00007ffc29a60000 - 0x00007ffc29d59000 C:\WINDOWS\System32\combase.dll 0x00007ffc27d00000 - 0x00007ffc27d6a000 C:\WINDOWS\System32\bcryptPrimitives.dll 0x00007ffc29080000 - 0x00007ffc290ad000 C:\WINDOWS\System32\IMM32.DLL 0x000000006b270000 - 0x000000006b342000 C:\Program Files\Java\jdk1.8.0_144\jre\bin\msvcr100.dll 0x0000000069b20000 - 0x000000006a3bd000 C:\Program Files\Java\jdk1.8.0_144\jre\bin\server\jvm.dll 0x00007ffc29900000 - 0x00007ffc29908000 C:\WINDOWS\System32\PSAPI.DLL 0x00007ffc16500000 - 0x00007ffc16509000 C:\WINDOWS\SYSTEM32\WSOCK32.dll 0x00007ffc290b0000 - 0x00007ffc2911c000 C:\WINDOWS\System32\WS2_32.dll 0x00007ffc24890000 - 0x00007ffc248b3000 C:\WINDOWS\SYSTEM32\WINMM.dll 0x00007ffc197c0000 - 0x00007ffc197ca000 C:\WINDOWS\SYSTEM32\VERSION.dll 0x00007ffc24830000 - 0x00007ffc2485b000 C:\WINDOWS\SYSTEM32\WINMMBASE.dll 0x00007ffc28300000 - 0x00007ffc28349000 C:\WINDOWS\System32\cfgmgr32.dll 0x000000006b260000 - 0x000000006b26f000 C:\Program Files\Java\jdk1.8.0_144\jre\bin\verify.dll 0x000000006b230000 - 0x000000006b259000 C:\Program Files\Java\jdk1.8.0_144\jre\bin\java.dll 0x000000006b210000 - 0x000000006b226000 C:\Program Files\Java\jdk1.8.0_144\jre\bin\zip.dll 0x00007ffc2a1b0000 - 0x00007ffc2b5e6000 C:\WINDOWS\System32\SHELL32.dll 0x00007ffc29ed0000 - 0x00007ffc29f7a000 C:\WINDOWS\System32\shcore.dll 0x00007ffc28350000 - 0x00007ffc28a43000 C:\WINDOWS\System32\windows.storage.dll 0x00007ffc29fe0000 - 0x00007ffc2a031000 C:\WINDOWS\System32\shlwapi.dll 0x00007ffc27aa0000 - 0x00007ffc27ab1000 C:\WINDOWS\System32\kernel.appcore.dll 0x00007ffc27ac0000 - 0x00007ffc27b0c000 C:\WINDOWS\System32\powrprof.dll 0x00007ffc27a80000 - 0x00007ffc27a95000 C:\WINDOWS\System32\profapi.dll 0x000000006b1f0000 - 0x000000006b20a000 C:\Program Files\Java\jdk1.8.0_144\jre\bin\net.dll 0x00007ffc27370000 - 0x00007ffc273cc000 C:\WINDOWS\system32\mswsock.dll 0x000000006b1d0000 - 0x000000006b1e1000 C:\Program Files\Java\jdk1.8.0_144\jre\bin\nio.dll 0x00007ffc27510000 - 0x00007ffc27527000 C:\WINDOWS\SYSTEM32\CRYPTSP.dll 0x00007ffc26f90000 - 0x00007ffc26fc4000 C:\WINDOWS\system32\rsaenh.dll 0x00007ffc27620000 - 0x00007ffc27645000 C:\WINDOWS\SYSTEM32\bcrypt.dll 0x00007ffc27990000 - 0x00007ffc279b9000 C:\WINDOWS\SYSTEM32\USERENV.dll 0x00007ffc27530000 - 0x00007ffc2753b000 C:\WINDOWS\SYSTEM32\CRYPTBASE.dll 0x00007ffc27110000 - 0x00007ffc27147000 C:\WINDOWS\SYSTEM32\IPHLPAPI.DLL 0x00007ffc29f80000 - 0x00007ffc29f88000 C:\WINDOWS\System32\NSI.dll 0x00007ffc1cb80000 - 0x00007ffc1cb96000 C:\WINDOWS\SYSTEM32\dhcpcsvc6.DLL 0x00007ffc1d550000 - 0x00007ffc1d56a000 C:\WINDOWS\SYSTEM32\dhcpcsvc.DLL 0x0000000067360000 - 0x0000000069b14000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\jfxwebkit.dll 0x00007ffc18480000 - 0x00007ffc18526000 C:\WINDOWS\SYSTEM32\MSVCP120.dll 0x00007ffc23cb0000 - 0x00007ffc23d9f000 C:\WINDOWS\SYSTEM32\MSVCR120.dll 0x0000000002750000 - 0x0000000002753000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-console-l1-1-0.dll 0x0000000002760000 - 0x0000000002763000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-datetime-l1-1-0.dll 0x0000000002770000 - 0x0000000002773000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-debug-l1-1-0.dll 0x0000000002780000 - 0x0000000002783000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-errorhandling-l1-1-0.dll 0x0000000002790000 - 0x0000000002794000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-file-l1-1-0.dll 0x00000000027a0000 - 0x00000000027a3000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-file-l1-2-0.dll 0x000000001fdc0000 - 0x000000001fdc3000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-file-l2-1-0.dll 0x000000001fdd0000 - 0x000000001fdd3000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-handle-l1-1-0.dll 0x000000001fde0000 - 0x000000001fde3000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-heap-l1-1-0.dll 0x00000000212e0000 - 0x00000000212e3000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-interlocked-l1-1-0.dll 0x00000000212f0000 - 0x00000000212f3000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-libraryloader-l1-1-0.dll 0x0000000021300000 - 0x0000000021303000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-localization-l1-2-0.dll 0x0000000021310000 - 0x0000000021313000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-memory-l1-1-0.dll 0x0000000021320000 - 0x0000000021323000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-namedpipe-l1-1-0.dll 0x0000000021330000 - 0x0000000021333000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-processenvironment-l1-1-0.dll 0x0000000021340000 - 0x0000000021343000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-processthreads-l1-1-0.dll 0x0000000021350000 - 0x0000000021353000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-processthreads-l1-1-1.dll 0x0000000021360000 - 0x0000000021363000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-profile-l1-1-0.dll 0x0000000021370000 - 0x0000000021373000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-rtlsupport-l1-1-0.dll 0x0000000021380000 - 0x0000000021383000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-string-l1-1-0.dll 0x00000000212d0000 - 0x00000000212d3000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-synch-l1-1-0.dll 0x0000000021510000 - 0x0000000021513000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-synch-l1-2-0.dll 0x0000000021520000 - 0x0000000021523000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-sysinfo-l1-1-0.dll 0x0000000021530000 - 0x0000000021533000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-timezone-l1-1-0.dll 0x0000000021540000 - 0x0000000021543000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-util-l1-1-0.dll 0x0000000021550000 - 0x0000000021553000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-conio-l1-1-0.dll 0x0000000021560000 - 0x0000000021564000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-convert-l1-1-0.dll 0x0000000021570000 - 0x0000000021573000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-environment-l1-1-0.dll 0x0000000021580000 - 0x0000000021583000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-filesystem-l1-1-0.dll 0x0000000021590000 - 0x0000000021593000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-heap-l1-1-0.dll 0x00000000215a0000 - 0x00000000215a3000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-locale-l1-1-0.dll 0x00000000215b0000 - 0x00000000215b5000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-math-l1-1-0.dll 0x00000000215c0000 - 0x00000000215c5000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-multibyte-l1-1-0.dll 0x00000000215d0000 - 0x00000000215e0000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-private-l1-1-0.dll 0x00000000215e0000 - 0x00000000215e3000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-process-l1-1-0.dll 0x00000000215f0000 - 0x00000000215f4000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-runtime-l1-1-0.dll 0x0000000021600000 - 0x0000000021604000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-stdio-l1-1-0.dll 0x0000000021610000 - 0x0000000021614000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-string-l1-1-0.dll 0x0000000021620000 - 0x0000000021623000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-time-l1-1-0.dll 0x0000000021630000 - 0x0000000021633000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-utility-l1-1-0.dll 0x00007ffbfe070000 - 0x00007ffbfe166000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\ucrtbase.dll 0x00007ffc1d750000 - 0x00007ffc1d7a1000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\concrt140.dll 0x00007ffc015b0000 - 0x00007ffc0164f000 C:\WINDOWS\SYSTEM32\MSVCP140.dll 0x00007ffc19750000 - 0x00007ffc19766000 C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll 0x00007ffc1ea00000 - 0x00007ffc1ea16000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\vcruntime140.dll 0x00007ffc09790000 - 0x00007ffc0982c000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\msvcp140.dll 0x00007ffc1e9e0000 - 0x00007ffc1e9fc000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\prism_sw.dll 0x00007ffc1d6e0000 - 0x00007ffc1d6f4000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\javafx_font.dll 0x00007ffc291a0000 - 0x00007ffc292e5000 C:\WINDOWS\System32\ole32.dll 0x00007ffc1de50000 - 0x00007ffc1e10f000 C:\WINDOWS\SYSTEM32\dwrite.dll 0x00007ffc1aaf0000 - 0x00007ffc1ab02000 C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\prism_common.dll 0x00007ffc26250000 - 0x00007ffc262e5000 C:\WINDOWS\system32\uxtheme.dll 0x000000006b1c0000 - 0x000000006b1cd000 C:\Program Files\Java\jdk1.8.0_144\jre\bin\management.dll 0x00007ffc0cbd0000 - 0x00007ffc0cd79000 C:\WINDOWS\SYSTEM32\dbghelp.dll VM Arguments: jvm_args: -DWEB_ARCHIVE_JAR_TEST_DIR=C:\Users\username\Documents\projects-username-in_process\rt\modules\web\build\testing\resources -Dglass.platform=Monocle -Djava.ext.dirs -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager -Dmonocle.platform=Headless -Dprism.order=sw -Dfile.encoding=windows-1252 -ea java_command: jarjar.org.gradle.process.internal.launcher.GradleWorkerMain java_class_path (initial): C:\Users\username\.gradle\caches\1.8\workerMain\gradle-worker.jar Launcher Type: SUN_STANDARD Environment Variables: JAVA_HOME=C:\Program Files\Java\jdk1.8.0_144 PATH=C:\Tools\cygwin64\usr\local\bin;C:\Tools\cygwin64\bin;C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\Program Files\Git\cmd;C:\Tools\gradle\bin;C:\Users\username\AppData\Local\Android\sdk\android-ndk-r10c;C:\Program Files\nodejs;C:\Program Files (x86)\Yarn\bin;C:\Program Files (x86)\Skype\Phone;C:\Program Files\Intel\WiFi\bin;C:\Program Files\Common Files\Intel\WirelessCommon;C:\Program Files\TortoiseHg;C:\Tools\ant-1.9.9\bin;C:\Program Files\Microsoft Windows Performance Toolkit;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\Microsoft SQL Server\130\Tools\Binn;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Users\username\AppData\Local\Microsoft\WindowsApps;C:\Users\username\AppData\Roaming\npm;C:\Users\username\AppData\Local\Yarn\.bin;C:\Users\username\AppData\Local\atom\bin;C:\Users\username\AppData\Local\Microsoft\WindowsApps SHELL=/bin/bash OS=Windows_NT PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 61 Stepping 4, GenuineIntel --------------- S Y S T E M --------------- OS: Windows 10.0 , 64 bit Build 15063 (10.0.15063.296) CPU:total 4 (initial active 4) (2 cores per cpu, 2 threads per core) family 6 model 61 stepping 4, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, avx2, aes, clmul, erms, 3dnowpref, lzcnt, ht, tsc, tscinvbit, bmi1, bmi2, adx Memory: 4k page, physical 16478140k(7207344k free), swap 18968508k(6267284k free) vm_info: Java HotSpot(TM) 64-Bit Server VM (25.144-b01) for windows-amd64 JRE (1.8.0_144-b01), built on Jul 21 2017 21:57:33 by "java_re" with MS VC++ 10.0 (VS2010) time: Tue Sep 26 15:40:58 2017 elapsed time: 65 seconds (0d 0h 1m 5s) 2017-09-26 15:37 GMT+02:00 David Bimamisa : > Hi all, > > I solve this problem after stumbling over the following comments in the > *buildSrc/genVSproperties.bat* file: > *"The current officially supported Visual Studio version is 15.0 * > *Handling of 11.0 and 14.0 is excluded here"* > > Thus, installing Visual Studio 2017 (VS 15.0) on the Windows 10 machine -- > instead of VS 2010 Express as recommended in the wiki > -- > works for me. > Maybe the comments above should be added to the wiki. > > Regards > David > > > 2017-09-25 14:18 GMT+02:00 David Bimamisa : > >> Hi all, >> >> I'm trying to build OpenJFX-8u on a Windows 10 machine and I stuck in the >> test task of the fxpackager module. I'm getting the following exception: >> >> com.oracle.tools.packager.APITest > testRuntimes FAILED >> java.lang.RuntimeException: Not found MSVC dlls at >> com.oracle.tools.packager.windows.WinAppBundler.copyMSVCDLLs >> (WinAppBundler.java:320) >> at com.oracle.tools.packager.windows.WinAppBundler.doBundle( >> WinAppBundler.java:277) >> at com.oracle.tools.packager.windows.WinAppBundler.execute(WinA >> ppBundler.java:586) >> at com.oracle.tools.packager.APITest.testRuntimes(APITest.java: >> 135) >> >> It seems that some DLLs (e.g. file:/[..]/modules/fxpackager/ >> build/classes/test/com/oracle/tools/packager/windows//vcruntime100.dll) >> are missing. >> >> Can you give some hints on how to solve this problem? >> >> Best regards >> David >> > > From kevin.rushforth at oracle.com Tue Sep 26 20:59:38 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 26 Sep 2017 13:59:38 -0700 Subject: Gradle test fail; DLLS are missing (Windows 10) In-Reply-To: References: Message-ID: <59CABFBA.8030006@oracle.com> I presume you aren't building WebKit? If not, then you will have a mismatch between the Java .class files and the native library. Possible solutions are: 1) Build WebKit yourself 2) Avoid running WebView tests 3) Wait for 3 weeks until JDK 8u152 is released (at which time the .class files and native libraries will be in sync again) -- Kevin David Bimamisa wrote: > Now I'm having issues when running unit tests of the webkit module. > > :web:test > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000069c6f73d, > pid=8240, tid=0x000000000000337c > # > # JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build > 1.8.0_144-b01) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode > windows-amd64 compressed oops) > # Problematic frame: > # V [jvm.dll+0x14f73d] > # > # Failed to write core dump. Minidumps are not enabled by default on client > versions of Windows > # > # An error report file with more information is saved as: > # > C:\Users\~\Documents\projects-shaka-in_process\rt\modules\web\hs_err_pid8240.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > Exception in thread "JavaFX Application Thread" Unexpected exception thrown. > org.gradle.messaging.remote.internal.MessageIOException: Could not write > message [EndOfStream] to '/127.0.0.1:64074'. > at > org.gradle.messaging.remote.internal.inet.SocketConnection.dispatch(SocketConnection.java:115) > at > org.gradle.messaging.remote.internal.hub.MessageHub$ConnectionDispatch.run(MessageHub.java:279) > at > org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > > And the corresponding report file: > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000069c6f73d, > pid=4728, tid=0x0000000000002690 > # > # JRE version: Java(TM) SE Runtime Environment (8.0_144-b01) (build > 1.8.0_144-b01) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode > windows-amd64 compressed oops) > # Problematic frame: > # V [jvm.dll+0x14f73d] > # > # Failed to write core dump. Minidumps are not enabled by default on client > versions of Windows > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x000000001ec34800): JavaThread "JavaFX Application > Thread" [_thread_in_vm, id=9872, > stack(0x0000000021800000,0x0000000021900000)] > > siginfo: ExceptionCode=0xc0000005, reading address 0x0000000000000000 > > Registers: > RAX=0x0000000000000000, RBX=0x000000001ec34800, RCX=0x0000000000000480, > RDX=0x000000001dd9dd68 > RSP=0x00000000218fcca0, RBP=0x00000000218fcd98, RSI=0x0000000000000000, > RDI=0x000000001ec349f8 > R8 =0x0000000000000000, R9 =0x00000000218fcd98, R10=0x000000001b25bc60, > R11=0x000000000262a970 > R12=0x000000001dd9dd68, R13=0x0000000000000000, R14=0x000000001ec349f8, > R15=0x0000000020f915a0 > RIP=0x0000000069c6f73d, EFLAGS=0x0000000000010246 > > Top of Stack: (sp=0x00000000218fcca0) > 0x00000000218fcca0: 00000000218fcc89 0000000800000001 > 0x00000000218fccb0: 0000000000000000 00000006c53eff70 > 0x00000000218fccc0: 000036cea0d95ca8 0000000000000001 > 0x00000000218fccd0: 000000006b322620 0000000069c648fd > 0x00000000218fcce0: 000000001e5bc888 000000006a126ee0 > 0x00000000218fccf0: 000000001ec34800 0000000000000000 > 0x00000000218fcd00: 000000000262a6d0 000000001ec34800 > 0x00000000218fcd10: 000000000000000e 0000000069c64a0b > 0x00000000218fcd20: 0000000020f915a0 000000001ec349f8 > 0x00000000218fcd30: 0000000000000000 0000000000000000 > 0x00000000218fcd40: 0000000000000000 0000000067c2b55c > 0x00000000218fcd50: 000000001ec349f8 00000000685f7ae0 > 0x00000000218fcd60: 00000000009d5450 000000001f247978 > 0x00000000218fcd70: 000000001ec349f8 0000000067c4ee80 > 0x00000000218fcd80: 00000000685f7ae0 000000001ec349f8 > 0x00000000218fcd90: 0000000000000000 000000001f247978 > > Instructions: (pc=0x0000000069c6f73d) > 0x0000000069c6f71d: 00 48 83 7b 08 00 48 89 5c 24 50 48 c7 44 24 58 > 0x0000000069c6f72d: 00 00 00 00 74 0a 48 8d 4c 24 50 e8 63 c6 12 00 > 0x0000000069c6f73d: 48 8b 06 c7 44 24 40 0e 00 00 00 48 8d 4c 24 70 > 0x0000000069c6f74d: 48 8b 50 08 0f b7 42 24 48 8b 52 08 48 8b 54 c2 > > > Register to memory mapping: > > RAX=0x0000000000000000 is an unknown value > RBX=0x000000001ec34800 is a thread > RCX=0x0000000000000480 is an unknown value > RDX=0x000000001dd9dd68 is a global jni handle > RSP=0x00000000218fcca0 is pointing into the stack for thread: > 0x000000001ec34800 > RBP=0x00000000218fcd98 is pointing into the stack for thread: > 0x000000001ec34800 > RSI=0x0000000000000000 is an unknown value > RDI=0x000000001ec349f8 is an unknown value > R8 =0x0000000000000000 is an unknown value > R9 =0x00000000218fcd98 is pointing into the stack for thread: > 0x000000001ec34800 > R10={method} {0x000000001b25bc68} 'printStackTrace' '()V' in > 'java/lang/Throwable' > R11=0x000000000262a970 is an unknown value > R12=0x000000001dd9dd68 is a global jni handle > R13=0x0000000000000000 is an unknown value > R14=0x000000001ec349f8 is an unknown value > R15=0x0000000020f915a0 is an unknown value > > > Stack: [0x0000000021800000,0x0000000021900000], sp=0x00000000218fcca0, > free space=1011k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > V [jvm.dll+0x14f73d] > C [jfxwebkit.dll+0x8cb55c] > C [jfxwebkit.dll+0x8eee80] > C [jfxwebkit.dll+0x5a80e8] > C [jfxwebkit.dll+0x8e6371] > C [jfxwebkit.dll+0x8ee37e] > C [jfxwebkit.dll+0x4eae04] > C [jfxwebkit.dll+0x4ebacf] > C [jfxwebkit.dll+0x6cf2ac] > C [jfxwebkit.dll+0x6cd2c6] > C [jfxwebkit.dll+0x6cfcd5] > C [jfxwebkit.dll+0x3bf35c] > C [jfxwebkit.dll+0x7e3a54] > C [jfxwebkit.dll+0x7e3514] > C [jfxwebkit.dll+0x7e39fd] > C [jfxwebkit.dll+0x7e3514] > C [jfxwebkit.dll+0x7e39fd] > C [jfxwebkit.dll+0x7e6021] > C [jfxwebkit.dll+0x7e5804] > C [jfxwebkit.dll+0x7e5340] > C [jfxwebkit.dll+0x2894d6] > C [jfxwebkit.dll+0x290755] > C [jfxwebkit.dll+0x283698] > C [jfxwebkit.dll+0x4b4847] > C [jfxwebkit.dll+0x4f2d92] > C [jfxwebkit.dll+0x4da3e9] > C [jfxwebkit.dll+0x4d968c] > C [jfxwebkit.dll+0x4d5d46] > C [jfxwebkit.dll+0x8f419f] > C [jfxwebkit.dll+0x8f5801] > C 0x00000000027d7f74 > > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j > com.sun.webkit.network.URLLoader.twkDidFail(ILjava/lang/String;Ljava/lang/String;J)V+0 > j > com.sun.webkit.network.URLLoader.notifyDidFail(ILjava/lang/String;Ljava/lang/String;)V+102 > j > com.sun.webkit.network.URLLoader.lambda$didFail$6(ILjava/lang/String;Ljava/lang/String;)V+11 > j com.sun.webkit.network.URLLoader$$Lambda$273.run()V+16 > j > com.sun.javafx.application.PlatformImpl.lambda$null$5(Ljava/lang/Runnable;)Ljava/lang/Void;+1 > j > com.sun.javafx.application.PlatformImpl$$Lambda$54.run()Ljava/lang/Object;+4 > v ~StubRoutines::call_stub > J 2338 > java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object; > (0 bytes) @ 0x0000000002f57066 [0x0000000002f57000+0x66] > j > com.sun.javafx.application.PlatformImpl.lambda$runLater$6(Ljava/lang/Runnable;Ljava/security/AccessControlContext;)V+7 > j com.sun.javafx.application.PlatformImpl$$Lambda$53.run()V+8 > j com.sun.glass.ui.monocle.RunnableProcessor.runLoop()Ljava/lang/Object;+36 > j com.sun.glass.ui.monocle.RunnableProcessor.run()V+1 > j java.lang.Thread.run()V+11 > v ~StubRoutines::call_stub > > --------------- P R O C E S S --------------- > > Java Threads: ( => current thread ) > 0x000000001e8b9800 JavaThread "URL-Loader-14" daemon [_thread_blocked, > id=11888, stack(0x0000000066e80000,0x0000000066f80000)] > 0x000000001ec33000 JavaThread "URL-Loader-13" daemon [_thread_blocked, > id=3596, stack(0x0000000066d80000,0x0000000066e80000)] > 0x000000001ec31800 JavaThread "URL-Loader-12" daemon [_thread_blocked, > id=7936, stack(0x0000000066c80000,0x0000000066d80000)] > 0x000000001ec32800 JavaThread "Prism Font Disposer" daemon > [_thread_blocked, id=11704, stack(0x0000000063010000,0x0000000063110000)] > 0x000000001ec36000 JavaThread "Disposer" daemon [_thread_blocked, > id=8516, stack(0x0000000061c10000,0x0000000061d10000)] > 0x000000001ec35800 JavaThread "Timer-0" daemon [_thread_blocked, id=5244, > stack(0x0000000021900000,0x0000000021a00000)] > =>0x000000001ec34800 JavaThread "JavaFX Application Thread" [_thread_in_vm, > id=9872, stack(0x0000000021800000,0x0000000021900000)] > 0x000000001ec30000 JavaThread "QuantumRenderer-0" daemon > [_thread_blocked, id=11256, stack(0x00000000211c0000,0x00000000212c0000)] > 0x000000001ec2f800 JavaThread "Test worker" [_thread_blocked, id=12732, > stack(0x000000001fbc0000,0x000000001fcc0000)] > 0x000000001e7cc000 JavaThread "socket connection at /127.0.0.1:63555 with > /127.0.0.1:63554 workers Thread 2" [_thread_in_native, id=220, > stack(0x000000001f8c0000,0x000000001f9c0000)] > 0x000000001e378800 JavaThread "socket connection at /127.0.0.1:63555 with > /127.0.0.1:63554 workers" [_thread_blocked, id=2340, > stack(0x000000001f7c0000,0x000000001f8c0000)] > 0x000000001d0fb800 JavaThread "Service Thread" daemon [_thread_blocked, > id=6244, stack(0x000000001dab0000,0x000000001dbb0000)] > 0x000000001bc27000 JavaThread "C1 CompilerThread2" daemon > [_thread_blocked, id=9788, stack(0x000000001d9b0000,0x000000001dab0000)] > 0x000000001bc1d800 JavaThread "C2 CompilerThread1" daemon > [_thread_in_native, id=12764, stack(0x000000001d8b0000,0x000000001d9b0000)] > 0x000000001bc1b000 JavaThread "C2 CompilerThread0" daemon > [_thread_blocked, id=10040, stack(0x000000001d7b0000,0x000000001d8b0000)] > 0x000000001bc19000 JavaThread "Attach Listener" daemon [_thread_blocked, > id=8576, stack(0x000000001d6b0000,0x000000001d7b0000)] > 0x000000001bbfe000 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=6112, stack(0x000000001d5b0000,0x000000001d6b0000)] > 0x000000001bbca800 JavaThread "Finalizer" daemon [_thread_blocked, > id=7616, stack(0x000000001ce30000,0x000000001cf30000)] > 0x00000000026d1000 JavaThread "Reference Handler" daemon > [_thread_blocked, id=1768, stack(0x000000001cd30000,0x000000001ce30000)] > 0x00000000027be000 JavaThread "main" [_thread_blocked, id=7848, > stack(0x00000000024c0000,0x00000000025c0000)] > > Other Threads: > 0x000000001bba8000 VMThread [stack: > 0x000000001cc30000,0x000000001cd30000] [id=11656] > 0x000000001d12a800 WatcherThread [stack: > 0x000000001dbb0000,0x000000001dcb0000] [id=12444] > > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap: > PSYoungGen total 243200K, used 33029K [0x000000076c300000, > 0x000000077f400000, 0x00000007c0000000) > eden space 237056K, 13% used > [0x000000076c300000,0x000000076e341780,0x000000077aa80000) > from space 6144K, 0% used > [0x000000077c500000,0x000000077c500000,0x000000077cb00000) > to space 27136K, 0% used > [0x000000077aa80000,0x000000077aa80000,0x000000077c500000) > ParOldGen total 132096K, used 39085K [0x00000006c4800000, > 0x00000006cc900000, 0x000000076c300000) > object space 132096K, 29% used > [0x00000006c4800000,0x00000006c6e2b6b8,0x00000006cc900000) > Metaspace used 21147K, capacity 22320K, committed 22400K, reserved > 1069056K > class space used 2831K, capacity 3123K, committed 3200K, reserved > 1048576K > > Card table byte_map: [0x0000000011b80000,0x0000000012360000] byte_map_base: > 0x000000000e55c000 > > Marking Bits: (ParMarkBitMap*) 0x000000006a33d850 > Begin Bits: [0x0000000012ca0000, 0x0000000016b80000) > End Bits: [0x0000000016b80000, 0x000000001aa60000) > > Polling page: 0x0000000000cd0000 > > CodeCache: size=245760Kb used=8377Kb max_used=8377Kb free=237382Kb > bounds [0x00000000027c0000, 0x0000000003010000, 0x00000000117c0000] > total_blobs=3204 nmethods=2570 adapters=546 > compilation: enabled > > Compilation events (10 events): > Event: 65.613 Thread 0x000000001bc27000 nmethod 3018 0x0000000002d5c110 > code [0x0000000002d5c260, 0x0000000002d5c3f0] > Event: 65.613 Thread 0x000000001bc27000 3019 3 > com.sun.javafx.iio.png.PNGImageLoader2::paethPr (56 bytes) > Event: 65.613 Thread 0x000000001bc27000 nmethod 3019 0x0000000002d824d0 > code [0x0000000002d82660, 0x0000000002d82a70] > Event: 65.615 Thread 0x000000001bc27000 3021 3 > org.gradle.util.LineBufferingOutputStream::endsWithLineSeparator (61 bytes) > Event: 65.615 Thread 0x000000001bc27000 nmethod 3021 0x0000000002d81f10 > code [0x0000000002d82080, 0x0000000002d82370] > Event: 65.615 Thread 0x000000001bc27000 3020 3 > org.gradle.util.LineBufferingOutputStream::write (97 bytes) > Event: 65.616 Thread 0x000000001bc27000 nmethod 3020 0x0000000002d716d0 > code [0x0000000002d71880, 0x0000000002d71d58] > Event: 65.616 Thread 0x000000001bc27000 3022 1 > sun.nio.cs.SingleByte$Decoder::decode (11 bytes) > Event: 65.616 Thread 0x000000001bc27000 nmethod 3022 0x0000000002d71350 > code [0x0000000002d714a0, 0x0000000002d715f0] > Event: 65.616 Thread 0x000000001bc27000 3023 3 > java.nio.ByteBuffer::arrayOffset (35 bytes) > > GC Heap History (10 events): > Event: 1.965 GC heap before > {Heap before GC invocations=3 (full 0): > PSYoungGen total 75264K, used 67890K [0x000000076c300000, > 0x0000000775600000, 0x00000007c0000000) > eden space 64512K, 99% used > [0x000000076c300000,0x00000007701e5008,0x0000000770200000) > from space 10752K, 32% used > [0x0000000770c80000,0x0000000770fe7a50,0x0000000771700000) > to space 10752K, 0% used > [0x0000000770200000,0x0000000770200000,0x0000000770c80000) > ParOldGen total 172032K, used 24K [0x00000006c4800000, > 0x00000006cf000000, 0x000000076c300000) > object space 172032K, 0% used > [0x00000006c4800000,0x00000006c4806000,0x00000006cf000000) > Metaspace used 10666K, capacity 10994K, committed 11264K, reserved > 1058816K > class space used 1346K, capacity 1457K, committed 1536K, reserved > 1048576K > Event: 1.969 GC heap after > Heap after GC invocations=3 (full 0): > PSYoungGen total 75264K, used 3525K [0x000000076c300000, > 0x0000000775600000, 0x00000007c0000000) > eden space 64512K, 0% used > [0x000000076c300000,0x000000076c300000,0x0000000770200000) > from space 10752K, 32% used > [0x0000000770200000,0x0000000770571788,0x0000000770c80000) > to space 10752K, 0% used > [0x0000000774b80000,0x0000000774b80000,0x0000000775600000) > ParOldGen total 172032K, used 32K [0x00000006c4800000, > 0x00000006cf000000, 0x000000076c300000) > object space 172032K, 0% used > [0x00000006c4800000,0x00000006c4808000,0x00000006cf000000) > Metaspace used 10666K, capacity 10994K, committed 11264K, reserved > 1058816K > class space used 1346K, capacity 1457K, committed 1536K, reserved > 1048576K > } > Event: 1.986 GC heap before > {Heap before GC invocations=4 (full 0): > PSYoungGen total 75264K, used 68000K [0x000000076c300000, > 0x0000000775600000, 0x00000007c0000000) > eden space 64512K, 99% used > [0x000000076c300000,0x00000007701f69f0,0x0000000770200000) > from space 10752K, 32% used > [0x0000000770200000,0x0000000770571788,0x0000000770c80000) > to space 10752K, 0% used > [0x0000000774b80000,0x0000000774b80000,0x0000000775600000) > ParOldGen total 172032K, used 32K [0x00000006c4800000, > 0x00000006cf000000, 0x000000076c300000) > object space 172032K, 0% used > [0x00000006c4800000,0x00000006c4808000,0x00000006cf000000) > Metaspace used 10666K, capacity 10994K, committed 11264K, reserved > 1058816K > class space used 1346K, capacity 1457K, committed 1536K, reserved > 1048576K > Event: 1.990 GC heap after > Heap after GC invocations=4 (full 0): > PSYoungGen total 139776K, used 3570K [0x000000076c300000, > 0x0000000775600000, 0x00000007c0000000) > eden space 129024K, 0% used > [0x000000076c300000,0x000000076c300000,0x0000000774100000) > from space 10752K, 33% used > [0x0000000774b80000,0x0000000774efc958,0x0000000775600000) > to space 10752K, 0% used > [0x0000000774100000,0x0000000774100000,0x0000000774b80000) > ParOldGen total 172032K, used 40K [0x00000006c4800000, > 0x00000006cf000000, 0x000000076c300000) > object space 172032K, 0% used > [0x00000006c4800000,0x00000006c480a000,0x00000006cf000000) > Metaspace used 10666K, capacity 10994K, committed 11264K, reserved > 1058816K > class space used 1346K, capacity 1457K, committed 1536K, reserved > 1048576K > } > Event: 4.018 GC heap before > {Heap before GC invocations=5 (full 0): > PSYoungGen total 139776K, used 132594K [0x000000076c300000, > 0x0000000775600000, 0x00000007c0000000) > eden space 129024K, 100% used > [0x000000076c300000,0x0000000774100000,0x0000000774100000) > from space 10752K, 33% used > [0x0000000774b80000,0x0000000774efc958,0x0000000775600000) > to space 10752K, 0% used > [0x0000000774100000,0x0000000774100000,0x0000000774b80000) > ParOldGen total 172032K, used 40K [0x00000006c4800000, > 0x00000006cf000000, 0x000000076c300000) > object space 172032K, 0% used > [0x00000006c4800000,0x00000006c480a000,0x00000006cf000000) > Metaspace used 10916K, capacity 11256K, committed 11520K, reserved > 1058816K > class space used 1362K, capacity 1458K, committed 1536K, reserved > 1048576K > Event: 4.024 GC heap after > Heap after GC invocations=5 (full 0): > PSYoungGen total 139776K, used 3991K [0x000000076c300000, > 0x000000077cb00000, 0x00000007c0000000) > eden space 129024K, 0% used > [0x000000076c300000,0x000000076c300000,0x0000000774100000) > from space 10752K, 37% used > [0x0000000774100000,0x00000007744e5de8,0x0000000774b80000) > to space 6144K, 0% used > [0x000000077c500000,0x000000077c500000,0x000000077cb00000) > ParOldGen total 172032K, used 48K [0x00000006c4800000, > 0x00000006cf000000, 0x000000076c300000) > object space 172032K, 0% used > [0x00000006c4800000,0x00000006c480c000,0x00000006cf000000) > Metaspace used 10916K, capacity 11256K, committed 11520K, reserved > 1058816K > class space used 1362K, capacity 1458K, committed 1536K, reserved > 1048576K > } > Event: 6.305 GC heap before > {Heap before GC invocations=6 (full 0): > PSYoungGen total 139776K, used 88628K [0x000000076c300000, > 0x000000077cb00000, 0x00000007c0000000) > eden space 129024K, 65% used > [0x000000076c300000,0x00000007715a7218,0x0000000774100000) > from space 10752K, 37% used > [0x0000000774100000,0x00000007744e5de8,0x0000000774b80000) > to space 6144K, 0% used > [0x000000077c500000,0x000000077c500000,0x000000077cb00000) > ParOldGen total 172032K, used 48K [0x00000006c4800000, > 0x00000006cf000000, 0x000000076c300000) > object space 172032K, 0% used > [0x00000006c4800000,0x00000006c480c000,0x00000006cf000000) > Metaspace used 20354K, capacity 21286K, committed 21296K, reserved > 1067008K > class space used 2728K, capacity 2937K, committed 2944K, reserved > 1048576K > Event: 6.330 GC heap after > Heap after GC invocations=6 (full 0): > PSYoungGen total 243200K, used 6143K [0x000000076c300000, > 0x000000077f400000, 0x00000007c0000000) > eden space 237056K, 0% used > [0x000000076c300000,0x000000076c300000,0x000000077aa80000) > from space 6144K, 99% used > [0x000000077c500000,0x000000077caffce0,0x000000077cb00000) > to space 27136K, 0% used > [0x000000077aa80000,0x000000077aa80000,0x000000077c500000) > ParOldGen total 172032K, used 36077K [0x00000006c4800000, > 0x00000006cf000000, 0x000000076c300000) > object space 172032K, 20% used > [0x00000006c4800000,0x00000006c6b3b7d8,0x00000006cf000000) > Metaspace used 20354K, capacity 21286K, committed 21296K, reserved > 1067008K > class space used 2728K, capacity 2937K, committed 2944K, reserved > 1048576K > } > Event: 6.330 GC heap before > {Heap before GC invocations=7 (full 1): > PSYoungGen total 243200K, used 6143K [0x000000076c300000, > 0x000000077f400000, 0x00000007c0000000) > eden space 237056K, 0% used > [0x000000076c300000,0x000000076c300000,0x000000077aa80000) > from space 6144K, 99% used > [0x000000077c500000,0x000000077caffce0,0x000000077cb00000) > to space 27136K, 0% used > [0x000000077aa80000,0x000000077aa80000,0x000000077c500000) > ParOldGen total 172032K, used 36077K [0x00000006c4800000, > 0x00000006cf000000, 0x000000076c300000) > object space 172032K, 20% used > [0x00000006c4800000,0x00000006c6b3b7d8,0x00000006cf000000) > Metaspace used 20354K, capacity 21286K, committed 21296K, reserved > 1067008K > class space used 2728K, capacity 2937K, committed 2944K, reserved > 1048576K > Event: 6.387 GC heap after > Heap after GC invocations=7 (full 1): > PSYoungGen total 243200K, used 0K [0x000000076c300000, > 0x000000077f400000, 0x00000007c0000000) > eden space 237056K, 0% used > [0x000000076c300000,0x000000076c300000,0x000000077aa80000) > from space 6144K, 0% used > [0x000000077c500000,0x000000077c500000,0x000000077cb00000) > to space 27136K, 0% used > [0x000000077aa80000,0x000000077aa80000,0x000000077c500000) > ParOldGen total 132096K, used 39085K [0x00000006c4800000, > 0x00000006cc900000, 0x000000076c300000) > object space 132096K, 29% used > [0x00000006c4800000,0x00000006c6e2b6b8,0x00000006cc900000) > Metaspace used 20354K, capacity 21286K, committed 21296K, reserved > 1067008K > class space used 2728K, capacity 2937K, committed 2944K, reserved > 1048576K > } > > Deoptimization events (10 events): > Event: 65.470 Thread 0x000000001e378800 Uncommon trap: reason=unstable_if > action=reinterpret pc=0x0000000002b8fde0 > method=java.io.ObjectOutputStream$BlockDataOutputStream.getUTFLength(Ljava/lang/String;)J > @ 73 > Event: 65.470 Thread 0x000000001e378800 Uncommon trap: reason=unstable_if > action=reinterpret pc=0x0000000002dfcbe8 > method=java.io.ObjectOutputStream$BlockDataOutputStream.writeUTF(Ljava/lang/String;J)V > @ 29 > Event: 65.590 Thread 0x000000001ec34800 Uncommon trap: reason=bimorphic > action=maybe_recompile pc=0x0000000002de4958 > method=java.util.regex.Pattern$Curly.match0(Ljava/util/regex/Matcher;IILjava/lang/CharSequence;)Z > @ 141 > Event: 65.590 Thread 0x000000001ec34800 Uncommon trap: reason=unstable_if > action=reinterpret pc=0x0000000002ff5550 > method=java.util.Formatter$Flags.parse(Ljava/lang/String;)Ljava/util/Formatter$Flags; > @ 19 > Event: 65.590 Thread 0x000000001ec34800 Uncommon trap: reason=class_check > action=maybe_recompile pc=0x0000000002f61ba0 > method=java.util.Formatter$FormatSpecifier.printInteger(Ljava/lang/Object;Ljava/util/Locale;)V > @ 58 > Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=unstable_if > action=reinterpret pc=0x0000000002c3332c > method=java.io.ByteArrayInputStream.read()I @ 8 > Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=class_check > action=maybe_recompile pc=0x0000000002c3b630 > method=java.io.FilterInputStream.read()I @ 4 > Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=class_check > action=maybe_recompile pc=0x0000000002c3b630 > method=java.io.FilterInputStream.read()I @ 4 > Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=class_check > action=maybe_recompile pc=0x0000000002c3b630 > method=java.io.FilterInputStream.read()I @ 4 > Event: 65.612 Thread 0x000000001ec34800 Uncommon trap: reason=class_check > action=maybe_recompile pc=0x0000000002c3b630 > method=java.io.FilterInputStream.read()I @ 4 > > Internal exceptions (10 events): > Event: 65.561 Thread 0x000000001ec34800 Exception 'sun/nio/fs/WindowsException'> (0x000000076ca68530) thrown at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, > line 709] > Event: 65.568 Thread 0x000000001ec34800 Exception 'java/lang/reflect/InvocationTargetException'> (0x000000076ca6a7f0) thrown > at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\runtime\reflection.cpp, > line 1092] > Event: 65.568 Thread 0x000000001ec34800 Exception 'java/security/PrivilegedActionException'> (0x000000076ca6ac10) thrown at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jvm.cpp, > line 1390] > Event: 65.568 Thread 0x000000001ec34800 Exception 'netscape/javascript/JSException'> (0x000000076ca6aeb0) thrown at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, > line 709] > Event: 65.575 Thread 0x000000001ec34800 Exception 'sun/nio/fs/WindowsException'> (0x000000076ca70f10) thrown at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, > line 709] > Event: 65.578 Thread 0x000000001ec34800 Exception 'sun/nio/fs/WindowsException'> (0x000000076ca71c38) thrown at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, > line 709] > Event: 65.588 Thread 0x000000001e8b9800 Exception 'java/io/FileNotFoundException'> (0x000000076decde80) thrown at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, > line 709] > Event: 65.588 Thread 0x000000001e8b9800 Exception 'java/io/FileNotFoundException'> (0x000000076dece590) thrown at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, > line 709] > Event: 65.596 Thread 0x000000001e378800 Exception 'java/lang/NoSuchMethodError': > (0x000000076d0e8c68) thrown at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, > line 1613] > Event: 65.614 Thread 0x000000001ec34800 Exception 'java/lang/NoSuchMethodError': getImageSize> (0x000000076e0eaf80) thrown at > [C:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u144\9417\hotspot\src\share\vm\prims\jni.cpp, > line 1613] > > Events (10 events): > Event: 65.612 loading class com/sun/javafx/iio/ImageMetadata > Event: 65.612 loading class com/sun/javafx/iio/ImageMetadata done > Event: 65.613 loading class com/sun/javafx/iio/ImageFrame > Event: 65.613 loading class com/sun/javafx/iio/ImageFrame done > Event: 65.614 loading class com/sun/javafx/iio/ImageStorage$ImageType > Event: 65.614 loading class com/sun/javafx/iio/ImageStorage$ImageType done > Event: 65.614 loading class java/lang/Throwable$WrappedPrintStream > Event: 65.614 loading class java/lang/Throwable$WrappedPrintStream done > Event: 65.614 loading class java/util/IdentityHashMap$KeySet > Event: 65.614 loading class java/util/IdentityHashMap$KeySet done > > > Dynamic libraries: > 0x00007ff600290000 - 0x00007ff6002c7000 C:\Program > Files\Java\jdk1.8.0_144\bin\java.exe > 0x00007ffc2b5f0000 - 0x00007ffc2b7cb000 C:\WINDOWS\SYSTEM32\ntdll.dll > 0x00007ffc2a0a0000 - 0x00007ffc2a14e000 C:\WINDOWS\System32\KERNEL32.DLL > 0x00007ffc28050000 - 0x00007ffc28299000 C:\WINDOWS\System32\KERNELBASE.dll > 0x00007ffc26110000 - 0x00007ffc2618e000 C:\WINDOWS\SYSTEM32\apphelp.dll > 0x00007ffc29740000 - 0x00007ffc297e1000 C:\WINDOWS\System32\ADVAPI32.dll > 0x00007ffc28e40000 - 0x00007ffc28edd000 C:\WINDOWS\System32\msvcrt.dll > 0x00007ffc2a150000 - 0x00007ffc2a1a9000 C:\WINDOWS\System32\sechost.dll > 0x00007ffc28b50000 - 0x00007ffc28c75000 C:\WINDOWS\System32\RPCRT4.dll > 0x00007ffc29910000 - 0x00007ffc29a5a000 C:\WINDOWS\System32\USER32.dll > 0x00007ffc27ce0000 - 0x00007ffc27cfe000 C:\WINDOWS\System32\win32u.dll > 0x00007ffc29fb0000 - 0x00007ffc29fd7000 C:\WINDOWS\System32\GDI32.dll > 0x00007ffc27d70000 - 0x00007ffc27ef8000 C:\WINDOWS\System32\gdi32full.dll > 0x00007ffc27fb0000 - 0x00007ffc2804a000 C:\WINDOWS\System32\msvcp_win.dll > 0x00007ffc28a50000 - 0x00007ffc28b46000 C:\WINDOWS\System32\ucrtbase.dll > 0x00007ffc1a7e0000 - 0x00007ffc1aa47000 > C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.15063.483_none_26002d27e7c744a2\COMCTL32.dll > 0x00007ffc29a60000 - 0x00007ffc29d59000 C:\WINDOWS\System32\combase.dll > 0x00007ffc27d00000 - 0x00007ffc27d6a000 > C:\WINDOWS\System32\bcryptPrimitives.dll > 0x00007ffc29080000 - 0x00007ffc290ad000 C:\WINDOWS\System32\IMM32.DLL > 0x000000006b270000 - 0x000000006b342000 C:\Program > Files\Java\jdk1.8.0_144\jre\bin\msvcr100.dll > 0x0000000069b20000 - 0x000000006a3bd000 C:\Program > Files\Java\jdk1.8.0_144\jre\bin\server\jvm.dll > 0x00007ffc29900000 - 0x00007ffc29908000 C:\WINDOWS\System32\PSAPI.DLL > 0x00007ffc16500000 - 0x00007ffc16509000 C:\WINDOWS\SYSTEM32\WSOCK32.dll > 0x00007ffc290b0000 - 0x00007ffc2911c000 C:\WINDOWS\System32\WS2_32.dll > 0x00007ffc24890000 - 0x00007ffc248b3000 C:\WINDOWS\SYSTEM32\WINMM.dll > 0x00007ffc197c0000 - 0x00007ffc197ca000 C:\WINDOWS\SYSTEM32\VERSION.dll > 0x00007ffc24830000 - 0x00007ffc2485b000 C:\WINDOWS\SYSTEM32\WINMMBASE.dll > 0x00007ffc28300000 - 0x00007ffc28349000 C:\WINDOWS\System32\cfgmgr32.dll > 0x000000006b260000 - 0x000000006b26f000 C:\Program > Files\Java\jdk1.8.0_144\jre\bin\verify.dll > 0x000000006b230000 - 0x000000006b259000 C:\Program > Files\Java\jdk1.8.0_144\jre\bin\java.dll > 0x000000006b210000 - 0x000000006b226000 C:\Program > Files\Java\jdk1.8.0_144\jre\bin\zip.dll > 0x00007ffc2a1b0000 - 0x00007ffc2b5e6000 C:\WINDOWS\System32\SHELL32.dll > 0x00007ffc29ed0000 - 0x00007ffc29f7a000 C:\WINDOWS\System32\shcore.dll > 0x00007ffc28350000 - 0x00007ffc28a43000 > C:\WINDOWS\System32\windows.storage.dll > 0x00007ffc29fe0000 - 0x00007ffc2a031000 C:\WINDOWS\System32\shlwapi.dll > 0x00007ffc27aa0000 - 0x00007ffc27ab1000 > C:\WINDOWS\System32\kernel.appcore.dll > 0x00007ffc27ac0000 - 0x00007ffc27b0c000 C:\WINDOWS\System32\powrprof.dll > 0x00007ffc27a80000 - 0x00007ffc27a95000 C:\WINDOWS\System32\profapi.dll > 0x000000006b1f0000 - 0x000000006b20a000 C:\Program > Files\Java\jdk1.8.0_144\jre\bin\net.dll > 0x00007ffc27370000 - 0x00007ffc273cc000 C:\WINDOWS\system32\mswsock.dll > 0x000000006b1d0000 - 0x000000006b1e1000 C:\Program > Files\Java\jdk1.8.0_144\jre\bin\nio.dll > 0x00007ffc27510000 - 0x00007ffc27527000 C:\WINDOWS\SYSTEM32\CRYPTSP.dll > 0x00007ffc26f90000 - 0x00007ffc26fc4000 C:\WINDOWS\system32\rsaenh.dll > 0x00007ffc27620000 - 0x00007ffc27645000 C:\WINDOWS\SYSTEM32\bcrypt.dll > 0x00007ffc27990000 - 0x00007ffc279b9000 C:\WINDOWS\SYSTEM32\USERENV.dll > 0x00007ffc27530000 - 0x00007ffc2753b000 C:\WINDOWS\SYSTEM32\CRYPTBASE.dll > 0x00007ffc27110000 - 0x00007ffc27147000 C:\WINDOWS\SYSTEM32\IPHLPAPI.DLL > 0x00007ffc29f80000 - 0x00007ffc29f88000 C:\WINDOWS\System32\NSI.dll > 0x00007ffc1cb80000 - 0x00007ffc1cb96000 C:\WINDOWS\SYSTEM32\dhcpcsvc6.DLL > 0x00007ffc1d550000 - 0x00007ffc1d56a000 C:\WINDOWS\SYSTEM32\dhcpcsvc.DLL > 0x0000000067360000 - 0x0000000069b14000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\jfxwebkit.dll > 0x00007ffc18480000 - 0x00007ffc18526000 C:\WINDOWS\SYSTEM32\MSVCP120.dll > 0x00007ffc23cb0000 - 0x00007ffc23d9f000 C:\WINDOWS\SYSTEM32\MSVCR120.dll > 0x0000000002750000 - 0x0000000002753000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-console-l1-1-0.dll > 0x0000000002760000 - 0x0000000002763000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-datetime-l1-1-0.dll > 0x0000000002770000 - 0x0000000002773000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-debug-l1-1-0.dll > 0x0000000002780000 - 0x0000000002783000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-errorhandling-l1-1-0.dll > 0x0000000002790000 - 0x0000000002794000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-file-l1-1-0.dll > 0x00000000027a0000 - 0x00000000027a3000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-file-l1-2-0.dll > 0x000000001fdc0000 - 0x000000001fdc3000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-file-l2-1-0.dll > 0x000000001fdd0000 - 0x000000001fdd3000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-handle-l1-1-0.dll > 0x000000001fde0000 - 0x000000001fde3000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-heap-l1-1-0.dll > 0x00000000212e0000 - 0x00000000212e3000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-interlocked-l1-1-0.dll > 0x00000000212f0000 - 0x00000000212f3000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-libraryloader-l1-1-0.dll > 0x0000000021300000 - 0x0000000021303000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-localization-l1-2-0.dll > 0x0000000021310000 - 0x0000000021313000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-memory-l1-1-0.dll > 0x0000000021320000 - 0x0000000021323000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-namedpipe-l1-1-0.dll > 0x0000000021330000 - 0x0000000021333000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-processenvironment-l1-1-0.dll > 0x0000000021340000 - 0x0000000021343000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-processthreads-l1-1-0.dll > 0x0000000021350000 - 0x0000000021353000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-processthreads-l1-1-1.dll > 0x0000000021360000 - 0x0000000021363000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-profile-l1-1-0.dll > 0x0000000021370000 - 0x0000000021373000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-rtlsupport-l1-1-0.dll > 0x0000000021380000 - 0x0000000021383000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-string-l1-1-0.dll > 0x00000000212d0000 - 0x00000000212d3000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-synch-l1-1-0.dll > 0x0000000021510000 - 0x0000000021513000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-synch-l1-2-0.dll > 0x0000000021520000 - 0x0000000021523000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-sysinfo-l1-1-0.dll > 0x0000000021530000 - 0x0000000021533000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-timezone-l1-1-0.dll > 0x0000000021540000 - 0x0000000021543000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-core-util-l1-1-0.dll > 0x0000000021550000 - 0x0000000021553000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-conio-l1-1-0.dll > 0x0000000021560000 - 0x0000000021564000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-convert-l1-1-0.dll > 0x0000000021570000 - 0x0000000021573000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-environment-l1-1-0.dll > 0x0000000021580000 - 0x0000000021583000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-filesystem-l1-1-0.dll > 0x0000000021590000 - 0x0000000021593000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-heap-l1-1-0.dll > 0x00000000215a0000 - 0x00000000215a3000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-locale-l1-1-0.dll > 0x00000000215b0000 - 0x00000000215b5000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-math-l1-1-0.dll > 0x00000000215c0000 - 0x00000000215c5000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-multibyte-l1-1-0.dll > 0x00000000215d0000 - 0x00000000215e0000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-private-l1-1-0.dll > 0x00000000215e0000 - 0x00000000215e3000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-process-l1-1-0.dll > 0x00000000215f0000 - 0x00000000215f4000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-runtime-l1-1-0.dll > 0x0000000021600000 - 0x0000000021604000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-stdio-l1-1-0.dll > 0x0000000021610000 - 0x0000000021614000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-string-l1-1-0.dll > 0x0000000021620000 - 0x0000000021623000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-time-l1-1-0.dll > 0x0000000021630000 - 0x0000000021633000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\api-ms-win-crt-utility-l1-1-0.dll > 0x00007ffbfe070000 - 0x00007ffbfe166000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\ucrtbase.dll > 0x00007ffc1d750000 - 0x00007ffc1d7a1000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\concrt140.dll > 0x00007ffc015b0000 - 0x00007ffc0164f000 C:\WINDOWS\SYSTEM32\MSVCP140.dll > 0x00007ffc19750000 - 0x00007ffc19766000 C:\WINDOWS\SYSTEM32\VCRUNTIME140.dll > 0x00007ffc1ea00000 - 0x00007ffc1ea16000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\vcruntime140.dll > 0x00007ffc09790000 - 0x00007ffc0982c000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\msvcp140.dll > 0x00007ffc1e9e0000 - 0x00007ffc1e9fc000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\prism_sw.dll > 0x00007ffc1d6e0000 - 0x00007ffc1d6f4000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\javafx_font.dll > 0x00007ffc291a0000 - 0x00007ffc292e5000 C:\WINDOWS\System32\ole32.dll > 0x00007ffc1de50000 - 0x00007ffc1e10f000 C:\WINDOWS\SYSTEM32\dwrite.dll > 0x00007ffc1aaf0000 - 0x00007ffc1ab02000 > C:\Users\username\Documents\projects-username-in_process\rt\build\sdk\rt\bin\prism_common.dll > 0x00007ffc26250000 - 0x00007ffc262e5000 C:\WINDOWS\system32\uxtheme.dll > 0x000000006b1c0000 - 0x000000006b1cd000 C:\Program > Files\Java\jdk1.8.0_144\jre\bin\management.dll > 0x00007ffc0cbd0000 - 0x00007ffc0cd79000 C:\WINDOWS\SYSTEM32\dbghelp.dll > > VM Arguments: > jvm_args: > -DWEB_ARCHIVE_JAR_TEST_DIR=C:\Users\username\Documents\projects-username-in_process\rt\modules\web\build\testing\resources > -Dglass.platform=Monocle -Djava.ext.dirs > -Djava.security.manager=jarjar.org.gradle.process.internal.child.BootstrapSecurityManager > -Dmonocle.platform=Headless -Dprism.order=sw -Dfile.encoding=windows-1252 > -ea > java_command: jarjar.org.gradle.process.internal.launcher.GradleWorkerMain > java_class_path (initial): > C:\Users\username\.gradle\caches\1.8\workerMain\gradle-worker.jar > Launcher Type: SUN_STANDARD > > Environment Variables: > JAVA_HOME=C:\Program Files\Java\jdk1.8.0_144 > PATH=C:\Tools\cygwin64\usr\local\bin;C:\Tools\cygwin64\bin;C:\ProgramData\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\Program > Files\Git\cmd;C:\Tools\gradle\bin;C:\Users\username\AppData\Local\Android\sdk\android-ndk-r10c;C:\Program > Files\nodejs;C:\Program Files (x86)\Yarn\bin;C:\Program Files > (x86)\Skype\Phone;C:\Program Files\Intel\WiFi\bin;C:\Program Files\Common > Files\Intel\WirelessCommon;C:\Program > Files\TortoiseHg;C:\Tools\ant-1.9.9\bin;C:\Program Files\Microsoft Windows > Performance Toolkit;C:\Program Files\Microsoft SQL > Server\110\Tools\Binn;C:\Program Files\Microsoft SQL > Server\120\Tools\Binn;C:\Program Files\Microsoft SQL > Server\130\Tools\Binn;C:\Program Files (x86)\Windows Kits\10\Windows > Performance > Toolkit;C:\Users\username\AppData\Local\Microsoft\WindowsApps;C:\Users\username\AppData\Roaming\npm;C:\Users\username\AppData\Local\Yarn\.bin;C:\Users\username\AppData\Local\atom\bin;C:\Users\username\AppData\Local\Microsoft\WindowsApps > SHELL=/bin/bash > OS=Windows_NT > PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 61 Stepping 4, GenuineIntel > > > > --------------- S Y S T E M --------------- > > OS: Windows 10.0 , 64 bit Build 15063 (10.0.15063.296) > > CPU:total 4 (initial active 4) (2 cores per cpu, 2 threads per core) family > 6 model 61 stepping 4, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, > sse4.1, sse4.2, popcnt, avx, avx2, aes, clmul, erms, 3dnowpref, lzcnt, ht, > tsc, tscinvbit, bmi1, bmi2, adx > > Memory: 4k page, physical 16478140k(7207344k free), swap 18968508k(6267284k > free) > > vm_info: Java HotSpot(TM) 64-Bit Server VM (25.144-b01) for windows-amd64 > JRE (1.8.0_144-b01), built on Jul 21 2017 21:57:33 by "java_re" with MS > VC++ 10.0 (VS2010) > > time: Tue Sep 26 15:40:58 2017 > elapsed time: 65 seconds (0d 0h 1m 5s) > > > 2017-09-26 15:37 GMT+02:00 David Bimamisa : > > >> Hi all, >> >> I solve this problem after stumbling over the following comments in the >> *buildSrc/genVSproperties.bat* file: >> *"The current officially supported Visual Studio version is 15.0 * >> *Handling of 11.0 and 14.0 is excluded here"* >> >> Thus, installing Visual Studio 2017 (VS 15.0) on the Windows 10 machine -- >> instead of VS 2010 Express as recommended in the wiki >> -- >> works for me. >> Maybe the comments above should be added to the wiki. >> >> Regards >> David >> >> >> 2017-09-25 14:18 GMT+02:00 David Bimamisa : >> >> >>> Hi all, >>> >>> I'm trying to build OpenJFX-8u on a Windows 10 machine and I stuck in the >>> test task of the fxpackager module. I'm getting the following exception: >>> >>> com.oracle.tools.packager.APITest > testRuntimes FAILED >>> java.lang.RuntimeException: Not found MSVC dlls at >>> com.oracle.tools.packager.windows.WinAppBundler.copyMSVCDLLs >>> (WinAppBundler.java:320) >>> at com.oracle.tools.packager.windows.WinAppBundler.doBundle( >>> WinAppBundler.java:277) >>> at com.oracle.tools.packager.windows.WinAppBundler.execute(WinA >>> ppBundler.java:586) >>> at com.oracle.tools.packager.APITest.testRuntimes(APITest.java: >>> 135) >>> >>> It seems that some DLLs (e.g. file:/[..]/modules/fxpackager/ >>> build/classes/test/com/oracle/tools/packager/windows//vcruntime100.dll) >>> are missing. >>> >>> Can you give some hints on how to solve this problem? >>> >>> Best regards >>> David >>> >>> >> From kevin.rushforth at oracle.com Thu Sep 28 01:10:09 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Sep 2017 18:10:09 -0700 Subject: CFV: New OpenJFX Committer: Prasanta Sadhukhan Message-ID: <59CC4BF1.5020602@oracle.com> I hereby nominate Prasanta Sadhukhan [1] to OpenJFX Committer. Prasanta is a member of JavaFX team at Oracle, who has contributed 12 changesets [2] to OpenJFX. Votes are due by October 11, 2017. Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] http://openjdk.java.net/census#psadhukhan [2] http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=20&rev=author%28psadhukhan%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From kevin.rushforth at oracle.com Thu Sep 28 01:12:20 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 27 Sep 2017 18:12:20 -0700 Subject: CFV: New OpenJFX Committer: Prasanta Sadhukhan In-Reply-To: <59CC4BF1.5020602@oracle.com> References: <59CC4BF1.5020602@oracle.com> Message-ID: <59CC4C74.1080905@oracle.com> Vote: YES Kevin Rushforth wrote: > I hereby nominate Prasanta Sadhukhan [1] to OpenJFX Committer. > > Prasanta is a member of JavaFX team at Oracle, who has contributed 12 > changesets [2] to OpenJFX. > > Votes are due by October 11, 2017. > > Only current OpenJFX Committers [3] 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 [4]. Nomination to a > project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#psadhukhan > > [2] > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=20&rev=author%28psadhukhan%29 > > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From jonathan.giles at oracle.com Thu Sep 28 01:19:03 2017 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 28 Sep 2017 14:19:03 +1300 Subject: CFV: New OpenJFX Committer: Prasanta Sadhukhan In-Reply-To: <59CC4BF1.5020602@oracle.com> References: <59CC4BF1.5020602@oracle.com> Message-ID: Vote: YES On September 28, 2017 2:10:09 PM GMT+13:00, Kevin Rushforth wrote: >I hereby nominate Prasanta Sadhukhan [1] to OpenJFX Committer. > >Prasanta is a member of JavaFX team at Oracle, who has contributed 12 >changesets [2] to OpenJFX. > >Votes are due by October 11, 2017. > >Only current OpenJFX Committers [3] 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 [4]. Nomination to a >project >Committer is described in [5]. > >Thanks. > >-- Kevin > >[1] http://openjdk.java.net/census#psadhukhan > >[2] >http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=20&rev=author%28psadhukhan%29 > >[3] http://openjdk.java.net/census#openjfx > >[4] http://openjdk.java.net/bylaws#lazy-consensus > >[5] http://openjdk.java.net/projects#project-committer From ajit.ghaisas at oracle.com Thu Sep 28 04:03:46 2017 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Wed, 27 Sep 2017 21:03:46 -0700 (PDT) Subject: CFV: New OpenJFX Committer: Prasanta Sadhukhan In-Reply-To: <59CC4BF1.5020602@oracle.com> References: <59CC4BF1.5020602@oracle.com> Message-ID: <0bf00c69-67ee-46eb-99f4-7b4945451a3a@default> Vote: YES -----Original Message----- From: Kevin Rushforth Sent: Thursday, September 28, 2017 6:40 AM To: Prasanta Sadhukhan; openjfx-dev at openjdk.java.net Subject: CFV: New OpenJFX Committer: Prasanta Sadhukhan I hereby nominate Prasanta Sadhukhan [1] to OpenJFX Committer. Prasanta is a member of JavaFX team at Oracle, who has contributed 12 changesets [2] to OpenJFX. Votes are due by October 11, 2017. Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. Thanks. -- Kevin [1] http://openjdk.java.net/census#psadhukhan [2] http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=20&rev=author%28psadhukhan%29 [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer From alexander.zvegintsev at oracle.com Thu Sep 28 04:30:48 2017 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 28 Sep 2017 10:00:48 +0530 Subject: CFV: New OpenJFX Committer: Prasanta Sadhukhan In-Reply-To: <59CC4BF1.5020602@oracle.com> References: <59CC4BF1.5020602@oracle.com> Message-ID: Vote: YES Thanks, Alexander. On 28/09/2017 06:40, Kevin Rushforth wrote: > I hereby nominate Prasanta Sadhukhan [1] to OpenJFX Committer. > > Prasanta is a member of JavaFX team at Oracle, who has contributed 12 > changesets [2] to OpenJFX. > > Votes are due by October 11, 2017. > > Only current OpenJFX Committers [3] 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 [4]. Nomination to a > project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#psadhukhan > > [2] > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=20&rev=author%28psadhukhan%29 > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From murali.billa at oracle.com Thu Sep 28 07:14:40 2017 From: murali.billa at oracle.com (Murali Billa) Date: Thu, 28 Sep 2017 00:14:40 -0700 (PDT) Subject: [10] Review request for 8187366: Remove hardcoded MSVC Version in win.gradle In-Reply-To: References: <5d429381-0799-e757-c070-827af4746317@oracle.com> <4816ea91-3506-4e52-84f6-86f04768d6f3@default> <9d808a20-87b9-4b9e-bcd8-a3a7a8ad2a20@default> <8ff1fe45-0844-4811-943a-3f76e4f9c71c@default> <667f16a9-820e-4d63-ac76-09b08b8629d1@default> Message-ID: <59b7e388-3537-41a2-bd47-fc1ce3eae3d7@default> ? Hi Kevin, Arun Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8187366 ? Webrev: http://cr.openjdk.java.net/~mbilla/8187366/webrev.01/ ? ? Thanks, Murali From guru.hb at oracle.com Thu Sep 28 09:06:18 2017 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 28 Sep 2017 14:36:18 +0530 Subject: CFV: New OpenJFX Committer: Prasanta Sadhukhan In-Reply-To: <59CC4BF1.5020602@oracle.com> References: <59CC4BF1.5020602@oracle.com> Message-ID: Vote: YES > On 28-Sep-2017, at 6:40 AM, Kevin Rushforth wrote: > > I hereby nominate Prasanta Sadhukhan [1] to OpenJFX Committer. > > Prasanta is a member of JavaFX team at Oracle, who has contributed 12 changesets [2] to OpenJFX. > > Votes are due by October 11, 2017. > > Only current OpenJFX Committers [3] 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 [4]. Nomination to a project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#psadhukhan > > [2] http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=20&rev=author%28psadhukhan%29 > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From semyon.sadetsky at oracle.com Thu Sep 28 14:51:41 2017 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 28 Sep 2017 07:51:41 -0700 Subject: CFV: New OpenJFX Committer: Prasanta Sadhukhan In-Reply-To: <59CC4BF1.5020602@oracle.com> References: <59CC4BF1.5020602@oracle.com> Message-ID: <59CD0C7D.1000905@oracle.com> Vote: YES On 9/27/2017 6:10 PM, Kevin Rushforth wrote: > I hereby nominate Prasanta Sadhukhan [1] to OpenJFX Committer. > > Prasanta is a member of JavaFX team at Oracle, who has contributed 12 > changesets [2] to OpenJFX. > > Votes are due by October 11, 2017. > > Only current OpenJFX Committers [3] 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 [4]. Nomination to a > project Committer is described in [5]. > > Thanks. > > -- Kevin > > [1] http://openjdk.java.net/census#psadhukhan > > [2] > http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=20&rev=author%28psadhukhan%29 > > [3] http://openjdk.java.net/census#openjfx > > [4] http://openjdk.java.net/bylaws#lazy-consensus > > [5] http://openjdk.java.net/projects#project-committer > From javafx at use.startmail.com Thu Sep 28 22:59:36 2017 From: javafx at use.startmail.com (javafx at use.startmail.com) Date: Thu, 28 Sep 2017 18:59:36 -0400 Subject: Error on build Message-ID: <4e4d9f34d37d5c35b0e52964beb8b4a5.startmail@www.startmail.com> Hi All, New member to this group. I am encountering a little trouble ?when I try to build OpenJFX. I am following the instructions here:?(using Cygwin on Win 7): https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX When I run gradle after cloning the OpenJFX repository,?I get a "build failed with exception" . I include the output from the entire run just in case it's significant: $ gradle WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.gradle.internal.reflect.JavaMethod (file:/C:/gradle/lib/gradle-base-services-3.1.jar) to method java.lang.ClassLoader.getPackages() WARNING: Please consider reporting this to the maintainers of org.gradle.internal.reflect.JavaMethod WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release :buildSrc:generateGrammarSource UP-TO-DATE :buildSrc:compileJava UP-TO-DATE :buildSrc:compileGroovy UP-TO-DATE :buildSrc:processResources UP-TO-DATE :buildSrc:classes UP-TO-DATE :buildSrc:jar UP-TO-DATE :buildSrc:assemble UP-TO-DATE :buildSrc:compileTestJava UP-TO-DATE :buildSrc:compileTestGroovy UP-TO-DATE :buildSrc:processTestResources UP-TO-DATE :buildSrc:testClasses UP-TO-DATE :buildSrc:test UP-TO-DATE :buildSrc:check UP-TO-DATE :buildSrc:build UP-TO-DATE FAILURE: Build failed with an exception. * Where: Script 'C:\cygwin64\home\mdbg\rt\buildSrc\win.gradle' line: 91 * What went wrong: A problem occurred evaluating script. > FAIL: WINSDK_DIR not defined * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED Total time: 1.376 secs I should add that even though the tutorial doesn't mention to do it, I cd-ed into the folder named rt, which was created by Mercurial when I cloned OpenJFX,??I called gradle from there. Calling it from the directory containing rt resulted in nothing happening , which makes sense afaik. the variable WINSDK is? not one I am familiar with- it's not any environment or system variable on my machine and the tutorial doesn't say anything about it. I hesitate to start arbitrarily hacking build files based on error messages. It seems as though it ought to just work and perhaps this is a bug I should report or is it something else ? Thank you! From toni.epple at eppleton.de Sat Sep 30 09:18:41 2017 From: toni.epple at eppleton.de (Anton Epple) Date: Sat, 30 Sep 2017 11:18:41 +0200 Subject: PulseLogger negative start time Message-ID: Hi, I need some help interpreting PulseLogger output. Sometimes I see log messages like this: [947 16ms:0ms] PULSE: 948 [2051ms:201ms] T13 (-2051 +2051ms): Layout Pass T13 (0 +2ms): CSS Pass T13 (2 +147ms): Layout Pass T13 (149 +1ms): Update bounds T13 (151 +0ms): Waiting for previous rendering T13 (151 +1ms): Copy state to render graph T10 (153 +0ms): Dirty Opts Computed T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow shape path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 : Slow background path for null T10 (153 +47ms): Painting T10 (200 +0ms): Presenting Counters: ??????????????? NGRegion renderBackgroundShape slow path: 12 ??????????????? NGRegion renderBackgrounds slow path: 22 ??????????????? Nodes rendered: 1086 ??????????????? Nodes visited during render: 1159 [949 175ms:65ms] Pulse 948 shows an initial Layout Pass starting at -2051ms. Does this Layout pass with its negative starting point really belong to pulse 948, or is this a bug? The project has a single scene. I?m running this on a mac (OS X 10.12.6) with? java 1.8.0_112-b16 (Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16, mixed mode)) with Options: -Djavafx.pulseLogger=true -Djavafx.pulseLogger.threshold=100 Thanks Toni Epple From neacsu.cristianstefan at gmail.com Sat Sep 30 13:04:09 2017 From: neacsu.cristianstefan at gmail.com (Neacsu Cristian) Date: Sat, 30 Sep 2017 16:04:09 +0300 Subject: PulseLogger negative start time In-Reply-To: References: Message-ID: Same happens here. I am very interested in a reply. Negative numbers appears only for Layout pass. Thank you in advance. Cristian-Stefan On Sat, Sep 30, 2017 at 12:18 PM, Anton Epple wrote: > Hi, > > > > I need some help interpreting PulseLogger output. Sometimes I see log messages like this: > > > > [947 16ms:0ms] > > > > PULSE: 948 [2051ms:201ms] > > T13 (-2051 +2051ms): Layout Pass > > T13 (0 +2ms): CSS Pass > > T13 (2 +147ms): Layout Pass > > T13 (149 +1ms): Update bounds > > T13 (151 +0ms): Waiting for previous rendering > > T13 (151 +1ms): Copy state to render graph > > T10 (153 +0ms): Dirty Opts Computed > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow shape path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 : Slow background path for null > > T10 (153 +47ms): Painting > > T10 (200 +0ms): Presenting > > Counters: > > NGRegion renderBackgroundShape slow path: 12 > > NGRegion renderBackgrounds slow path: 22 > > Nodes rendered: 1086 > > Nodes visited during render: 1159 > > > > [949 175ms:65ms] > > > > Pulse 948 shows an initial Layout Pass starting at -2051ms. Does this Layout pass with its negative starting point really belong to pulse 948, or is this a bug? > > > > The project has a single scene. I?m running this on a mac (OS X 10.12.6) with java 1.8.0_112-b16 (Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16, mixed mode)) with Options: -Djavafx.pulseLogger=true -Djavafx.pulseLogger.threshold=100 > > > > Thanks > > > > Toni Epple > > >