Re: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

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

Re: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

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" <james.gra...@oracle.com <mailto:james.gra...@oracle.com>> a écrit : Hi Laurent, On 8/28/17 2:09 PM,

Re: RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

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 <james.gra...@oracle.com <mailto:james.gra...@oracle.com>>: [D]Dasher.java - why the

Re: RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0

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

Re: [10] RFR: JDK-8133329: Drag and Drop of files in a SwingNode fails

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 re

Re: [10] RFR: JDK-8133329: Drag and Drop of files in a SwingNode fails

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

[10] Review request for 8183530: JavaFX charts peg rendering thread as more data is added

JBS: https://bugs.openjdk.java.net/browse/JDK-8183530 webrev: http://cr.openjdk.java.net/~flar/JDK-8183530/webrev.03/ ...jim

Re: javafx.scene.shape.Path (memory) inefficient PathElements

: 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 <james.gra...@oracle.com> wrote: Thanks Tom, I've already posted a patch for 8180938

[10] Review request: JDK-8181976 - Specifying desired dimensions for Image with HiDPI (@2x) variant gets the size wrong

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

Re: CFV: New OpenJFX Committer: Ajit Ghaisas

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:

Re: javafx.scene.shape.Path (memory) inefficient PathElements

... ...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 look like

Re: MarlinFX upgrade 0.7.5

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() +

Re: MarlinFX upgrade 0.7.5

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

Re: MarlinFX upgrade 0.7.5

njfx10.patch Regards, Laurent 2017-04-26 7:06 GMT+02:00 Jim Graham <james.gra...@oracle.com>: 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 sy

[10] Review request: JDK-8179946 - Objects are not rendered for certain rotation angle and cache hint combinations

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

Re: javafx.scene.shape.Path (memory) inefficient PathElements

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?

Re: MarlinFX upgrade 0.7.5

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

Re: MarlinFX upgrade 0.7.5

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

Re: consider setInput/getInput as method in Effect

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

[10] Review request: 8178521 Severe performance drop for path rendering

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

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

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

[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

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

Re: Canvas Content Shift

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

Re: [10] Review request for 8176844: Menus not always selected properly with GTK 3

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

[9] Review request for 8174671: Native debug build fails on Windows

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

[9] Review request for 8174688: JavaFX Applet popup windows are in the wrong location

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).

[9, 8u] Review request for 8148549: Region is not rendered correctly when node cache is enabled

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...

Re: 8173385: spelling errors in JavaFX javadoc

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

Re: CFV: New OpenJFX Committer: Semyon Sadetsky

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

Re: [8u] Review request for 8169777: MenuBar unoperable after moving Application to second monitor

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

Re: Review request: Fx applet fails to get loaded on Ubuntu with jre9-b150

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:

[8u] Review request for 8169777: MenuBar unoperable after moving Application to second monitor

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

[9] Review request for JDK-8171513: Fix typo in API doc for AnimationTimer

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 ---

[9] Review request for JDK-8146920: [hidpi] Multi-Monitor issue with HiDpi scaling and undecorated stages

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

[9] Review request for 8171393: Integrate precision fixes for Marlin

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:

Re: [9] Review request: JDK-8170030 Code in Marlin-based rasterizers may have an off-by-1 bug

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

Re: [9,8u] Review request: JDK-8088857 Menu slow to respond after resizing a window multiple times with animation running

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

[9] Review request: JDK-8088857 Menu slow to respond after resizing a window multiple times with animation running

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

Re: Follow-on bugs

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

Re: Follow-on bugs

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...

Re: Follow-on bugs

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

Re: Follow-on bugs

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

Re: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background

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-8088179 Webrev: http

Re: Fwd: Re: Marlin-Renderer and JavaFX

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

Re: [9] Code Review Request For 8088179: [Quantum] White flashing when opening a stage with dark background

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:

Re: Fwd: Re: Marlin-Renderer and JavaFX

r the FX enhancement ? https://bugs.openjdk.java.net/browse/JDK-8169270 Cheers, Laurent 2016-11-04 19:55 GMT+01:00 Jim Graham <james.gra...@oracle.com>: On 11/4/2016 11:33 AM, Laurent Bourgès wrote: For SWContext, I figured out that only openpisces.* classes were used directly via imp

