and
accurate whether the entire path is EO or NZ...
...jim
On 8/31/17 4:15 PM, Jim Graham wrote:
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
pre-clip this" or "not" then this isn't really
needed - just add the necessary logic to Renderer instead...
...jim
On 8/31/17 4:15 PM, Jim Graham wrote:
First, consider what is handled inside the guts of the Renderer process.
- It doesn't need t
First, consider what is handled inside the guts of the Renderer process.
- It doesn't need to process any segments above or below the clip, they have no impact on the rendered pieces inside the
clip
- It needs to process segments that are out-left only in so far as it needs to come up with a pro
the DDA stuff is just as good as any other technique for accomplishing that and since we have to do the DDA stuff
anyway, we can just piggy-back off of that. When it calls addLine(), we will reject each of its pieces individually...
...jim
On 8/31/17 12:45 PM, Jim Graha
accuracy
(cups...)
Hope you will have time soon to look at the webrev, your feedback may help a
lot.
Cheers,
Laurent
Le 29 août 2017 2:58 AM, "Jim Graham" mailto:james.gra...@oracle.com>> a écrit :
Hi Laurent,
On 8/28/17 2:09 PM, Laurent Bourgès wrote:
Hi Jim,
Hi Laurent,
On 8/28/17 2:09 PM, Laurent Bourgès wrote:
Hi Jim,
Thanks for your comments, it helped refining the webrev.
Here are my answers:
2017-08-26 2:22 GMT+02:00 Jim Graham mailto:james.gra...@oracle.com>>:
[D]Dasher.java - why the changes from (firstSegIdx > 0) to (fi
Hi Laurent,
I'm just reading through the code now to get a handle on the nature of the
changes...(and starting with the 2D version)...
[D]Dasher.java - why the changes from (firstSegIdx > 0) to (firstSegIdx != 0)?
[D]Dasher.java - why is there a new goto_starting() which is only used from one p
This looks good... +1
...jim
On 8/3/17 9:20 PM, Prasanta Sadhukhan wrote:
On 8/4/2017 2:57 AM, Jim Graham wrote:
I noticed a "FIXME" comment in there. Didn't we do a pass a while back and
convert all of them into JBS entries?
The new code simply r
I noticed a "FIXME" comment in there. Didn't we do a pass a while back and
convert all of them into JBS entries?
The new code simply repeats what was done for the existing Exception which is what has the "FIXME" comment so I would
use this opportunity to upgrade that FIXME into an actual bug e
JBS: https://bugs.openjdk.java.net/browse/JDK-8183530
webrev: http://cr.openjdk.java.net/~flar/JDK-8183530/webrev.03/
...jim
inez wrote:
Just curious, did this make it to the 8u144 release? If not, any idea which
release (or when) we can expect it?
Thank youjose
On Wednesday, May 24, 2017 08:38:41 PM EDT, Jim Graham
wrote:
Thanks Tom, I've already posted a patch for 8180938 (lazy property creat
JBS: https://bugs.openjdk.java.net/browse/JDK-8181976
webrev: http://cr.openjdk.java.net/~flar/JDK-8181976/webrev.00/
Simple fix is to carry the double "size requested" values all the way down to where the image pixel scale is determined
(not strictly required, but important for precision) and t
Vote: yes
...jim
On 5/26/17 5:20 AM, Kevin Rushforth wrote:
I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer.
Ajit is a member of JavaFX team at Oracle, who has contributed 10 changesets to OpenJFX. A list of these changesets is
available by the following link:
http:/
eview...
...jim
On 5/24/17 3:42 AM, Tom Schindl wrote:
Hi,
I created:
- https://bugs.openjdk.java.net/browse/JDK-8180935
- https://bugs.openjdk.java.net/browse/JDK-8180938
I'll work on a showcase to find out how much memory one can save.
Tom
On 04.05.17 23:33, Jim Graham wrote:
Hi Tom,
Those
This looks good. Did you create a JBS bug?
...jim
On 5/16/17 2:11 PM, Laurent Bourgès wrote:
Finally I propose another MarlinFX webrev:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-075.2/
Changes:
- (D)Helpers: revert syntax changed in cubicRootsInAB() + fixe
That's fine, I just wanted to make sure the difference was intentional and not
something that fell through the cracks...
...jim
On 5/16/17 2:17 PM, Laurent Bourgès wrote:
One more comment about '(D)RendererSharedMemory in FX, but not 2D':
This reduces the memory footpr
linFX-075.1/openjfx10.patch
Regards,
Laurent
2017-04-26 7:06 GMT+02:00 Jim Graham :
I've reviewed the code and run a number of tests. Things look fine.
I spotted at least one thing that I brought up in the 2D Marlin review,
but since the 2 source bases are moving towards synchronizing wi
JBS: https://bugs.openjdk.java.net/browse/JDK-8179946
webrev: http://cr.openjdk.java.net/~flar/JDK-8179946/webrev.00/
This should get back-ported to 9 as well, as soon as makes sense...
...jim
Hi Tom,
Those look like good suggestions. I would file bugs in JBS and create them
separately:
- Bug for lazy property creation in path elements
- Feature request for lower-memory paths
Did you benchmark how much the lazy properties, on their own, would save your
application?
Hi Laurent,
On 4/26/17 2:37 PM, Laurent Bourgès wrote:
I spotted at least one thing that I brought up in the 2D Marlin review, but
since the 2 source bases are moving
towards synchronizing with each other I didn't look too closely since many
of the changes in the 2D Marlin update
a
I've reviewed the code and run a number of tests. Things look fine.
I spotted at least one thing that I brought up in the 2D Marlin review, but since the 2 source bases are moving towards
synchronizing with each other I didn't look too closely since many of the changes in the 2D Marlin update a
Some effects have multiple inputs and have no single bare getInput/setInput
methods and ColorInput has no input at all...
...jim
On 4/21/17 5:13 AM, Jose Martinez wrote:
Hello,
Shouldn't the setInput/getInput method be part of the Effect abstract class?
Even if its ju
Review history already in JBS: https://bugs.openjdk.java.net/browse/JDK-8178521
final webrev: http://cr.openjdk.java.net/~flar/JDK-8178521/webrev.02/
This should be considered for a backport to 9 as well...
...jim
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
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
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
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 a
I don't think I was specifically involved in AWT fixes for that issue, but the concerns that David raises are all valid
and Phil correctly points out that this is much worse in a network display environment...
...jim
On 4/4/17 3:53 PM, Philip Race wrote:
AWT used to hav
Fix suggested in description works just fine:
JBS: https://bugs.openjdk.java.net/browse/JDK-8174671
webrev: http://cr.openjdk.java.net/~flar/JDK-8174671/webrev.00/
...jim
JBS: https://bugs.openjdk.java.net/browse/JDK-8174688
webrev: http://cr.openjdk.java.net/~flar/JDK-8174688/webrev.00/
It was a one-ish-line-ish fix (just needed to invert one Y coordinate consistent with other cases, but it took a couple
of lines to fetch the necessary data for inversion).
Sti
JBS: https://bugs.openjdk.java.net/browse/JDK-8148549
webrev: http://cr.openjdk.java.net/~flar/JDK-8148549/webrev.00/
The webrev is for 9, but the same code appears in 8u so I will apply and test the fix there and request a backport when
I'm sure that it works...
...jim
The spelling changes look right, but "of Foo method" bothers me - it should be "of the Foo method". The same comment
would reply to the retainAll doc comment... :(
...jim
On 1/29/17 1:31 PM, Jonathan Giles wrote:
Ajit,
Could you please review the following jira issue
Vote: yes
...jim
On 1/25/17 11:39 AM, David Hill wrote:
I hereby nominate Semyon Sadetsky to OpenJFX Committer.
Semyon Sadetsky is part of the JavaFX team focusing on glass.
A list of Semyon's commits and reviews is available by the following links
http://hg.openjdk.java.net/openjfx
I was able to fix my Win7 permission problems and verify the fix on
Windows 7 as well now...
...jim
On 1/5/2017 5:16 PM, Jim Graham wrote:
This is essentially a backport request for the fix for JDK-8160073, but
a modification of the fix was needed as the code changed
This fails if the coordinate is not on any screen (screen will remain null).
Also, spacing on the if statement at line 315...
...jim
On 1/11/17 1:54 PM, David Hill wrote:
Kevin, Jim,
please review:
https://bugs.openjdk.java.net/browse/JDK-8171985
webrev: http://cr
This is essentially a backport request for the fix for JDK-8160073, but a modification of the fix was needed as the code
changed between 8u and 9.
JBS: https://bugs.openjdk.java.net/browse/JDK-8169777
webrev: http://cr.openjdk.java.net/~flar/JDK-8169777/webrev.00/
I tested on Win10 and it works
JBS: https://bugs.openjdk.java.net/browse/JDK-8171513
The fix is small so the patch is included inline below...
...jim
---
diff -r 2bae8f04958b
modules/javafx.graphics/src/main/java/javafx/animation/AnimationTimer.java
---
a/modules/javafx.graphics/src/m
JBS: https://bugs.openjdk.java.net/browse/JDK-8146920
webrev: http://cr.openjdk.java.net/~flar/JDK-8146920/webrev.03/
Details are in the JBS comments.
I'm tagging Kevin here on the review, but any engineers with more than a passing familiarity with Glass should review
the changes as it represen
Laurent sent these webrevs to Kevin and I earlier to evaluate for JDK9. We're testing them and planning to integrate
them so I thought I should send out the official review request, though it is really Laurent's work and he'll be the
eventual author listed on the changeset:
JBS: https://bugs.o
Hi Laurent,
Normally we'd isolate fixes for different bugs even if they are just
preparatory formatting changes on comments.
Some comments on the formatting changes:
line 35 - you should also upper-case the E
line 148 - I don't understand why this "float" was a formatting danger, but the one
The fix applied cleanly to 8u-dev and fixed the same pair of bugs so this is
now also a backport request.
8u-specific webrev:
http://cr.openjdk.java.net/~flar/JDK-8088857/webrev.8u.rt.00/
...jim
On 12/7/16 8:06 AM, Jim Graham wrote:
JBS: https://bugs.openjdk.java.net
JBS: https://bugs.openjdk.java.net/browse/JDK-8088857
webrev: http://cr.openjdk.java.net/~flar/JDK-8088857/webrev.rt.00/
Fix is as we discussed.
I'll investigate applying it to 8u-dev soon...
...jim
Before we come to any conclusions on performance, though, we might want to run this on something like a Microsoft
Surface that uses a mobile processor (m3 in the low end) that might not perform as well with doubles. Does anyone have
a low-end Surface they could try these patches on and see how t
If this eliminates the regressions in TestNonAA, then I'm for reworking this as
an in-place patch for MarlinFX.
We can't use the existing Dasher bug for this because Marlin isn't the default renderer, but we can mention the
DMarlinFX bug as a workaround for the Dasher bug...
One thing that might cause a problem is that the script modified ERR_STEP_MAX because it had 7f, but it was 0x7f, not
1.7f. Some other constants might be affected as well...
...jim
On 11/30/16 2:12 PM, Laurent Bourgès wrote:
- TestNonAARasterization: the errors seem ar
Hi Laurent,
I think you've looked into the issues of flatness and how inflection points affect it about as much as I have at this
point. I'm not sure that sub-dividing at min/max values helps filling, but a way to subdivide at inflection points
might improve the flattening algorithm. It's wor
.
- Chien
On 11/10/16, 10:22 AM, Jim Graham wrote:
I guess we'll punt on ImagePattern?
Other than that the fix looks fine...
...jim
On 11/9/16 5:35 PM, Chien Yang wrote:
Hi Jim and Kevin,
Please review the proposed fix:
JIRA: https://bugs.openjdk.java.net/browse/JDK-80881
Another thought on multi-threaded scan-line rasterization would be to pre-scan the node tree and pre-rasterize all
shapes into masks before we run through and render them to the destination. Again, that would be outside the scope of
9, but it would be a change only to the rendering process (and
I guess we'll punt on ImagePattern?
Other than that the fix looks fine...
...jim
On 11/9/16 5:35 PM, Chien Yang wrote:
Hi Jim and Kevin,
Please review the proposed fix:
JIRA: https://bugs.openjdk.java.net/browse/JDK-8088179
Webrev: http://cr.openjdk.java.net/~ckyang/J
Maybe it is time to start the review for the FX enhancement ?
https://bugs.openjdk.java.net/browse/JDK-8169270
Cheers,
Laurent
2016-11-04 19:55 GMT+01:00 Jim Graham :
On 11/4/2016 11:33 AM, Laurent Bourgès wrote:
For SWContext, I figured out that only openpisces.* classes were used
dir
Going forward perhaps we should refer to the version of Marlin in Java2D as
Marlin2D?
Then Marlin is your original plug-in version that is still being worked on.
Marlin2D is what you integrated into OpenJDK/Java2D.
MarlinFX is what you are planning for FX.
That's just for conversational purpose
On 10/21/16 9:51 AM, Laurent Bourgès wrote:
Jim, do you think possible to unify Marlin and MarlinFX for openjdk9 ? The
main difference relies in different Shape/PathConsumer classes and Fx uses
the AlphaConsumer + different initialization.
Did you have a look at the diffs ?
One of the big hur
On 10/20/16 5:34 AM, Kevin Rushforth wrote:
For now the OpenPiscesRasterizer class uses a static Renderer (single
instance) so it is single-threaded.
In MarlinFX I could prepare the multi-threading support by using 1
RendererContext per thread (ThreadLocal) as I did in Marlin for java2d.
Howeve
On 11/7/2016 1:14 PM, Laurent Bourgès wrote:
The only difference in Path2D.java I noted is that the Java2D version has
an EXPAND_MIN which is 10, but you re-use INIT_SIZE, which is 20, here for
the same purpose.
You're right; I think I didn't want to add an extra constant but if you
prefer be
I'd like to see Kevin review the test as I'm not the best expert on our
JUnit framework.
It looks like it is mostly just going to emit some printouts about
performance (using echo() and log()) and verify that we don't get any
ArrayBounds related exceptions (or worse, OOME)?
The only differen
Path2D fix
as a separate bug fix, please file a new bug for this, linking it to the
equivalent Java2D bug and also to the new RFE that Jim will file.
Thanks.
-- Kevin
Jim Graham wrote:
There are basically 2 isolated changes to the existing code base and
then a set of added source files.
The
On 11/4/2016 11:33 AM, Laurent Bourgès wrote:
For SWContext, I figured out that only openpisces.* classes were used
directly via imports (hardcoded) so I left it unchanged. So you propose
to generalize use of marlin or native pisces ?
I didn't notice that, I was just searching on the use of
"d
There are basically 2 isolated changes to the existing code base and
then a set of added source files.
The first change is to use Marlin if the appropriate property is
specified, and those changes are very localized and easy to verify that
they won't hurt anything.
The second change is to mo
We currently control the configuration logging with prism.verbose, and
we already have a place in PrismSettings where we dump out the
configuration including which rasterizer we're using (native or
java-based) if verbose is set. We should probably consolidate this
along with the TODO to move t
JBS: https://bugs.openjdk.java.net/browse/JDK-8166856
webrev: http://cr.openjdk.java.net/~flar/JDK-8166856/webrev.00/
Some analysis in the last 2 comments of the JBS, but the main fix is to
not send bounds changes down to native when no change has happened from
FX code. The main culprit here w
JBS: https://bugs.openjdk.java.net/browse/JDK-8166382
webrev: http://cr.openjdk.java.net/~flar/JDK-8166382/webrev.00/
Pretty self-explanatory fix...
...jim
Rather than try to hack around the exposure of the internal ImageLoader APIs, given the relatively small amount of glue
code in that package it might be easier for them to reimplement the glue to use WritableImage...
...jim
On 10/11/16 5:36 AM, Kevin Rushforth wrote:
As
An updated webrev is available, incorporating the feedback in the JBS comments:
http://cr.openjdk.java.net/~flar/JDK-8166565/webrev.01/
...jim
On 9/27/16 9:09 PM, Jim Graham wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8166565
webrev: http://cr.openjdk.java.net
JBS: https://bugs.openjdk.java.net/browse/JDK-8166565
webrev: http://cr.openjdk.java.net/~flar/JDK-8166565/webrev.00/
I made the 6 new snapXY() methods in Region public for convenience here. They are all new for 9 and had been protected,
now they are public.
As noted in the bug report comment
PM, Jim Graham wrote:
JBS: https://bugs.openjdk.java.net/browse/JDK-8090176
webrev for 9u: http://cr.openjdk.java.net/~flar/JDK-8090176/webrev.9u.01/
The webrev is prepared for 8u, but I will be holding off on submitting that for
backport review until the fix has baked
in the 9u-dev repo for a
JBS: https://bugs.openjdk.java.net/browse/JDK-8090176
webrev for 9u: http://cr.openjdk.java.net/~flar/JDK-8090176/webrev.9u.01/
The webrev is prepared for 8u, but I will be holding off on submitting that for backport review until the fix has baked
in the 9u-dev repo for a couple of weeks...
Same patch applies to both (modulo source code paths).
jbs: https://bugs.openjdk.java.net/browse/JDK-8087565
8u webrev: http://cr.openjdk.java.net/~flar/JDK-8087565/webrev.8u.00/
9u webrev: http://cr.openjdk.java.net/~flar/JDK-8087565/webrev.9u.00/
This is a minor improvement on the earlier fix
JBS: https://bugs.openjdk.java.net/browse/JDK-8160073
webrev: http://cr.openjdk.java.net/~flar/JDK-8160073/webrev.00/
The details are in the comments in the bug report. To summarize:
- send a notification when DPI changes to reevaluate scene.getXY()
- correctly scale event screen coordinates fo
It looks like we create a dummy drawable for the context and install it when we are done with the frame. This appeared
in rev bbb8d2772b37, but it looks like that revision involved removing the unnecessary RenderingContext class, so we may
have been doing something similar via the RenderingConte
cy in the order of things as it exists so I moved a couple of the functions purely for my own OCD enjoyment,
but didn't sweat the details too much...
...jim
On 8/9/16 6:41 PM, Jim Graham wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8159892
we
Bug: https://bugs.openjdk.java.net/browse/JDK-8159892
webrev: http://cr.openjdk.java.net/~flar/JDK-8159892/webrev.00/
There are a number of bugs filed on this, or very similar issues as well - all
related to broken DPI scaling on GTK3.
It looks like there is a simple way of disabling automatic
Vote: yes
...jim
On 7/23/16 7:42 AM, Kevin Rushforth wrote:
I hereby nominate Andrey Rusakov [1] to OpenJFX Committer.
Andrey is a member of JavaFX SQE team at Oracle working on test development,
who has contributed 19 changesets [5] to
OpenJFX, at least 8 of which are signifi
Would a better exception help? OOME?
...jim
On 6/28/16 9:18 AM, Kevin Rushforth wrote:
Glad to hear it.
-- Kevin
GUEVEL, Emanuel wrote:
It worked.
The problem is not present anymore after switching to a 64-bit JVM.
Many thanks for this. :)
Best regards,
Emanuel
bug: https://bugs.openjdk.java.net/browse/JDK-8159860
webrev: http://cr.openjdk.java.net/~flar/JDK-8159860/webrev.00/
...jim
Updating the subject line to request 8u backport approval. The fix applies
cleanly to 8u and fixes the bug there as well...
...jim
On 6/17/16 2:09 PM, Jim Graham wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8145516
webrev: http://cr.openjdk.java.net/~flar/JDK
bug: https://bugs.openjdk.java.net/browse/JDK-8145516
webrev: http://cr.openjdk.java.net/~flar/JDK-8145516/webrev.00/
Information on the fix is in the bug report comments.
I need to repair my 8u-dev repos to check, but I believe this can be ported
directly to an 8u release...
A new webrev is available now that hopes to make sure the new functions have C-style external dependency names
regardless of how gio.h is included:
http://cr.openjdk.java.net/~flar/JDK-8157600/webrev.01/
...jim
On 5/26/16 5:43 PM, Jim Graham wrote:
bug: https
bug: https://bugs.openjdk.java.net/browse/JDK-8157600
webrev: http://cr.openjdk.java.net/~flar/JDK-8157600/webrev.00/
...jim
Sounds good...
...jim
On 5/20/16 3:56 PM, Kevin Rushforth wrote:
Jim Graham wrote:
On 5/20/16 3:33 PM, Kevin Rushforth wrote:
This is needed for those cases where we need to encapsulate a method in the
base Shape class that used to be public and
overridden in the
On 5/20/16 3:33 PM, Kevin Rushforth wrote:
This is needed for those cases where we need to encapsulate a method in the
base Shape class that used to be public and
overridden in the subclasses, not all of which are in the same package. It may
seem like overkill, but we need a way to
associate
It feels like there is extra indirection for the code that sets the helpers. Is there a reason it isn't as simple as
"this.shapeHelper = FooHelper.instance"? Or, even a package-private Shape(ShapeHelper) constructor on Shape? (*)
Also, many of the helper classes have argument names that were
This should be fixed in the next build (fix is already pushed to our 9-dev FX repo). It was caused by getting a "0"
from the GDK APIs that specify the scaling factor. We now protect against that uninitialized value...
...jim
On 5/20/16 8:30 AM, Kevin Rushforth wrote:
that seems to fix it.
On Wed, May 18, 2016 at 9:55 PM, Jim Graham wrote:
Ah, this is probably me returning a -1 as an uint. If you change the
"defval" used (line 167) in the call to query the property from -1 to 0
does it work as intended?
...jim
On 5/18/1
installed the stage looks fine.
On Wed, May 18, 2016 at 5:52 AM, Jim Graham mailto:james.gra...@oracle.com>> wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8157213
webrev: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-00/
Details of what was fixed are listed in the b
bug: https://bugs.openjdk.java.net/browse/JDK-8157213
webrev: http://cr.openjdk.java.net/~flar/JDK-8157213/webrev-00/
Details of what was fixed are listed in the bug report. This will hopefully fix all of the dependencies that Erik ran
into in his Gentoo environment...
t to "1", does FX come up fine?
...jim
On 05/16/2016 01:01 PM, Jim Graham wrote:
These may both be related to the HiDPI fix instead. I added a usage of
g_settings in that fix that went in on Friday. It looks like I'll have
to check for the schema existing
d.run(Thread.java:804)
Nearly all values seem to be -2147483648
I used openjdk9 109 as per instructions of the wiki, and the latest javafx
dev.
On Mon, May 9, 2016 at 8:56 PM, Jim Graham wrote:
Should we integrate that into prism.verbose output?
...jim
On 5/9/16
It is implemented in the FX Robot in that webrev...?
...jim
On 5/12/16 3:07 PM, Sergey Bylokhov wrote:
Hi Jim.
Do you plan to implement the new HiDPI API for the Robot class?
On 13.05.16 0:43, Jim Graham wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8137050
bug: https://bugs.openjdk.java.net/browse/JDK-8137050
webrev: http://cr.openjdk.java.net/~flar/JDK-8137050/webrev-00/
The order of taking scaling parameters in order of higher to lower priority is:
- -Dglass.gtk.uiScale system property
- Same property in the environment
- GDK_SCALE in the environ
Should we integrate that into prism.verbose output?
...jim
On 5/9/16 6:18 AM, David Hill wrote:
I added a new feature Friday and would like some help testing it.
This new feature (8087516: Conditional support for GTK 3 on Linux) allows us to
use either GTK v2 or 3 wit
d-stroke-styles/2d.gradient.interpolate.overlap2.html
Thanks,
Arun
On 5/5/2016 11:51 PM, Jim Graham wrote:
Hi Arun,
The change you made to the calculateSingleArray method looks like it produces a
bad array of color stops for the case
where Imin is 0. You should fall into the calculateMultipleArray method
instead which
bug: https://bugs.openjdk.java.net/browse/JDK-8156094
webrev for 9-dev: http://cr.openjdk.java.net/~flar/JDK-8156094/9-dev/webrev.00/
webrev for 8u-dev:
http://cr.openjdk.java.net/~flar/JDK-8156094/8u-dev/webrev.00/
The two fixes ended up being closer than I thought due to an idiosyncrasy of ho
TransformUtils.java - can't this class be deleted now since all it
exists to do is to forward to TransformHelper?
Alternatively, why create TransformHelper in the first place when it is
90% just a copy of what TransformUtils used to be (ignoring the inner
class that got moved to Transform) wit
On 05/05/2016 11:26 AM, Jim Graham wrote:
Is this true of any other objects managed by DWDisposer?
DWDisposer is only the class used to implement "dispose()" of
a single DWFontFile that occurs during running/gc.
It doesn't really "manage" anything and I don
Is this true of any other objects managed by DWDisposer? Would it be
better to simply run through the DWDisposer queue on shutdown and force
it to dispose (i.e. release) everything it has?
...jim
On 05/05/2016 11:12 AM, Phil Race wrote:
Please review :-
Bug : https://
Hi Arun,
The change you made to the calculateSingleArray method looks like it
produces a bad array of color stops for the case where Imin is 0. You
should fall into the calculateMultipleArray method instead which should
not have any trouble with zero length intervals. At that point you
don'
aring this information and your thought. I'm not sure is
this saving worth violating the principle of minimizing scope in code. I
guess you did bring up a good point let me think over it and discuss
with Kevin tomorrow.
- Chien
On 4/29/16, 4:04 PM, Jim Graham wrote:
One comment on the impl
One comment on the implementation. For the methods used by an accessor inner class, if you make them private in the
outer class then that inner class will need a hidden accessor method to be added in the bytecodes. If you make them
package-private then they can access the method directly.
Bas
Bug: https://bugs.openjdk.java.net/browse/JDK-8155692
webrev: http://cr.openjdk.java.net/~flar/JDK-8155692/webrev.00/
It's mostly just a build file change to pick up the compilers from the
new VS140COMNTOOLS location, but it also includes a change to minimize
the impact of a recent change to th
1 - 100 of 290 matches
Mail list logo
