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

[Jim Graham]

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 place?  To be able to add final to the 
parameters?

[D]Dasher.java, line 268ish - why move the call to out.moveto() down a line?

[D]Stroker.java, line 170ish - you added final to the float params, but not the 
double
[D]Stroker.java, line 196ish - why are ROUND treated differently.  You have a 
question on that as well in a comment.
[D]Stroker.java, line 196ish - CAP_SQUARE would require more than lw/2 padding. 
 I think it needs lw*sqrt(2)/2 padding.

I would think the padding would be (max of the CAP/JOIN values below):
CAP_BUTT - lw/2
CAP_ROUND - lw/2
CAP_SQUARE - lw/2 * sqrt(2)
JOIN_BEVEL - lw/2
JOIN_ROUND - lw/2
JOIN_MITER - max(lw/2, miter_limit * lw)

In other words:
- lw/2 by default
- if CAP_SQUARE then multiply that by sqrt(2)
- if JOIN_MITER then max it with limit

I'm still looking through the management of the closed path detection coordinates, but I thought I'd get at least these 
questions out first before the weekend...


...jim

On 8/25/17 1:09 PM, Laurent Bourgès wrote:

Hi,

Please review Marlin/FX upgrades that provide an efficient path clipper in
Stroker (float / double variants) fixing the bug JDK-8184429


Marlin2D patch (jdk10):
http://cr.openjdk.java.net/~lbourges/marlin/marlin-080.0/
MarlinFX patch (openjfx10):
http://cr.openjdk.java.net/~lbourges/marlinFX/marlin-080.0/

Path Clipper in (D)Stroker:
- it uses outcode computation (cohen - sutherland) for segment edges (2 for
lines, 3 for quads, 4 for cubics)
- it opens the path when a segment is invisible ie special moveTo() and
ignore invisible joins; it does not compute any intersection (line /
curve), it just skips useless segment for better performance and accuracy
- the ClosedPathDetector is needed to infer if the path is closed or not
(call to closePath) to produce caps when appropriate. It reuses the former
PolyStack (moved into Helper classes) to store the forward segments
- the clip rectangle is adjusted either in Stroker but also in
Transformer2D to take into account the mitter limit, stroker width and also
the Renderer offset

That's why it can not be applied to closed paths (fill operations) as the
path must remain closed in such case (concave polygon).
This could be implemented later as it needs to insert corner points when
needed to avoid artefacts; so the algorithm seem more complicated to me.

Marlin2D / FX Patches are slightly different to handle the Renderer offsets.

I tested these patches against my MapBench test with a small clip and
several affine transforms: it does not produce any artefact (0 pixel
difference between clip=true/false)

PS: I also improved the accuracy of Renderer's AFD by using the kaham
compensated-sum approach (later patch)

Cheers,
Laurent Bourgès

Re: Module dependencies

[Kevin Rushforth]

The implementation of javafx.base depends on java.desktop, but nothing 
in the API of javafx.base depends on java.desktop. So javafx.base 
(currently) requires java.desktop, but not transitively. This means that 
it would be possible to remove this dependency in a future version 
without breaking compatibility.


FWIW, the javafx.graphics module is in the same state: it requires 
java.desktop, but not transitively.


-- Kevin


Florian Brunner wrote:

Hi,

I'm still new to the Jigsaw module system, but I've found some documentation 
which is strange:
The Javadoc states that javafx.base depends on java.base:
http://download.java.net/java/jdk9/docs/api/javafx.base-summary.html

But when we look at the source code, we see that javafx.base depends on 
java.desktop:
http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/module-info.java

This sounds more logical as javafx.base depends on the package java.beans which 
is in the java.desktop module, e.g.:
http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptor.java
http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/PropertyDescriptor.java

So I guess, the info in the Javadoc, which was generated, I think, is 
misleading!

That said, as far as I remember, one of the original goals of JavaFX regarding 
to Java SE 8 Compact Profiles/ Java SE 9 modules was to be able to generate a 
tailored JRE, which only includes the JavaFX stack without the AWT/ Swing 
stack. With the module dependency from javafx.base to java.desktop this won't 
be possible now, I think.
This is really bad news for  JavaFX on mobiles and embedded systems, but also 
for desktop applications which ship with a tailored, embedded JRE.

Are there any plans to make JavaFX available without the AWT/ Swing stack?
Will it be possible to change the module dependencies once they are published? 
(Depending on how transitive dependencies are handled and regarded, this could 
be a breaking change.)

Kind regards,
Florian

  

Re: WebView and WebGL

[Michael Hoffer]

Hi Jonathan, hi all,

I would like to bring up the "WritableImage backed by DirectBuffer"
discussion again:

I did my own experiments with WebGL and native rendering. I posted them a
while ago here on the mailing list (https://github.com/miho/VFXWebKit &
https://youtu.be/FlIrY1SlNM4). I came to the conclusion that the most
generic and most important feature that we need for JavaFX is efficient
native buffer support (basically WritableImage backed by DirectBuffer).
This allows for plugging in almost any external rendering technology and
does not involve large API redesigns. Adding OpenGL and/or WebGL could be
done as community projects.

I find it particularly elegant to spawn separate render processes for doing
OpenGL/WebGL. This is basically what modern browsers do. WebKit is a very
complex piece of software that isn't easy to handle. In the past I had too
many bad experiences with WebKit and JavaFX. WebKit could easily tear down
the whole JVM. None of the safety-belts usually provided by Java will help
in such a case.

I would like to suggest that we do a JavaFX meeting at JavaOne for
discussing this topic. Anyone interested?

Regards,
Michael


--
Dr. rer. nat. Michael Hoffer

Twitter: @mihosoft
Webpage: www.mihosoft.eu

Oracle Developer Champion

Goethe-Zentrum für Wissenschaftliches Rechnen (G-CSC)
Goethe-Universität
Kettenhofweg 139
60325 Frankfurt am Main
phone: +49 69 798 25254
i...@michaelhoffer.de

2017-08-25 21:06 GMT+02:00 Jonathan Giles :

> All,
>
> WebGL is something that is currently in the planning pipeline with a
> relatively high priority. This means it is not under active development
> yet, but we already have engineers working on the research towards this
> feature. Once this is concluded and the scope of the work better
> understood, a JEP will be filed to engage the community on this project,
> and notification will be sent to the openjfx-dev mailing list.
>
> In reference to the question on whether WebView uses WebKit rendering or
> JavaFX rendering, I believe the answer is the latter.
>
> -- Jonathan
>
>
>
> On 25/08/17 12:12 PM, John-Val Rose wrote:
>
>> I have a couple of questions about the implementation of WebView within
>> JavaFX.
>>
>> I understand that, at present, it is based on WebKit but does not support
>> WebGL.  For our requirements, WebGL support is essential and I expect that
>> other developers would appreciate support of this kind as well.
>>
>> It appears that WebGL support will not be implemented until Java 10 at the
>> earliest, or, perhaps even later.  As we know, this could be several years
>> away so I would like to offer my time to work on implementing WebGL
>> support
>> ASAP so that it can be released to the community as part of an incremental
>> Java 9 release.
>>
>> How do you feel about this suggestion?
>>
>> Also, could you please let me know that if the current WebView is just a
>> wrapper around WebKit and uses native WebKit rendering, or is it actually
>> using the JavaFX API itself to do the rendering within the JavaFX
>> rendering
>> pipeline?
>>
>> *Graciously,*
>>
>> *John-Val Rose*
>> *Chief Scientist/Architect*
>> *Rosethorn Technology*
>> *Australia*
>>
>
>

Module dependencies

[Florian Brunner]

Hi,

I'm still new to the Jigsaw module system, but I've found some documentation 
which is strange:
The Javadoc states that javafx.base depends on java.base:
http://download.java.net/java/jdk9/docs/api/javafx.base-summary.html

But when we look at the source code, we see that javafx.base depends on 
java.desktop:
http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/module-info.java

This sounds more logical as javafx.base depends on the package java.beans which 
is in the java.desktop module, e.g.:
http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/ReadOnlyPropertyDescriptor.java
http://hg.openjdk.java.net/openjfx/9-dev/rt/file/c734b008e3e8/modules/javafx.base/src/main/java/com/sun/javafx/property/adapter/PropertyDescriptor.java

So I guess, the info in the Javadoc, which was generated, I think, is 
misleading!

That said, as far as I remember, one of the original goals of JavaFX regarding 
to Java SE 8 Compact Profiles/ Java SE 9 modules was to be able to generate a 
tailored JRE, which only includes the JavaFX stack without the AWT/ Swing 
stack. With the module dependency from javafx.base to java.desktop this won't 
be possible now, I think.
This is really bad news for  JavaFX on mobiles and embedded systems, but also 
for desktop applications which ship with a tailored, embedded JRE.

Are there any plans to make JavaFX available without the AWT/ Swing stack?
Will it be possible to change the module dependencies once they are published? 
(Depending on how transitive dependencies are handled and regarded, this could 
be a breaking change.)

Kind regards,
Florian

Re: WebView and WebGL

[Jonathan Giles]

All,

WebGL is something that is currently in the planning pipeline with a 
relatively high priority. This means it is not under active development 
yet, but we already have engineers working on the research towards this 
feature. Once this is concluded and the scope of the work better 
understood, a JEP will be filed to engage the community on this project, 
and notification will be sent to the openjfx-dev mailing list.


In reference to the question on whether WebView uses WebKit rendering or 
JavaFX rendering, I believe the answer is the latter.


-- Jonathan


On 25/08/17 12:12 PM, John-Val Rose wrote:

I have a couple of questions about the implementation of WebView within
JavaFX.

I understand that, at present, it is based on WebKit but does not support
WebGL.  For our requirements, WebGL support is essential and I expect that
other developers would appreciate support of this kind as well.

It appears that WebGL support will not be implemented until Java 10 at the
earliest, or, perhaps even later.  As we know, this could be several years
away so I would like to offer my time to work on implementing WebGL support
ASAP so that it can be released to the community as part of an incremental
Java 9 release.

How do you feel about this suggestion?

Also, could you please let me know that if the current WebView is just a
wrapper around WebKit and uses native WebKit rendering, or is it actually
using the JavaFX API itself to do the rendering within the JavaFX rendering
pipeline?

*Graciously,*

*John-Val Rose*
*Chief Scientist/Architect*
*Rosethorn Technology*
*Australia*

Re: WebView and WebGL

[John-Val Rose]

This *is* the problem: 7 years since a formal issue is raised and still we have 
nothing.

As I said, WebGL support won't happen unless *we* make it happen and I'm in a 
position where I have both a need and time to work on it. I'm sure others would 
help too.

Once someone from Oracle responds to my original questions, we will have a 
better idea of what the future holds.

> On 26 Aug 2017, at 02:22, Nir Lisker  wrote:
> 
> It has been suggested already in
> https://bugs.openjdk.java.net/browse/JDK-8091035.

Re: WebView and WebGL

[Michael Paus]

Am 25.08.17 um 18:22 schrieb Nir Lisker:

It has been suggested already in
https://bugs.openjdk.java.net/browse/JDK-8091035.


I am well aware of these suggestions but did you look at the creation date?

Re: WebView and WebGL

[Nir Lisker]

It has been suggested already in
https://bugs.openjdk.java.net/browse/JDK-8091035.

Re: WebView and WebGL

[John-Val Rose]

I agree with you Michael.

So let's open a discussion as a community and actually get coding.

It won't happen otherwise...

(At least not for 4 years or so)

> On 25 Aug 2017, at 17:34, Michael Paus  wrote:
> 
> I also find it important to get WebGL support into WebView as soon as possible
> but I fear that this is not such an easy task because there are a few things
> to consider. From my point of view, for example, it would not make much sense
> to implement WebGL exclusively in the context of the WebView. JavaFX
> itself also needs some high-performance, cross-platform low-level rendering
> engine which should be compatible with WebGL in a similar way as the JavaFX
> Canvas is compatible with the HTML 5 Canvas. But once you have such a
> cross-platform, GL compatible rendering engine you have to ask yourself why
> JavaFX still needs different internal Prism renderer implementations and would
> not just use the one cross platform engine. All this needs careful 
> consideration.
> 
> Michael
> 
>> Am 25.08.17 um 02:12 schrieb John-Val Rose:
>> I have a couple of questions about the implementation of WebView within
>> JavaFX.
>> 
>> I understand that, at present, it is based on WebKit but does not support
>> WebGL.  For our requirements, WebGL support is essential and I expect that
>> other developers would appreciate support of this kind as well.
>> 
>> It appears that WebGL support will not be implemented until Java 10 at the
>> earliest, or, perhaps even later.  As we know, this could be several years
>> away so I would like to offer my time to work on implementing WebGL support
>> ASAP so that it can be released to the community as part of an incremental
>> Java 9 release.
>> 
>> How do you feel about this suggestion?
>> 
>> Also, could you please let me know that if the current WebView is just a
>> wrapper around WebKit and uses native WebKit rendering, or is it actually
>> using the JavaFX API itself to do the rendering within the JavaFX rendering
>> pipeline?
>> 
>> *Graciously,*
>> 
>> *John-Val Rose*
>> *Chief Scientist/Architect*
>> *Rosethorn Technology*
>> *Australia*
> 
> 

Re: WebView and WebGL

[Michael Paus]

I also find it important to get WebGL support into WebView as soon as 
possible

but I fear that this is not such an easy task because there are a few things
to consider. From my point of view, for example, it would not make much 
sense

to implement WebGL exclusively in the context of the WebView. JavaFX
itself also needs some high-performance, cross-platform low-level rendering
engine which should be compatible with WebGL in a similar way as the JavaFX
Canvas is compatible with the HTML 5 Canvas. But once you have such a
cross-platform, GL compatible rendering engine you have to ask yourself why
JavaFX still needs different internal Prism renderer implementations and 
would
not just use the one cross platform engine. All this needs careful 
consideration.


Michael

Am 25.08.17 um 02:12 schrieb John-Val Rose:

I have a couple of questions about the implementation of WebView within
JavaFX.

I understand that, at present, it is based on WebKit but does not support
WebGL.  For our requirements, WebGL support is essential and I expect that
other developers would appreciate support of this kind as well.

It appears that WebGL support will not be implemented until Java 10 at the
earliest, or, perhaps even later.  As we know, this could be several years
away so I would like to offer my time to work on implementing WebGL support
ASAP so that it can be released to the community as part of an incremental
Java 9 release.

How do you feel about this suggestion?

Also, could you please let me know that if the current WebView is just a
wrapper around WebKit and uses native WebKit rendering, or is it actually
using the JavaFX API itself to do the rendering within the JavaFX rendering
pipeline?

*Graciously,*

*John-Val Rose*
*Chief Scientist/Architect*
*Rosethorn Technology*
*Australia*