Re: Fwd: Re: Marlin-Renderer and JavaFX

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

Re: Fwd: Re: Marlin-Renderer and JavaFX

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

Re: Fwd: Re: Marlin-Renderer and JavaFX

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.

Re: Review request for 8169294:

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

Re: Review request for 8169294:

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

Re: Fwd: Re: Marlin-Renderer and JavaFX

the 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

Re: Fwd: Re: Marlin-Renderer and JavaFX

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

Re: Fwd: Re: Marlin-Renderer and JavaFX

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

Re: Fwd: Re: Marlin-Renderer and JavaFX

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

[9] Review request for 8166856: OS X: dual screen rendering issue

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

[9] Review request: 8166382 [hidpi] Ubuntu 16.04: invalid coordinates when using glass robot

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

Re: [9] Review request for 8090176: Pisces software renderer shows incomplete border images in particular situation

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

[9] Review request for 8090176: Pisces software renderer shows incomplete border images in particular situation

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...

Re: Memory leaks on Linux with hardware renderer

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

Re: [9] Review request for 8159892: Ubuntu 16.04: invalid rendering of FX app stage in case of scaling

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 webrev: http

[9] Review request for 8159892: Ubuntu 16.04: invalid rendering of FX app stage in case of scaling

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

Re: CFV: New OpenJFX Committer: Andrey Rusakov

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

Re: Exception on render thread: "NGTriangleMesh: buildGeometry failed"

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

[8u, 9] Review request: 8159860: JavaFX Path drawing appears to leak native memory

bug: https://bugs.openjdk.java.net/browse/JDK-8159860 webrev: http://cr.openjdk.java.net/~flar/JDK-8159860/webrev.00/ ...jim

Re: [8u, 9] Review request: 8145516: Scene content shows too large on Retina display, when a regular screen attached

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

[9] Review request for 8157600: Failed to launch hello.HelloSanity due to libglass.so: undefined symbol

bug: https://bugs.openjdk.java.net/browse/JDK-8157600 webrev: http://cr.openjdk.java.net/~flar/JDK-8157600/webrev.00/ ...jim

Re: [9] Code Review Request For 8157350: Encapsulate impl_ methods in Shapes related classes

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

Re: [9] Code Review Request For 8157350: Encapsulate impl_ methods in Shapes related classes

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

Re: JDK9 build 119 fails on Ubuntu Gnome 16.04

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:

