Re: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer
Looks good to me, too. -- Kevin Laurent Bourgès wrote: Jim, It looks good to me (even I am not an official reviewer) and the Marlin Double-precision will be the default rasterizer. Bye, Laurent Le 14 avr. 2017 22:32, "Jim Graham" a écrit : JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ The only way to get one of the old Pisces rasterizers now is to manually disable Marlin (or use the new order option as follows). This fix also introduces a similar pattern for rasterizer selection that we use for pipeline selection: -Dprism.rasterizerorder=listof( marlin|marlinfloat|marlindouble| pisces|javapisces|nativepisces| *) (unknown values are ignored for future/backwards-proofing) Suggestions for naming of the new rasterizer identifiers and the "public name" strings are welcome... ...jim
Re: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer
Yes... ...jim On 4/14/17 1:45 PM, Michael Paus wrote: Will marlindouble remain the default when you say nothing or when you specify just marlin? Am 14.04.17 um 22:31 schrieb Jim Graham: JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ The only way to get one of the old Pisces rasterizers now is to manually disable Marlin (or use the new order option as follows). This fix also introduces a similar pattern for rasterizer selection that we use for pipeline selection: -Dprism.rasterizerorder=listof( marlin|marlinfloat|marlindouble| pisces|javapisces|nativepisces| *) (unknown values are ignored for future/backwards-proofing) Suggestions for naming of the new rasterizer identifiers and the "public name" strings are welcome... ...jim
Re: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer
Jim, It looks good to me (even I am not an official reviewer) and the Marlin Double-precision will be the default rasterizer. Bye, Laurent Le 14 avr. 2017 22:32, "Jim Graham" a écrit : > JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 > webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ > > The only way to get one of the old Pisces rasterizers now is to manually > disable Marlin (or use the new order option as follows). > > This fix also introduces a similar pattern for rasterizer selection that > we use for pipeline selection: > > -Dprism.rasterizerorder=listof( > marlin|marlinfloat|marlindouble| > pisces|javapisces|nativepisces| > *) > (unknown values are ignored for future/backwards-proofing) > > Suggestions for naming of the new rasterizer identifiers and the "public > name" strings are welcome... > > ...jim >
Re: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer
Will marlindouble remain the default when you say nothing or when you specify just marlin? Am 14.04.17 um 22:31 schrieb Jim Graham: JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ The only way to get one of the old Pisces rasterizers now is to manually disable Marlin (or use the new order option as follows). This fix also introduces a similar pattern for rasterizer selection that we use for pipeline selection: -Dprism.rasterizerorder=listof( marlin|marlinfloat|marlindouble| pisces|javapisces|nativepisces| *) (unknown values are ignored for future/backwards-proofing) Suggestions for naming of the new rasterizer identifiers and the "public name" strings are welcome... ...jim
Re: [10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer
I was going to tag Kevin and Laurent on this, but forgot to amend the address lines before I hit send... ...jim On 4/14/17 1:31 PM, Jim Graham wrote: JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ The only way to get one of the old Pisces rasterizers now is to manually disable Marlin (or use the new order option as follows). This fix also introduces a similar pattern for rasterizer selection that we use for pipeline selection: -Dprism.rasterizerorder=listof( marlin|marlinfloat|marlindouble| pisces|javapisces|nativepisces| *) (unknown values are ignored for future/backwards-proofing) Suggestions for naming of the new rasterizer identifiers and the "public name" strings are welcome... ...jim
[10] Review request: 8177985 Use Marlin renderer as the default FX rasterizer
JBS: https://bugs.openjdk.java.net/browse/JDK-8177985 webrev: http://cr.openjdk.java.net/~flar/JDK-8177985/webrev.00/ The only way to get one of the old Pisces rasterizers now is to manually disable Marlin (or use the new order option as follows). This fix also introduces a similar pattern for rasterizer selection that we use for pipeline selection: -Dprism.rasterizerorder=listof( marlin|marlinfloat|marlindouble| pisces|javapisces|nativepisces| *) (unknown values are ignored for future/backwards-proofing) Suggestions for naming of the new rasterizer identifiers and the "public name" strings are welcome... ...jim
Re: Canvas Content Shift
On 4/14/17 7:36 AM, Michael Paus wrote: For my Mac (Retina) I know that the renderScale is 2.0 but how do you find that out in the general case? In JDK 9 you have: Screen.getOutputScaleX/Y() Window.outputScaleX/Y (read-only double properties, based on Screen values) Window.renderScaleX/Y (get/set double properties, default to output scales) Window.forceIntegerRenderScale (get/set boolean property) In the case of Canvas, though, since we can't re-render currently (we have an outstanding wish-list item to add invalidation and repaint capabilities to it so we can make the data non-persistent) we have to choose the largest rendering scale that we might ever need - which is basically the max of all of the Screen output scales. We need to add (for 10, too late for 9): Canvas.renderScaleX/Y properties, gettable for all, settable only for non-persistent canvas objects and maybe: Canvas.repaint/validate/etc. for enabling non-persistence ...jim
Re: Canvas Content Shift
I think we can agree that this is kind of an expert feature but you
definitely need such features
for any high-level interface if you want to achieve a good performance.
The root of the problems you have described is the same as the one you
are already confronted
with today when you want to make a clear and crisp snapshot of a canvas.
A simple snapshot on
a system with pixel scaling is blurry and totally unusable. In order to
avoid this I use the code below.
public static WritableImage renderScaleAwareCanvasSnapshot(Canvas
canvas, double renderScale, WritableImage writableImage) {
if (writableImage == null ||
(int)Math.rint(writableImage.getWidth()) !=
(int)Math.rint(renderScale*canvas.getWidth()) ||
(int)Math.rint(writableImage.getHeight()) !=
(int)Math.rint(renderScale*canvas.getHeight())) {
writableImage = new
WritableImage((int)Math.rint(renderScale*canvas.getWidth()),
(int)Math.rint(renderScale*canvas.getHeight()));
}
SnapshotParameters spa = new SnapshotParameters();
spa.setTransform(Transform.scale(renderScale, renderScale));
return canvas.snapshot(spa, writableImage);
}
For my Mac (Retina) I know that the renderScale is 2.0 but how do you
find that out in the general case?
I am asking for such an API already for quite a while. Once you know the
renderScale things become easy.
In principle you can do the canvas shift already right now by using the
above code, although the performance will
of course be sub-optimal. That's the reason why we ask for a more
specific API here so that ideally this
shift could be done completely on the graphics hardware.
Michael
Am 10.04.17 um 20:17 schrieb Jim Graham:
Any suggestions on how to implement this when the size of pixels may
be an arbitrary non-integer number?
Consider rendering on a 125% scaled Windows 10 screen. If you want to
scroll by 2 pixels you would want to scroll by 1.6 coordinate units.
If you want to scroll by 2 coordinate units you are out of luck
because that would attempt to "scroll by 2.5 pixels" and there is no
good definition of that type of operation.
We could add a pixel size parameter (note that it might be different
than the window or screen render scale because the Canvas cannot
re-render and so it chooses the scale of the deepest screen). Then it
would be up to the developer to take this into account when
determining how far to scroll, but that is a bit more complicated than
what developers tend to be used to when they deal with scrolling.
Note that the scrolling of JViewport is handled by our own code, not
developer code, so we can take these adjustments into account
ourselves internally and know if/when we can blit or if/when we need
to re-render...
...jim
On 4/10/17 1:32 AM, Dirk Lemmermann wrote:
HI there,
I was wondering if there is any chance that Java 10 could implement
some sort of „content shifting“ for the Canvas API?
I would love to have this feature for supporting faster horizontal
scrolling in my Gantt Chart framework FlexGanttFX. Currently when the
user scrolls then the entire content of each canvas in each row of
the chart will be redrawn. This could be optimized by only drawing
the time range that has been moved into the „viewport“ and by
shifting or copying the remaining time range graphics. E.g. the user
currently looks at one week and scrolls one day to the right then the
data / graphics of 6 days would stay the same and could just be
reused. Only one day worth of data would need to be redrawn.
I think in Swing this is comparable with the BLIT_SCROLL_MODE of
JViewport.
Dirk
Re: PathTransition jitter
And here is the direct link in JBS:
https://bugs.openjdk.java.net/browse/JDK-8178805
-- Kevin
Jose Martinez wrote:
Thank you Kevin.
For those interested here is the bug report:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805
From: Kevin Rushforth
To: Jose Martinez
Cc: "openjfx-dev@openjdk.java.net"
Sent: Thursday, April 13, 2017 7:49 AM
Subject: Re: PathTransition jitter
One more thing: all bugs were transfered from the old JavaFX JIRA intoJBS in June 2015. You can find the ones you filed using this query:
https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx
-- Kevin
Jose Martinez wrote:
In case it helps, below is the original workaround that was provided. This
workaround no longer has any affect.
public class FixedPane extends Group {@Override
public BaseBounds impl_computeGeomBounds(BaseBounds bounds, BaseTransform
tx) {
if (!tx.isTranslateOrIdentity()) {
super.impl_computeGeomBounds(bounds,
BaseTransform.IDENTITY_TRANSFORM);
}
return super.impl_computeGeomBounds(bounds, tx);
}
}
Forgot to include: using a Windows 10 and Geforce gtx GPU.
From: Tom Eugelink
To: openjfx-dev@openjdk.java.net
Sent: Thursday, April 13, 2017 3:15 AM
Subject: Re: PathTransition jitter
I'm seeing some very small irregularities; short hesitations and then small jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD FirePro M5950 GPU, Windows 10 x64)
Slowing the animation to 8 instead of 4 seconds, make these hiccups better
visible. They're most definitely there.
On 13-4-2017 08:46, Michael Paus wrote:
It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea.
Am 13.04.17 um 04:25 schrieb Jose Martinez:
Many moons ago I complained about jittery PathTransition animation. A bug was openned and I was provided a workaround. This was with Java 7. I revisted the old project that lead to that initial complain, this time with Java 8. The problem seems to be back. I could not find the old bugreport, since I think the JavaFX team is not using the same bug trackingsite.
Below is the test code to reproduce. I tried it using JDK 8_64 u5, u11, u25,
u112, u121 and the problem occurs with all of them. The ImageViewstutters
through the PathTransition. I have a new laptop with 6th gen I7 and plenty of
ram. I do not think it is the hardware. This used to besmooth like butter.
Anyone else experiencing this or can make any suggestions?
@Override
public void start(Stage primaryStage) {String rocketImgStr=
"iVBORw0KGgoNSUhEUgAAADIdCAYAAADoxT9SCXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph
CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz
0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/
Re: JavaFX graphics performance
If what you want is the best performance than neither JavaFX nor web technologies will do. Qt as you mentioned will be much faster and it has native support for embedding OpenGL. In addition you can combine Qt with native optimizations for specific platforms. You can even add inline assembly in order to do very specific optimizations. Hand optimized assembly by a skilled developer will never be outperformed by anything else. The problem with these things of course is that they add a lot of work. Writing Qt code requires you to handle memory and threads and I can constantly see Qt developers failing at this. The VLC UI is written in Qt and it spits out a decent amount of Qt errors on the conseole, and that is probably one of the most well written Qt applications. We have the entire KDE ecosystem based on Qt which is infamous for it's many bugs. And assembly programming of course is a lot more problematic. In order to outperform pre-existing system libraries you sometimes need to know undocumented instructions used by system libraries. This is less of a problem today than it was 20 years ago but it still takes a lot to be good at assembly programming. However this is the JavaFX mailing list so in order to stay on topic I think the discussion should be about how to improve JavaFX performance. Some problems of course are related to the JavaFX code itself, others are rooted in the Java architecture and in JVM memory management. The fact that doing something similar to C/C++ structs and "pragma align" requires ninja level trickery is a problem. I don't know if this is a problem for OpenGL but sometimes when integrating with external systems the lack of "unsigned" is also a real problem, it's probably not a performance problem but writing correct code that deals with data containing unisgned integers can be quite a mess. I don't know OpenGL data structures well enough but in many Internet protocols there are lots of unsigened data to be processed. Also many file formats has that problem. When we are trying to interface Java with low level data such as OpenGL data structures we must recognise that we may need to take these things into consideration for upcoming versions of the JVM. One problem of course are how to deal with these kind of data structures while preserving data integrity and the Java way of doing bounds checking. This is also a big issue I have with the current hacks one have to perform in order to deal with data structures, dealing with large arrays moves the responsibility of data integrity to the application which of course is a breeding ground for bugs. On Tue, 11 Apr 2017 15:26:52 +0200 Nikos Nikolos wrote: > Here is a copy of a previous post I sent, needs are still the same on my > side and I don't see anything coming from the JavaFX side... > > > OpenGL rendering was a nice solution for performance intensive application > on the desktop. Since JavaFX doesn't offer a native OpenGL handle you can > use such a solution. > > > CSS and layout improvement are quite out of scope for the inital needs I > think. > > > Electron is becoming trendy maybe with some WebGL inside it you will be > able to outperform JavaFX rendering speed! > > > I really enjoyed desktop GUI development in Java but them came JavaFX... > > > > > Following the thread http://mail.openjdk.java.net/ > pipermail/openjfx-dev/2016-December/020025.html I would like to ask for > more information on JavaFX plan to allow a simple way to use existing > OpenGL code. > > > > I know this is not a new question and please forgive me if I’ve overlooked > some answers already posted. > > > > I work in the niche area where desktop applications are still needed and > use Swing since 2001, integrated Jogl and then Jogamp since 2006 and that > try to figure out how we can use JavaFX without a huge performance drop. I > think this bug https://bugs.openjdk.java.net/browse/JDK-8091324 is the best > summary of potential needs. And the answer gave by Kevin Rushforth was > quite disappointing. > > > > I remember Swing teams members (Kenneth Bradley Russell) working hard to > have a nice way to use OpenGL in a platform independent manner which is one > of the strength of Java. JOGAMP team also made a good work more recently. > > > > Some tricks have been used to try to provide a solution: > > · https://github.com/SkyLandTW/JOGL-FX#jogl-on-javafx-es2 > > · https://github.com/pepe1914/jfx-zoglpipeline > > · https://www.youtube.com/watch?v=aYRF34UYu-E > > But they are very fragile (use of internal classes, rebundling JavaFx > jars…). > > > > Is this need too specific for a change to have it implemented in JavaFX? > > Going on with Swing is a potential solution but it won’t resist a > comparison with QT long. > > > > Thanks for any of your ideas on that. > > Regards > > > > -- Message transféré -- > From: Mattias Eliasson > To: openjfx-dev@openjd
Re: PathTransition jitter
Thank you Kevin.
For those interested here is the bug report:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8178805
From: Kevin Rushforth
To: Jose Martinez
Cc: "openjfx-dev@openjdk.java.net"
Sent: Thursday, April 13, 2017 7:49 AM
Subject: Re: PathTransition jitter
One more thing: all bugs were transfered from the old JavaFX JIRA intoJBS in
June 2015. You can find the ones you filed using this query:
https://bugs.openjdk.java.net/issues/?jql=reporter%3Djmartinezjfx
-- Kevin
Jose Martinez wrote:
In case it helps, below is the original workaround that was provided. This
workaround no longer has any affect.
public class FixedPane extends Group { @Override
public BaseBounds impl_computeGeomBounds(BaseBounds bounds, BaseTransform
tx) {
if (!tx.isTranslateOrIdentity()) {
super.impl_computeGeomBounds(bounds,
BaseTransform.IDENTITY_TRANSFORM);
}
return super.impl_computeGeomBounds(bounds, tx);
}
}
Forgot to include: using a Windows 10 and Geforce gtx GPU.
From: Tom Eugelink
To: openjfx-dev@openjdk.java.net
Sent: Thursday, April 13, 2017 3:15 AM
Subject: Re: PathTransition jitter
I'm seeing some very small irregularities; short hesitations and then small
jumps ahead. Nothing major, but it is not totally smooth. (2.6GHz Intel i5, AMD
FirePro M5950 GPU, Windows 10 x64)
Slowing the animation to 8 instead of 4 seconds, make these hiccups better
visible. They're most definitely there.
On 13-4-2017 08:46, Michael Paus wrote:
It runs perfectly smooth on my old MacBook Pro from 2012 with JDK 8u152 ea.
Am 13.04.17 um 04:25 schrieb Jose Martinez:
Many moons ago I complained about jittery PathTransition animation. A bug was
openned and I was provided a workaround. This was with Java 7. I revisted the
old project that lead to that initial complain, this time with Java 8. The
problem seems to be back. I could not find the old bugreport, since I think
the JavaFX team is not using the same bug trackingsite.
Below is the test code to reproduce. I tried it using JDK 8_64 u5, u11, u25,
u112, u121 and the problem occurs with all of them. The ImageViewstutters
through the PathTransition. I have a new laptop with 6th gen I7 and plenty of
ram. I do not think it is the hardware. This used to besmooth like butter.
Anyone else experiencing this or can make any suggestions?
@Override
public void start(Stage primaryStage) { String rocketImgStr=
"iVBORw0KGgoNSUhEUgAAADIdCAYAAADoxT9SCXBIWXMAAAsYAAALGAGJqbUQAAAKT2lDQ1BQaG90b3Nob3AgSUNDIHByb2ZpbGUAAHjanVNnVFPpFj333vRCS4iAlEtvUhUIIFJCi4AUkSYqIQkQSoghodkVUcERRUUEG8igiAOOjoCMFVEsDIoK2AfkIaKOg6OIisr74Xuja9a89+bN/rXXPues852zzwfACAyWSDNRNYAMqUIeEeCDx8TG4eQuQIEKJHAAEAizZCFz/SMBAPh+PDwrIsAHvgABeNMLCADATZvAMByH/w/qQplcAYCEAcB0kThLCIAUAEB6jkKmAEBGAYCdmCZTAKAEAGDLY2LjAFAtAGAnf+bTAICd+Jl7AQBblCEVAaCRACATZYhEAGg7AKzPVopFAFgwABRmS8Q5ANgtADBJV2ZIALC3AMDOEAuyAAgMADBRiIUpAAR7AGDIIyN4AISZABRG8lc88SuuEOcqAAB4mbI8uSQ5RYFbCC1xB1dXLh4ozkkXKxQ2YQJhmkAuwnmZGTKBNA/g88wAAKCRFRHgg/P9eM4Ors7ONo62Dl8t6r8G/yJiYuP+5c+rcEAAAOF0ftH+LC+zGoA7BoBt/qIl7gRoXgugdfeLZrIPQLUAoOnaV/Nw+H48PEWhkLnZ2eXk5NhKxEJbYcpXff5nwl/AV/1s+X48/Pf14L7iJIEyXYFHBPjgwsz0TKUcz5IJhGLc5o9H/LcL//wd0yLESWK5WCoU41EScY5EmozzMqUiiUKSKcUl0v9k4t8s+wM+3zUAsGo+AXuRLahdYwP2SycQWHTA4vcAAPK7b8HUKAgDgGiD4c93/+8//UegJQCAZkmScQAAXkQkLlTKsz/HCAAARKCBKrBBG/TBGCzABhzBBdzBC/xgNoRCJMTCQhBCCmSAHHJgKayCQiiGzbAdKmAv1EAdNMBRaIaTcA4uwlW4Dj1wD/ph
CJ7BKLyBCQRByAgTYSHaiAFiilgjjggXmYX4IcFIBBKLJCDJiBRRIkuRNUgxUopUIFVIHfI9cgI5h1xGupE7yAAygvyGvEcxlIGyUT3UDLVDuag3GoRGogvQZHQxmo8WoJvQcrQaPYw2oefQq2gP2o8+Q8cwwOgYBzPEbDAuxsNCsTgsCZNjy7EirAyrxhqwVqwDu4n1Y8+xdwQSgUXACTYEd0IgYR5BSFhMWE7YSKggHCQ0EdoJNwkDhFHCJyKTqEu0JroR+cQYYjIxh1hILCPWEo8TLxB7iEPENyQSiUMyJ7mQAkmxpFTSEtJG0m5SI+ksqZs0SBojk8naZGuyBzmULCAryIXkneTD5DPkG+Qh8lsKnWJAcaT4U+IoUspqShnlEOU05QZlmDJBVaOaUt2ooVQRNY9aQq2htlKvUYeoEzR1mjnNgxZJS6WtopXTGmgXaPdpr+h0uhHdlR5Ol9BX0svpR+iX6AP0dwwNhhWDx4hnKBmbGAcYZxl3GK+YTKYZ04sZx1QwNzHrmOeZD5lvVVgqtip8FZHKCpVKlSaVGyovVKmqpqreqgtV81XLVI+pXlN9rkZVM1PjqQnUlqtVqp1Q61MbU2epO6iHqmeob1Q/pH5Z/YkGWcNMw09DpFGgsV/jvMYgC2MZs3gsIWsNq4Z1gTXEJrHN2Xx2KruY/R27iz2qqaE5QzNKM1ezUvOUZj8H45hx+Jx0TgnnKKeX836K3hTvKeIpG6Y0TLkxZVxrqpaXllirSKtRq0frvTau7aedpr1Fu1n7gQ5Bx0onXCdHZ4/OBZ3nU9lT3acKpxZNPTr1ri6qa6UbobtEd79up+6Ynr5egJ5Mb6feeb3n+hx9L/1U/W36p/VHDFgGswwkBtsMzhg8xTVxbzwdL8fb8VFDXcNAQ6VhlWGX4YSRudE8o9VGjUYPjGnGXOMk423GbcajJgYmISZLTepN7ppSTbmmKaY7TDtMx83MzaLN1pk1mz
0x1zLnm+eb15vft2BaeFostqi2uGVJsuRaplnutrxuhVo5WaVYVVpds0atna0l1rutu6cRp7lOk06rntZnw7Dxtsm2qbcZsOXYBtuutm22fWFnYhdnt8Wuw+6TvZN9un2N/T0HDYfZDqsdWh1+c7RyFDpWOt6azpzuP33F9JbpL2dYzxDP2DPjthPLKcRpnVOb00dnF2e5c4PziIuJS4LLLpc+Lpsbxt3IveRKdPVxXeF60vWdm7Obwu2o26/uNu5p7ofcn8w0nymeWTNz0MPIQ+BR5dE/C5+VMGvfrH5PQ0+BZ7XnIy9jL5FXrdewt6V3qvdh7xc+9j5yn+M+4zw33jLeWV/MN8C3yLfLT8Nvnl+F30N/I/9k/3r/0QCngCUBZwOJgUGBWwL7+Hp8Ib+OPzrbZfay2e1BjKC5QRVBj4KtguXBrSFoyOyQrSH355jOkc5pDoVQfujW0Adh5mGLw34MJ4WHhVeGP45wiFga0TGXNXfR3
Re: JavaFX graphics performance
For those who are interested. Here is the missing link: "Excessive memory consumption in TriangleMesh/MeshView" https://bugs.openjdk.java.net/browse/JDK-8178804 Michael Am 13.04.17 um 14:28 schrieb Michael Paus: Hi, I have done that already here "Severe performance drop for scene graph path rendering." https://bugs.openjdk.java.net/browse/JDK-8178521 and another one for which I do not have the link yet. "Excessive memory consumption in TriangleMesh/MeshView" Internal review ID : 9048570 Michael Am 10.04.17 um 22:08 schrieb Kevin Rushforth: We are planning some performance improvements in JDK 10, mostly in the areas of CSS and layout. If you have specific concerns in other areas we could look into them. Having a specific test case that shows a performance problem would be a good start. -- Kevin Michael Paus wrote: Hi, more and more people ask me why I am still doing GUI development in JavaFX instead of following the mainstream and use some web technology. One of the arguments I could use in the past was performance but nowadays this does not seem to be such a valid argument anymore. Web technologies are catching up quickly and JavaFX currently has not much to offer here. Actually the general drawing performance is very bad compared to what is in principle possible with a modern GPU. I even tried to use a TriangleMesh to better exploit the graphics hardware but this approach is also limited by the fact that a TrinangleMesh has an excessive memory usage (about 60 times its nominal memory consumption). I would therefore like to ask whether there are already any plans for Java 10 to improve this situation? Michael
Review Request [JDK 8] - 8087545:Line separator is broken in the clipboard of WebView
Hi Philip, Kevin, Please review the fix for : JBS: https://bugs.openjdk.java.net/browse/JDK-8087545 Webrev: http://cr.openjdk.java.net/~asrivastava/dipak/8087545/webrev.00/ I have tested the fix on Win64 and Junit test case run was fine. Many thanks, Dipak
