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
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.ja
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-817798
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 ra
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/
T
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
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 (g
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 mak
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 Martine
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
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
O
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 r
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
13 matches
Mail list logo