Re: [9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency

that seems to fix it. On Wed, May 18, 2016 at 9:55 PM, Jim Graham <james.gra...@oracle.com> 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?

Re: [9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency

installed the stage looks fine. On Wed, May 18, 2016 at 5:52 AM, Jim Graham <james.gra...@oracle.com <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 wha

[9] Review request for 8157213: HiDPI support for Linux creates unnecessary dependency

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...

Re: Support for GTK 2 & 3 now in JFX

ot;, 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 before I access it.

Re: Support for GTK 2 & 3 now in JFX

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 <james.gra...@oracle.com> wrote: Should we integrate that into prism.verbose output? ...jim On 5/9/16 6:18 AM, David Hill

Re: [9] Review request for 8137050: Support Linux settings for HiDPI scaling

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

[9] Review request for 8137050: Support Linux settings for HiDPI scaling

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

Re: Support for GTK 2 & 3 now in JFX

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

Re: [graphics] [9] Review request for 8155903: Crash while running imported/w3c/canvas/2d.gradient.interpolate.overlap2.html

oke-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 shoul

[8u, 9] Review request for 8156094: ContextMenu shown at wrong position on Windows10 with Extended Screen

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

Re: [9] Code Review Request For 8155762: Encapsulate JavaFX impl_* implementation methods in transform package

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)

Re: RFR: 8152423: Generated temp files (+JXF...temp) for custom fonts not deleted on exit.

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't see it used to dispos

Re: RFR: 8152423: Generated temp files (+JXF...temp) for custom fonts not deleted on exit.

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 :

Re: Code Review Request For 8155757: Encapsulate impl_ methods in animation, canvas, image, input, layout, paint, and text packages

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 implementation

Re: Code Review Request For 8155757: Encapsulate impl_ methods in animation, canvas, image, input, layout, paint, and text packages

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.

[9] review request: 8155692: changes to compile under Visual Studio 14.0

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

Re: CFV: New OpenJFX Committer: Guru Hb

Vote: yes ...jim On 4/28/16 8:16 AM, Kevin Rushforth wrote: I hereby nominate Guru Hb [1] to OpenJFX Committer. Guru is a member of JavaFX team at Oracle working on WebKit, who has contributed 10 changesets [5] to OpenJFX, at least 8 of which are significant. Votes are due by May 12,

[9] post-commit review: 8153348: JavaFX API doc examples use nonexistent package "javafx.animation.transition"

https://bugs.openjdk.java.net/browse/JDK-8153348 ...jim Changeset: e1688df54bdc Author:flar Date: 2016-04-12 15:26 -0700 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/e1688df54bdc 8153348: JavaFX API doc examples use

Re: [9] Review request: 8091832: Provide API for getting the Screen scale on HiDPI screens

...jim On 3/31/16 12:52 AM, Jim Graham wrote: I've updated the fix with the following additions: http://cr.openjdk.java.net/~flar/JDK-8091832/webrev.rt.02/ - Redundant or obsolete command line overrides removed from Windows code as follows: Settings still supported

Re: Is there a Anti-aliasing grayscale prism option?

All Shape antialiasing should be grayscale. The only non-grayscale AA we have is for text only, and that can be controlled using the fontSmoothingType property on the Text node. Are these Text nodes or other nodes that show the colored pixels? It might help to submit a small test case (as

Re: [9] Review request: 8091832: Provide API for getting the Screen scale on HiDPI screens

of embedded Swing nodes. I looked at what was needed and have an idea of what the fix would involve, but decided that it was outside the scope of these fixes that are needed to get the HiDPI FX properties implemented. ...jim On 3/28/16 6:25 PM, Jim Graham wrote: bug

Re: [9] Review request: 8091832: Provide API for getting the Screen scale on HiDPI screens

en X- and Y-direction is actually relevant. I've never seen such a system before. Michael Am 29.03.16 um 03:25 schrieb Jim Graham: bug: https://bugs.openjdk.java.net/browse/JDK-8091832 webrev: http://cr.openjdk.java.net/~flar/JDK-8091832/webrev.rt.00/ This webrev fixes pixel snapping and applica

Re: buffer too small

... ...jim On 3/9/16 3:26 PM, Jim Graham wrote: Hi Johan, That sounds like the fix then. Note that there is another optimization issue here that could be addressed in a follow-on - basically when a larger physical size is allocated, then we could expand the content

Re: buffer too small

0, 0, 0, 0, highMaskCol, nextMaskRow, - maskTex.getPhysicalWidth(), true); + maskTex.getContentWidth(), true); maskTex.unlock(); curMaskRow = curMaskCol = nextMaskRow = highMaskCol = 0; } On Tue, Mar 8, 2

Re: buffer too small

I think I see the issue. In the code that calls maskTex.update(...) it passes maskTex.physicalWidth() as the scan stride of the buffer, but the scan stride of the buffer is based on the content size, not the physical size. Thus, the checkUpdateParams() method overestimates how many bytes

Re: buffer too small

Hi Johan, Notes in line below... On 3/8/16 6:14 AM, Johan Vos wrote: We got a number of bug reports (on Android and iOS) reported by developers using large images: java.lang.IllegalArgumentException: Upload requires 2475266 elements, but only 1549938 elements remain in the buffer at

Re: GLS language errors (Was: Internal error: Error loading stock shader FillRoundRect_LinearGradient,_PAD on Vivante ARM)

The thing about this use of pixcoord is that the same information can be supplied much more efficiently as a pair of texture coordinates. The value of pixcoord ends up being a linear equation over the area of the primitive which is exactly what texture coordinate samples give you for free.

Re: [9] review request: 8149967: Cannot compile JFXPanel with JDK 9: SurfaceData::getDefaultScale not found

Sergey Bylokhov wrote: Note that in jdk9 the same data can be obtained via GraphicsConfiguration.getDefaultTransform(); On 17.02.16 2:53, Jim Graham wrote: I added a comment on the bug about BC, but it sounds like you already considered it. I'm fine with this as is, but would push for moving

  1   2   3   >