Re: Review request for 8169294:

2016-11-07 Thread Jim Graham



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 being more consistent, I can prepare another webrev.


In looking at it again, I don't think it matters since it would only 
ever be triggered if they created a path that intentionally had fewer 
than the default number of entries, so it makes more sense to always 
grow by at least the INIT_SIZE rather than a smaller number.


I think I like the new policy better than the one in Java2D...

...jim


Re: Fwd: Re: Marlin-Renderer and JavaFX

2016-11-07 Thread Laurent Bourgès
Jim,

Here is the new patch:
http://cr.openjdk.java.net/~lbourges/marlinFX/marlinFX-s02-ofx9.3/

Changes:
- cleanup wrt OpenJDK9 (Unsafe is OK but I switch to the standard Cleaner)
- modified PrismSettings as recommended and renamed all Marlin properties
to use the prefix 'prism.marlin'
- SWContext: added Marlin SW support: I had to tweak the processed range[x;
pix_to[ instead of [pix_from; pix_to[ as the PiscesRenderer does not handle
properly the bbox so it processes many extra pixels on the left side (empty
coverage) = to be discussed as it can be fixed in the native prism-sw code
... See my comment in the code:

+@Override+public void
setAndClearRelativeAlphas(final int[] alphaDeltas, final int pix_y,+
   final int pix_from,
final int pix_to)+{+// use x instead of
pix_from as it cause artefacts:+// note: it would be
more efficient to skip all those empty pixels [x to pix_from[+
   // but the native implementation must be fixed too.+//
  pr.emitAndClearAlphaRow(alpha_map, alphaDeltas, pix_y, pix_from,
pix_to, rowNum);+pr.emitAndClearAlphaRow(alpha_map,
alphaDeltas, pix_y, x, pix_to, rowNum);

I successfully built OpenJFX9 (gradle) and tested OK with OpenJDK9 b143
(xpatch.args) with Ensemble8 + DemoFX.

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
>> 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
> "doNativePisces".  We can look at that separately, and Kevin would know how
> frequently we end up in the SW pipeline these days...


Re: Review request for 8169294:

2016-11-07 Thread Kevin Rushforth
I'll review the test tomorrow (I'm a little backed up on my code reviews 
given the impending change to build with jigsaw JDK).


-- Kevin


Laurent Bourgès wrote:

Jim,

2016-11-07 21:05 GMT+01:00 Jim Graham >:


I'd like to see Kevin review the test as I'm not the best expert
on our JUnit framework.


I just added @Test annotations and kept the jtreg tags in header (for 
information).
I could add asserts but JUnit does intercept any thrown exception and 
reports a test failure in such case.


I managed to undestand how to run my test with gradle:
gradle :graphics:test  --tests test.com.sun.javafx.geom.Path2DGrowTest

It is passing and the reports indicates that the 2 new tests are OK 
(report in modules/javafx.graphics/build/reports/tests/index.html)
 



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


Exactly, it is passing as there is no runtime exception and the 
performance issue is fixed as indicated by the few logged lines.
 



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 being more consistent, I can prepare another webrev.


Laurent


RFR: 8088325 & 8169339 : Provide internal JDK API to JavaFX to locate JDK fonts

2016-11-07 Thread Phil Race

Hi,
Two bug ids, two webrevs and a cross-post since JDK needs to provide a
qualified export to JavaFX so it can access any fonts that may be provided
with the JDK.

FX bug: https://bugs.openjdk.java.net/browse/JDK-8088325
FX  fix : http://cr.openjdk.java.net/~prr/8088325/ 


JDK bug : https://bugs.openjdk.java.net/browse/JDK-8169339
JDK  fix : http://cr.openjdk.java.net/~prr/8169339/ 



-phil.


Re: Review request for 8169294:

2016-11-07 Thread Laurent Bourgès
Jim,

2016-11-07 21:05 GMT+01:00 Jim Graham :

> I'd like to see Kevin review the test as I'm not the best expert on our
> JUnit framework.
>

I just added @Test annotations and kept the jtreg tags in header (for
information).
I could add asserts but JUnit does intercept any thrown exception and
reports a test failure in such case.

I managed to undestand how to run my test with gradle:
gradle :graphics:test  --tests test.com.sun.javafx.geom.Path2DGrowTest

It is passing and the reports indicates that the 2 new tests are OK (report
in modules/javafx.graphics/build/reports/tests/index.html)


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

Exactly, it is passing as there is no runtime exception and the performance
issue is fixed as indicated by the few logged lines.


>
> 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 being more consistent, I can prepare another webrev.

Laurent


Re: Review request for 8169294:

2016-11-07 Thread Jim Graham
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 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.


I think that's fine, but wanted to point it out so you could comment...

...jim

On 11/6/2016 1:01 PM, Laurent Bourgès wrote:

Hi,

Please review this Path2D fix improving its storage growth algorithm as
done in java2d:
JBS: https://bugs.openjdk.java.net/browse/JDK-8169294
Webrev: http://cr.openjdk.java.net/~lbourges/fx/path2D/

PS: I converted the former jtreg test to JUnit test for OpenJFX. I hope
it is correct, as I was not able to run this test within gradle (but it
works in netbeans)

Best regards,
Laurent


Re: Issues porting to Monocle EPD platform

2016-11-07 Thread David Hill

On 11/7/16, 12:55 PM, John Neffenger wrote:

Hi John,
I am probably the guy that will be looking over these, but I am in the 
middle of a big push. Feel free to ping me offline if I don't get back to you 
by early next week.

Dave

While porting OpenJFX to devices with an electronic paper display, I resolved 
three issues in the graphics module that I thought I should pass along. The 
following merge request on GitLab lists the issues and my minor changes. See 
the Commits and Changes tabs in the middle of the page for details.

WIP: Patches to OpenJFX
https://gitlab.com/openjfxepd/jfxpatch/merge_requests/1

Did I understand the code correctly? I would appreciate any feedback.

As a brief summary, the first issue, "QuantumRenderer modifies buffer in use by 
JavaFX Application Thread," may be of general interest because it occurs on the 
Monocle Headless and VNC platforms.

The second issue, "zForce touchscreen input device fails when closed and immediately 
reopened," might affect only my platform, or maybe just the older Linux kernel and 
device driver I'm forced to use, but I couldn't find a good workaround without 
duplicating the entire LinuxInputDevice class.

The third issue, "Get two bytes for the Linux input event type, not four," 
doesn't seem to cause any problems, but may still be worth fixing.

Thank you,
John



--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)



Issues porting to Monocle EPD platform

2016-11-07 Thread John Neffenger
While porting OpenJFX to devices with an electronic paper display, I 
resolved three issues in the graphics module that I thought I should 
pass along. The following merge request on GitLab lists the issues and 
my minor changes. See the Commits and Changes tabs in the middle of the 
page for details.


WIP: Patches to OpenJFX
https://gitlab.com/openjfxepd/jfxpatch/merge_requests/1

Did I understand the code correctly? I would appreciate any feedback.

As a brief summary, the first issue, "QuantumRenderer modifies buffer in 
use by JavaFX Application Thread," may be of general interest because it 
occurs on the Monocle Headless and VNC platforms.


The second issue, "zForce touchscreen input device fails when closed and 
immediately reopened," might affect only my platform, or maybe just the 
older Linux kernel and device driver I'm forced to use, but I couldn't 
find a good workaround without duplicating the entire LinuxInputDevice 
class.


The third issue, "Get two bytes for the Linux input event type, not 
four," doesn't seem to cause any problems, but may still be worth fixing.


Thank you,
John


Re: [webkit] [9] Review request for 8088205: [Mac] WebView renders icons instead of letters on some sites

2016-11-07 Thread Arunprasad Rajkumar
Hello Kevin, Phil,

I have incorporated review comments, Please take a look.

http://cr.openjdk.java.net/~arajkumar/8088205/webrev.01/ 


Thanks,
Arun
> On 04-Oct-2016, at 12:15 AM, Arunprasad Rajkumar 
>  wrote:
> 
> Hello Kevin, Phil, Guru
> 
> Please review the following fix.
> 
> JIRA: https://bugs.openjdk.java.net/browse/JDK-8088205
> 
> Webrev: http://cr.openjdk.java.net/~arajkumar/8088205/webrev.00 
> 
> Analysis: Some Web Fonts(like Thin.ttf, refer the attachment) doesn’t have 
> valid entry in the TTF Naming Table. Due to missing entry, 
> “CTFontCreateWithName” is not returning correct font reference.
> 
> Solution: Use “CGFontCreateWithDataProvider”, it takes font path as a 
> parameter and creates a CGFontRef, then create a CTFontRef using CGFontRef. 
> “CGFontCreateWithDataProvider” doesn’t support TTC font type, so use 
> “CTFontCreateWithName” as a fallback if CGFontRef creation fails.
> 
> Test - 1: Load http://www.cnet.com with HelloWebView
> 
> Test - 2: Try simple fx application present in 
> https://bugs.openjdk.java.net/secure/attachment/62649/CustomFontApp.tar.bz2
> 
> Regards,
> Arun
> 
> 
> 



Heads up: Modular build is close.....

2016-11-07 Thread David Hill


The new modular build is close... !

The plan is for me to push the change set around 10 EST (7PST) on Tuesday.
This way we have much of the week to respond to disruptions.

Unlike one of my previous changes, there should be less disruption (less moved 
files, did not change buildSrc).

BUT ... there is some things I have mentioned, that I will mention again. This 
build checks for versions of gradle and the JDK. We are sensitive to ant 
versions.
  * Gradle 3.1 [1]
  * JDK 9 ea build 142+ [2]
  * ANT 1.8.2 [3]

Before pulling in the Tuesday changesets, it is very good practice to either 
run:
   gradle clean
or
   hg purge --all
to tidy up your repo (or both :-)

[1] https://gradle.org/gradle-download/
[2] https://jdk9.java.net/download/
[3] https://ant.apache.org/bindownload.cgi

--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)



Re: [Alpine Linux][amd64][JDK8] Build :graphics:compileDecoraNativeShadersLinux FAILED

2016-11-07 Thread Kevin Rushforth
The NPE is a known issue with antlr that happens on all platforms and is 
unrelated to your gcc error.


-- Kevin


d...@libertysurf.fr wrote:

No, I did not install any new packages after the first build failure. In fact, 
I am building the javafx in a docker container restarting from the beginning at 
each test !

Looking at the long output of the build, I noticed this :

...
:buildSrc:generateGrammarSource
error(10):  internal error: Can't get property indirectDelegates using method 
get/isIndirectDelegates from org.antlr.tool.Grammar instance : 
java.lang.NullPointerException
java.util.Objects.requireNonNull(Objects.java:203)
java.util.ArrayList.removeAll(ArrayList.java:689)
org.antlr.tool.CompositeGrammar.getIndirectDelegates(CompositeGrammar.java:222)
org.antlr.tool.Grammar.getIndirectDelegates(Grammar.java:2620)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:498)
org.antlr.stringtemplate.language.ASTExpr.invokeMethod(ASTExpr.java:563)
org.antlr.stringtemplate.language.ASTExpr.rawGetObjectProperty(ASTExpr.java:514)
org.antlr.stringtemplate.language.ASTExpr.getObjectProperty(ASTExpr.java:416)
org.antlr.stringtemplate.language.ActionEvaluator.attribute(ActionEvaluator.java:351)
org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:136)
org.antlr.stringtemplate.language.ActionEvaluator.templateApplication(ActionEvaluator.java:216)
org.antlr.stringtemplate.language.ActionEvaluator.expr(ActionEvaluator.java:126)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:84)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148)
org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722)
org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148)
org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722)
org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148)
org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:722)
org.antlr.stringtemplate.language.ASTExpr.writeAttribute(ASTExpr.java:659)
org.antlr.stringtemplate.language.ActionEvaluator.action(ActionEvaluator.java:86)
org.antlr.stringtemplate.language.ASTExpr.write(ASTExpr.java:148)
org.antlr.stringtemplate.StringTemplate.write(StringTemplate.java:700)
org.antlr.codegen.CodeGenerator.write(CodeGenerator.java:1278)
org.antlr.codegen.Target.genRecognizerFile(Target.java:94)
org.antlr.codegen.CodeGenerator.genRecognizer(CodeGenerator.java:463)
org.antlr.Tool.generateRecognizer(Tool.java:607)
org.antlr.Tool.process(Tool.java:429)
org.antlr.Tool.main(Tool.java:91)
:buildSrc:compileJava
...

