Missing tick marks on charts

[Ty Young]

Does anyone know whats going on with this:


https://imgur.com/a/g7Ti3Zc


It doesn't seem to be a space issue, even the top tick mark is missing 
on the one chart...

Re: [Rev 04] RFR: 8238954: Improve performance of tiled snapshot rendering

[Kevin Rushforth]

On Tue, 17 Mar 2020 11:43:16 GMT, Frederic Thevenet 
 wrote:

>> Issue JDK-8088198, where an exception would be thrown when trying to capture 
>> a snapshot whose final dimensions would be
>> larger than the running platform's maximum supported texture size, was 
>> addressed in openjfx14. The fix, based around
>> the idea of capturing as many tiles of the maximum possible size and 
>> re-compositing the final snapshot out of these, is
>> currently only attempted after the original, non-tiled, strategy has already 
>> failed. This was decided to avoid any risk
>> of regressions, either in terms of performances and correctness, while still 
>> offering some relief to the original
>> issue.  This follow-on issue aims to propose a fix to the original issue, 
>> that is able to correctly decide on the best
>> snapshot strategy (tiled or not) to adopt before applying it and ensure best 
>> performances possible when tiling is
>> necessary while still introducing no regressions compared to the original 
>> solution.
>
> Frederic Thevenet has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Revert changes in import statements

Overall, this looks quite good. In particular the tiled rendering, as 
implemented by the `renderTile` method, should be
reasonably efficient.

My only high-level comment is that I'm somewhat skeptical of 
`computeOptimumTileSize` to determine the size and
direction of tiling. I note that in the case of an image that is tiled in both 
X and Y, there are at most 4 distinct
tile sizes if it doesn't fit evenly. In the case where only one of X or Y is 
tiled, there are at most 2 distinct tile
sizes. Here is an example:

+---+---+  .  +---+
|   |   |  .  |   |
| M | M |  .  |   R   |
|   |   |  .  |   |
+---+---+  .  +---+
|   |   |  .  |   |
| M | M |  .  |   R   |
|   |   |  .  |   |
+---+---+  .  +---+
  .   ..  .
+---+---+  .  +---+
|   |   |  .  |   |
| M | M |  .  |   R   |
|   |   |  .  |   |
+---+---+  .  +---+
| B | B |  .  |   C   |
+---+---+  .  +---+

Where `M` represents the middle set of tiles each with a size of `tileW x 
tileH`. `R` is the right hand column of
tiles, `B` is bottom row, and `C` is corner.

Recognizing this, I wonder if it might be better to always use the maximum tile 
size, but fill all of the middle tiles
of that size first, and then pick up the right and/or bottom edges as needed. 
This will minimize thrashing (no more
than 3 changes of tile size), while avoiding the more complicated logic that 
tries to keep the tiles all the same size
at the cost of smaller tiles, and which has to fall back to using uneven tiles 
anyway. If you do it this way, there is
also no need to have code that switches the order of the inner loop. It will 
naturally handle that.

Either way, I'd like to see some additional system tests that cover all of the 
cases of X and Y fitting/not-fitting
exactly (and if you stick with your current approach, X or Y as the inner loop).

I left a couple inline comments as well.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
 line 1495:

> 1494: }
> 1495: //Copy tile's pixel into the target image
> 1496: targetImg.image.setPixels(xOffset, yOffset, w, h,

Typo: should be "pixels" (plural)

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
 line 1523:

> 1522:
> 1523: private int computeOptimumTileSize(int size, int maxSize){
> 1524: return computeOptimumTileSize(size, maxSize, null);

Minor: add a space before the `{` , although this will become a moot point if 
you take my suggestion of eliminating
this method entirely.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java
 line 1527:

> 1526:
> 1527: private int computeOptimumTileSize(int size, int maxSize, 
> AtomicBoolean isDivExact) {
> 1528: // This method attempts to find the smallest exact 
> divider for the provided `size`

I don't care for the use of `AtomicBoolean` to effect a pass-by-reference. You 
aren't relying on the atomic nature, so
it just ends up being confusing. I recommend using `boolean[]`, although this 
will become a moot point if you take my
suggestion of eliminating this method entirely.

-

PR: https://git.openjdk.java.net/jfx/pull/112

Re: Questions ad JavaScript in JavaFX' WebEngine

[Kevin Rushforth]

WebEngine uses WebKit's JavaScriptCore as its JavaScript engine. The 
sources are in the jfx repo, along with the JavaFX-specific classes that 
implement the two-way Java <--> JavaScript bridge. Other than the public 
API docs for WebEngine, which you referred to in your message, there 
isn't any documentation of the interface. What sort of information are 
you looking for?


-- Kevin


On 5/8/2020 7:01 AM, Rony G. Flatscher wrote:

Wondering which JavaScript engine gets referred to in WebEngine [1].

In case it is currently (JavaFX 14) Nashorn [2], what happens after Nashorn 
gets removed from the
next [3] version? In case it is WebKit's JavaScriptCore [4] where can one study 
the interface from
WebEngine to it?

---rony

[1] WebEngine: 

[2] Nashorn: 
[3] Nashorn removal from JDK 15: 
[4] JavaScriptCore: 

Re: Next steps ? (Re: An attempt of a CSR draft ... (Re: A new WIP (PR # 192) (Re: WIP version with PI compile (Re: A WIP for JDK-8238080 for review/discussion (Re: "Internal review ID 9063426: "FXMLL

[Kevin Rushforth]

Hi Rony,

I'm finally getting back to this. I took a look at 
https://github.com/openjdk/jfx/pull/192 and I like that as the direction 
for this enhancement.


The initial CSR you have is a good start.

Next steps are:

1. Update the "Introduction to FXML" specification (see my comment in 
the PR)
2. Update PR 192 with the draft CSR as a comment, modifying it to 
include the above additions to "Introduction to FXML"

3. Remove WIP from the title

You can then close the other two PRs (129 and 187).

Thanks.

-- Kevin


On 4/28/2020 6:15 AM, Rony G. Flatscher wrote:


Hi Kevin,

what should be the next steps?

Should I remove "WIP" from the title in 
 and add the CSR draft text 
of my last e-mail as a "CSR" comment with PR # 192, thereby requesting 
it to be added to 
?


Please advise.

TIA,

---rony

P.S.: This is the RFE:

  * RFE (2020-01-24):


These are the three versions (all with appropriate unit tests) that I 
came up with chronologically to implement the RFE, would prefer the 
latest version (PR # 192):


  * Compile if Compilable implemented (2020-02-28):

  * Compile if compile PI and Compilable is implemented (2020-04-11):

  * Compile with fallback, if Compilable is implemented, compile PI
for fine-grained control (2020-04-14):



On 22.04.2020 20:01, Rony G. Flatscher wrote:

Hi Kevin,

as I am not able to file a CSR with the issue you suggested to come up with a 
draft, so here it goes:

 Summary
 ===
 Have javafx.fxml.FXMLLoader compile FXML scripts before evaluating them, 
if the script engine
 implements the javax.script.Compilable interface to speed up execution. In 
case compilation
 throws a javax.script.ScriptException fall back to evaluating the 
uncompiled script. Allow
 control of script compilation with a "compile" PI for FXML files.

 Problem
 ===
 javafx.fxml.FXMLLoader is able to execute scripts in Java script languages
 (javax.script.ScriptEngine implementations) referred to or embedded in a 
FXML file.

 If a script engine implements the javax.script.Compilable interface, then 
such scripts could be
 compiled and the resulting javax.script.CompiledScript could be executed 
instead using its
 eval() methods.

 Evaluating the javax.script.CompiledScript objects may help speed up the 
execution of script
 invocations, especially for scripts defined for event attributes in FXML 
elements (e.g. like
 onMouseMove) which may be repetitively invoked and evaluated.

 Solution
 
 Before evaluating the script code test whether the 
javax.script.ScriptEngine implements
 javax.script.Compilable. If so, compile the script to a 
javax.script.CompiledScript object first
 and then use its eval() method to evaluate the script, otherwise continue 
to use the
 javax.script.ScriptEngine's eval() method instead. Should compilation of a 
script yield
 (unexpectedly) a javax.script.ScriptException then fall back to using the
 javax.script.ScriptEngine's eval() method. A new process instruction 
"compile" allows control of
 the compilation of scripts ("true" sets compilation on, "false" to set 
compilation off) in FXML
 files.

 Specification
 =
 If a javax.script.ScriptEngine implements the javax.script.Compilable 
interface, then use its
 compile() method to compile the script to a javax.script.CompiledScript 
object and use its
 eval() method to run the script. In the case that the compilation throws 
(unexpectedly) a
 javax.script.ScriptException log a warning and fall back to using the
 javax.script.ScriptEngine's eval() method instead.
 To allow setting this feature off and on while processing the FXML file a 
"compile" process
 instruction ("" or "") gets defined that 
allows to turn
 compilation off and on throughout a FXML file.

Having never seen a real CSR I hope that this matches what is expected and is 
helpful for
assessment. If not please advise (got the name of these fields from [1]).

---

Also added brief information about the respective test units (what they test 
and yield) in the WIP  [2].

---rony

[1] "CSR-FAQ":

[2] "WIP: Script compilable+compile PI+fallback: 8238080: FXMLLoader: if script 
engines implement
javax.script.Compilable compile scripts 
#192":


On 20.04.2020 14:58, Rony G. Flatscher wrote:

There is a new WIP at:

 This WIP adds the ability for a fallback in case compilation of scripts 
fails, in which case a
 warning gets issued about this 

Re: [Rev 01] RFR: 8242861: Update ImagePattern to apply SVG pattern transforms

[Kevin Rushforth]

On Thu, 23 Apr 2020 12:31:34 GMT, Arun Joseph  wrote:

>> fillPath() and fillRect() functions in
>> [GraphicsContextJava.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/GraphicsContextJava.cpp)
>> use Image::drawPattern() for applying patterns as fill. But drawPattern() 
>> doesn't use patternTransform argument as
>> ImagePattern doesn't have the same attribute. So, the final image won't be 
>> transformed.
>
> Arun Joseph has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add CanvasTest

This works for the HW accelerated pipeline, but you need to also modify the SW 
pipeline and J2D pipeline (used for
printing). See
[SWPaint::computeImagePatternTransform](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/sw/SWPaint.java#L280)
and the ImagePattern case in
[J2DPrismGraphics::toJ2DPaint](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/prism/j2d/J2DPrismGraphics.java#L282).
In the J2D pipeline case, you will have more work to do, since it doesn't use a 
pattern transform that I can see.

-

Changes requested by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/190