May be there is a relationship between this and the final error ?

Didier

- Mail original -
  

Did you install any new packages after the first time you got a build
failure? If so, you might try manually doing:

rm -rf build

This will cause the various properties files in build to be
recreated.

-- Kevin



d...@libertysurf.fr wrote:


Hi all,

I'm trying to build JavaFX 8 taken from mercurial repo with Gradle
1.8 (as explained in
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX)
for alpine linux amd64 and face the following error :


bash-4.3# gradle
...
OS_NAME: linux
OS_ARCH: amd64
JAVA_HOME: /usr/lib/jvm/java-1.8-openjdk
JDK_HOME: /usr/lib/jvm/java-1.8-openjdk
java.runtime.version: 1.8.0_92-internal-alpine-r1-b14
java version: 1.8.0_92
java build number: 14
jdk.runtime.version: 1.8.0_92-internal-alpine-r1-b14
jdk version: 1.8.0_92
jdk build number: 14
minimum java build number: 26
CONF: Debug
NUM_COMPILE_THREADS: 8
COMPILE_TARGETS: linux
COMPILE_FLAGS_FILES: buildSrc/linux.gradle
HUDSON_JOB_NAME: not_hudson
HUDSON_BUILD_NUMBER: 
PROMOTED_BUILD_NUMBER: 00
PRODUCT_NAME: OpenJFX
RAW_VERSION: 8.0.132
RELEASE_NAME: 8u132
RELEASE_MILESTONE: ea
UPDATE_STUB_CACHE: false
The CompileOptions.useAnt property has been deprecated and is
scheduled to be
removed in Gradle 2.0. There is no replacement for this property.
:checkJfxrtJar
...
:graphics:compileDecoraNativeShadersLinux
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: error: : No such file or directory
gcc: error: :

[9] Review request for 8169309: Migrate SwingNode to the new float API of JLightweightFrame

2016-11-07 Thread Semyon Sadetsky

Hello Kevin & Jim,

Please review the fix for jfx9:

webrev: http://cr.openjdk.java.net/~ssadetsky/8169309/webrev.00/

bug: https://bugs.openjdk.java.net/browse/JDK-8153522

--Semyon