Re: [jfx15] RFR: 8248381: Create a daemon thread for MonocleTimer
On Thu, 2 Jul 2020 23:46:40 GMT, Kevin Rushforth wrote: > Given that this is a regression introduced in JavaFX 14, this fix seems like > a good candidate for JavaFX 15 ... Actually, this is a regression introduced in JavaFX 15, so we have the chance to fix it before it's ever released. > Go ahead and retarget your PR to the `jfx15` branch (you should not need to > merge anything) ... Like [this](https://github.blog/2016-08-15-change-the-base-branch-of-a-pull-request/)? I'll try that now. - PR: https://git.openjdk.java.net/jfx/pull/256
Re: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v2]
On Tue, 30 Jun 2020 18:28:11 GMT, Oliver Schmidtmer
wrote:
>> In edge cases where monitor scaling of 1.25 or 1.75 is active, Math.ceil and
>> Math.round produce different results and
>> EmbeddedScene#getPixels in JFXPanel#paintComponent causes an off-by-one
>> error on the line width and therefore sheared
>> rendering. The changes were already proposed by the submitter in
>> JBS-8220484.
>>
>> OCA is signed and send.
>
> Oliver Schmidtmer has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Change to Math.ceil and add test
I left specific feedback, mostly on the test, but also one question on the fix.
For the test, make sure you can run it as follows:
gradle --info -PFULL_TEST=true -PUSE_ROBOT=true cleanTest :systemTests:test
--tests JFXPanelScaledTest
(presuming you rename it to `JFXPanelScaledTest`)
It should fail without your fix and pass with your fix.
Currently, it will fail because of the call to `setAccessible` (see inline
comments).
tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 2:
> 1: /*
> 2: * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
This should be `Copyright (c) 2020, Oracle` ...
tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 39:
> 38: import javax.swing.*;
> 39: import java.awt.*;
> 40: import java.awt.image.BufferedImage;
We generally avoid wildcard imports.
tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 49:
> 48:
> 49: public class JDK8220484Test {
> 50: static CountDownLatch launchLatch;
We no longer use the pattern of naming our test classes after the bug ID. I
recommend a descriptive name for the test
class.
tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 71:
> 70: try {
> 71: if (!launchLatch.await(5 * TIMEOUT, TimeUnit.MILLISECONDS)) {
> 72: throw new AssertionFailedError("Timeout waiting for
> Application to launch (" + (5 * TIMEOUT) + "
> seconds)");
If you add `throws Exception` to the this setup method, then you can replace
the entire try / catch block with simply:
assertTrue("Timeout waiting for Application to launch",
launchLatch.await(5 * TIMEOUT, TimeUnit.MILLISECONDS));
This is the pattern we use for our newer system tests.
tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 90:
> 89: Field fpixelsIm = JFXPanel.class.getDeclaredField("pixelsIm");
> 90: fpixelsIm.setAccessible(true);
> 91: BufferedImage pixelsIm = (BufferedImage)
> fpixelsIm.get(myApp.jfxPanel);
This isn't the pattern we use to access internal fields of a JavaFX class, and
won't work.
We typically use the "shim" pattern for such white-box testing. Can you look
into adding shims to the `javafx.swing`
module? Many of the other modules already have shims, so you can use that as a
pattern. It will require adding a
package-scope `test_getPixelsIm` method to `JFXPanel`.
Alternatively, you can use AWT `Robot` to read the JFXPanel pixels.
tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 93:
> 92:
> 93:
> 94: assertEquals(127, pixelsIm.getWidth());
Minor: a single blank line is sufficient.
tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 103:
> 102: for (int y = 90; y < 115; y++) {
> 103: if(colorOfDiagonal == pixelsIm.getRGB( x, y )) {
> 104: fail( "image is skewed" );
Are you sure that an equality test will work on all platforms and
configurations? We usually use a tolerance when
comparing colors whose components are other than 0 or 255.
Somewhat related to this, is the expected value of `181` coming from the
default value of the button border? It might
be more robust to fill the Scene with a stroked rectangle whose color you
control (e.g. set to black). Either that or
set the color of the button border using an inline CSS style so you aren't
dependent on the default inherited from the
`modena.css` style sheet.
Minor: add a space after the `if` and remove the extra spaces surrounding the
function arguments `x, y`.
tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 104:
> 103: if(colorOfDiagonal == pixelsIm.getRGB( x, y )) {
> 104: fail( "image is skewed" );
> 105: }
Minor: remove the extra spaces surrounding the function argument.
tests/system/src/test/java/test/javafx/embed/swing/JDK8220484Test.java line 26:
> 25:
> 26: package test.javafx.embed.swing;
> 27:
This test will need to move to the `test.robot.javafx.embed.swing` package
since it relies on reading the actual
rendered pixels.
modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/EmbeddedScene.java
line 235:
> 234:
Re: RFR: 8244212: Optionally download media and webkit libraries from latest openjfx EA build
On Wed, 1 Jul 2020 18:27:01 GMT, Johan Vos wrote: >> Do the build instructions need to be updated? > > The build instruction can indeed refer to WEBKIT-MEDIA-STUBS.md now. I updated https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-PlatformPrerequisites. - PR: https://git.openjdk.java.net/jfx/pull/202
Re: RFR: 8220484: JFXPanel renders a slanted image with a hidpi monitor scale of 125% or 175% [v2]
On Tue, 30 Jun 2020 18:21:52 GMT, Oliver Schmidtmer wrote: >> In 2D, we normally use sun.java2d.pipe.Region.clipRound as it also checks >> for -ve/+ve max INTEGER but I guess that is >> internal class to FX so it's ok to use Math.round. Approval pending test >> creation. > > While both might work, as long as there is no mixed usage of round and ceil, > Math.ceil seems to be better. > > I'm not sure if the timed waiting for the resizes is the best way for > ensuring that the buffer is resized to the new > bounds, so I'm open for suggestions. To me at least it seems to create a > reproducible sheared output after the second > resize in the test case and not anymore after changing the calculations to > Math.ceil. This fix might be a candidate for JavaFX 15, so I recommend to _not_ merge the master branch. If we don't spot anything of concern during the review, then we might ask you to retarget your PR to the `jfx15` branch. - PR: https://git.openjdk.java.net/jfx/pull/246
Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2]
On Thu, 2 Jul 2020 12:41:34 GMT, Kevin Rushforth wrote:
>> I tested this pull request on all of the following platforms:
>>
>> * JavaFX desktop platforms (*amd64* architecture)
>> * Windows SDK on Windows 10 Pro Version 2004
>> * Mac OS X SDK on macOS 10.15.5 (Catalina)
>> * Linux SDK on Ubuntu 16.04.6 LTS (Xenial Xerus)
>> * JavaFX embedded platforms (*armhf* architecture)
>> * armv6hf SDK (Monocle EPD) on Ubuntu 14.04.6 LTS (Trusty Tahr)
>> * armv6hf SDK (Monocle VNC) on Ubuntu 20.04 LTS (Focal Fossa)
>>
>> This is a tricky timing problem on most platforms, so I used rather
>> intrusive techniques to catch the error and verify
>> it was fixed. The bug is easily visible only on the Monocle VNC platform.
>> ### Desktop
>>
>> I tested the desktop platforms as follows:
>>
>> 1. I added `assert` statements and calls to `Thread.sleep` as shown by [this
>> commit](https://github.com/jgneff/javafx-graphics/commit/ffc639e4) to catch
>> the error. It looks like a lot of changes,
>> but they simply call `sleep` to change the timing of the threads so that the
>> JavaFX Application Thread is unable to
>> keep up with the QuantumRenderer. The `assert` statements catch the error
>> when the rendering thread starts looking for
>> an unused buffer.
>> All platforms printed many `InvalidMarkException` errors as the buffer
>> position was modified while in use on the JavaFX
>> application thread. The Linux and Windows platforms printed, "Exception
>> in thread 'JavaFX Application Thread'
>> java.nio.InvalidMarkException," while the macOS platform printed,
>> "Exception in thread 'AppKit Thread'
>> java.nio.InvalidMarkException."
>>
>> 2. I applied the fix to call `getBuffer` instead of `getPixels` in
>> `QueuedPixelSource`.
>>
>> 3. After the fix, no errors were detected by the assertions on any of the
>> platforms.
>>
>> ### Embedded
>>
>> I tested the embedded platforms as follows:
>>
>> 1. I added only `assert` statements to the `HeadlessScreen` and `EPDScreen`
>> classes, as shown below. Both platforms
>> printed many `InvalidMarkException` errors as the buffer position was
>> modified while in use on the JavaFX application
>> thread. 2. I applied the fix to call `getBuffer` instead of `getPixels` in
>> `QueuedPixelSource`.
>>
>> 3. After the fix, no errors were detected by the assertions on either
>> platform.
>>
>> `HeadlessScreen` and `EPDScreen`
>>
>> @Override
>> public synchronized void uploadPixels(Buffer b, int x, int y,
>> int width, int height, float alpha) {
>> +assert b.mark() == b;
>> pixels.composePixels(b, x, y, width, height, alpha);
>> +assert b.reset() == b;
>> }
>>
>> For the Monocle VNC platform, you can also simply connect and watch the bug
>> corrupt the frames sent to the VNC client,
>> as shown in my prior comment on this pull request.
>> ### Other results
>>
>> I found some unexpected results, listed below.
>>
>> * JavaFX on Linux does not limit its frame rate to 60 Hz when using the
>> hardware pipeline, reaching over 350 frames per
>> second.
>>
>> * JavaFX on macOS ignores the system property `-Djavafx.animation.pulse=8`
>> and runs at 60 Hz, even though it prints the
>> message "Setting PULSE_DURATION to 8 hz."
>>
>> * JavaFX on macOS prints the error shown below when `Platform.exit` is
>> called to end the application. The error also
>> occurs on JavaFX 14.0.1 and 15-ea+6. The error does not occur when the
>> window is closed manually using the mouse.
>>
>> Java has been detached already, but someone is still trying to use it at
>> -[GlassViewDelegate dealloc]:
>> /Users/john/src/jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m:204
>> 0 libglass.dylib 0x00010eb6c05d -[GlassViewDelegate dealloc] + 221
>> 1 libglass.dylib 0x00010eb71af6 -[GlassView3D dealloc] + 246
>> 2 libobjc.A.dylib 0x7fff66937054
>> _ZN19AutoreleasePoolPage12releaseUntilEPP11objc_object + 134
>> 3 libobjc.A.dylib 0x7fff6691bdba objc_autoreleasePoolPop + 175
>> 4 CoreFoundation 0x7fff2dad23c5
>> __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
>> 5 CoreFoundation 0x7fff2dad22f7 __CFRunLoopDoObservers + 457
>> 6 CoreFoundation 0x7fff2dad1895 __CFRunLoopRun + 874
>> 7 CoreFoundation 0x7fff2dad0ece CFRunLoopRunSpecific + 462
>> 8 libjli.dylib 0x00010be945c1 CreateExecutionEnvironment + 399
>> 9 libjli.dylib 0x00010be90752 JLI_Launch + 1354
>> 10 java 0x00010be83ca1 main + 375
>> 11 libdyld.dylib0x7fff67acdcc9 start + 1
>> 12 ??? 0x000b 0x0 + 11
>>
>> ### Test scripts
>>
>> Below are the scripts I used to run the tests. The scripts include the
>> system property `-Djavafx.animation.pulse=8`,
>> but I removed it when trying to recreate the bug with the added `assert` and
>> `sleep` statements.
>> linux.sh
Re: RFR: 8248381: Create a daemon thread for MonocleTimer
On Mon, 29 Jun 2020 11:33:24 GMT, Johan Vos wrote: >> I think the code in the `_stop` method is correct after all. >> >> The `MonocleTimer` class is written to allow for multiple calls to the pair >> of `_start` and `_stop` methods (even >> though I don't think that ever happens), and the static >> `ScheduledThreadPoolExecutor`, named `scheduler`, is created >> only once and reused on subsequent calls. Changing the `_stop` method to >> call `task.cancel(true)` still leaves the >> timer thread running, which prevents the JavaFX application from exiting >> when the timer thread is a user thread. >> Furthermore, whether it's a user or daemon thread, if the call to >> `task.cancel(true)` happens to run exactly when the >> periodic task is *in progress*, the `timerRunnable` lambda in >> `QuantumToolkit` prints the stack trace when it catches >> the `InterruptedException`. java.lang.InterruptedException: >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit >>.lambda$runToolkit$12(QuantumToolkit.java:345) >> at java.base/java.util.concurrent.Executors$RunnableAdapter >>.call(Executors.java:515) >> at java.base/java.util.concurrent.FutureTask >>.runAndReset(FutureTask.java:305) >> at >> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask >>.run(ScheduledThreadPoolExecutor.java:305) >> at java.base/java.util.concurrent.ThreadPoolExecutor >>.runWorker(ThreadPoolExecutor.java:1130) >> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker >>.run(ThreadPoolExecutor.java:630) >> at java.base/java.lang.Thread >>.run(Thread.java:832) >> >> So the call to `task.cancel(false)` is correct. >> >> Changing the `_stop` method to shut down the `scheduler` will terminate the >> associated thread, regardless of its daemon >> status, but a subsequent call to `_start` will throw a >> `RejectedExecutionException` when trying to schedule the timer >> task: java.util.concurrent.RejectedExecutionException: >> Task >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@b1fe89 >> [Not completed, task = >> java.util.concurrent.Executors$RunnableAdapter@1f85c96 >> [Wrapped task = >> com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$111/0x34563828@141859b]] >> rejected from java.util.concurrent.ScheduledThreadPoolExecutor@55f462 >> [Terminated, pool size = 0, active threads = 0, queued tasks = 0, >> completed tasks = 0] >> at java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy >>.rejectedExecution(ThreadPoolExecutor.java:2057) >> at java.base/java.util.concurrent.ThreadPoolExecutor >>.reject(ThreadPoolExecutor.java:827) >> at java.base/java.util.concurrent.ScheduledThreadPoolExecutor >>.delayedExecute(ScheduledThreadPoolExecutor.java:340) >> at java.base/java.util.concurrent.ScheduledThreadPoolExecutor >>.scheduleAtFixedRate(ScheduledThreadPoolExecutor.java:632) >> at javafx.graphics/com.sun.glass.ui.monocle.MonocleTimer >>._start(MonocleTimer.java:64) >> at javafx.graphics/com.sun.glass.ui.Timer >>.start(Timer.java:96) >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit >>.runToolkit(QuantumToolkit.java:384) >> at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit >>.lambda$startup$10(QuantumToolkit.java:280) >> at javafx.graphics/com.sun.glass.ui.Application >>.lambda$run$1(Application.java:153) >> at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor >>.runLoop(RunnableProcessor.java:92) >> at javafx.graphics/com.sun.glass.ui.monocle.RunnableProcessor >>.run(RunnableProcessor.java:51) >> at java.base/java.lang.Thread >>.run(Thread.java:832) >> >> So if we want `MonocleTimer` to reuse a single `ScheduledThreadPoolExecutor` >> object, I think the only way to make sure >> that its timer thread exits when the application exits is to set its daemon >> status to `true`. > > While the PR should indeed fix the original issue, I'm unsure about the > behavior of multiple invocations of start/stop > rather than using the (nop) pause method. However, it seems this behavior is > similar on other platforms, so I assume it > is by design. Given that this is a regression introduced in JavaFX 14, this fix seems like a good candidate for JavaFX 15, so I recommend to _not_ merge the master branch. Go ahead and retarget your PR to the `jfx15` branch (you should not need to merge anything), although we will need to satisfy ourselves that the risk of further regression is low. - PR: https://git.openjdk.java.net/jfx/pull/256
Re: RFR: 8176270: Adding ChangeListener to TextField.selectedTextProperty causes StringOutOfBoundsException [v6]
On Tue, 30 Jun 2020 23:14:52 GMT, Kevin Rushforth wrote: >> Robert Lichtenberger has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8176270: Adding ChangeListener to TextField.selectedTextProperty causes >> StringOutOfBoundsException >> >> Move replaceSelectionAtEndWithListener test to general test class. >> Add a more general test for selection/text properties and >> replace/undo/redo operations. > > Changing from using bindings to using listeners seems reasonable as long as > there can't be a memory leak as a result > (it should be fine). > As I note inline below, I think the clamping is still wrong. Maybe you can't > ever hit a case where it matters now, but > it should still be fixed. I need to do some more testing, but this looks like the right approach. This fix might be a candidate for JavaFX 15, so I recommend to _not_ merge the master branch. If I don't spot anything of concern during the review, then I will ask you to retarget your PR to the `jfx15` branch. - PR: https://git.openjdk.java.net/jfx/pull/138
JBS bugs and enhancements still targeted to openjfx15
To: OpenJFX Authors, Committers, and Reviewers Now that we are in the rampdown for openjfx15, I ask everyone who is an Author, Committer, or Reviewer in the OpenJFX project, and who has a JBS issue targeted to openjfx15 (that is, "fixversion==openjfx15"), to look at their JBS issues and move them to a future release, unless they are among the few candidates for getting into 15 during rampdown. 1. Here is a JBS query for bugs still targeted to openjfx15: https://bugs.openjdk.java.net/issues/?filter=39194 At the time of sending this email, there are 28 bugs on that list. Many (probably most) of these should be retargeted to openjfx16, or to "tbd" if you don't intend to fix them within the next 6 months. 2. Here is a JBS query for enhancements and other tasks still targeted to openjfx15: https://bugs.openjdk.java.net/issues/?filter=39195 At the time of sending this email, there are 15 issues on that list. None of these seem like candidates to consider for openjfx15, so they should be retargeted to either "openjfx16", if they are planned for the next 6 months, or "tbd", otherwise. Let me know if you have any questions. Thank you. -- Kevin
JavaFX 15 is in Rampdown Phase One (RDP1)
JavaFX 15 is now in Rampdown Phase One (RDP1) [1]. We have forked a new jfx15 branch [2] for stabilizing the JavaFX 15 release. Here is the short summary of what this means: - The master branch of the jfx repo is available for integrating bug fixes or enhancements for openjfx16. Most fixes will be integrated to master for 16. - The jfx15 branch of the jfx repo is now open for integrating fixes for openjfx15 that meet the RDP1 criteria as outlined below. - Reviewers and Committers now have an additional responsibility to verify the target branch of each pull request. - I will periodically sync jfx15 --> master, meaning that developers should integrate fixes to one or the other, not both DETAILS: P1-P3 bug fixes, and test or doc fixes of any priority are good candidates for integrating to jfx15 during RDP1. The only hard restriction is that enhancements need explicit approval, over and above the review of the PR, to go into jfx15. The bar for such approval is appropriately high. We also need to be careful to avoid potentially risky fixes during this time. Note that these restrictions apply to the jfx15 branch. The master branch is open for all openjfx16 fixes, including enhancements. As a reminder, we are using a single openjdk/jfx GitHub repo with stabilization branches [3] rather than creating separate stabilization repos. The jfx15 branch is used to stabilize the upcoming openjfx15 release. Please be aware of this, especially if you are a Reviewer or Committer in the Project. This allows all pull requests to be in the same place, but care needs to be taken for any PR that is targeted to jfx15 to ensure that it doesn't contain any commits from master after the jfx15 fork date. What that means is that if you intend a PR to be for jfx15, don't merge master into your local source branch! IMPORTANT: Reviewers and Committers now have an extra responsibility to double-check the target branch of each PR that they review, integrate, or sponsor. By default a PR will be targeted to `master` which is the main development line (OpenJFX 16 as of today). This is usually what we want. A PR should be targeted to `jfx15` if, and only if, it is intended for OpenJFX 15 and meets the criteria for the current rampdown phase (we're in RDP1 as of today). Reviewers are advised to be extra cautious in approving potentially risky fixes targeted to `jfx15`. If there is a concern, then a reviewer can as part of the review indicate that the PR should be retargeted to `master` for 16. Reviewers also need to be extra careful when reviewing PRs targeted to jfx15 that it doesn't mistakenly contain any commits from the master branch. You'll be able to tell because the diffs will contain changes that are not part of the fix being reviewed. Such a PR will either need to be closed and redone, or it will need to be rebased and force-pushed. We will use the same rules for RDP1 that the JDK uses [4], with the same three modifications we did for the previous release: 1. Approval is needed from one of the OpenJFX project leads (not the OpenJDK project lead) 2. Since we are not part of the JDK, we need to use labels that do not collide with the JDK 15 release. As an obvious choice, derived from the JBS fix version, we will use "openjfx15-enhancement-request", "openjfx15-enhancement-yes", "openjfx15-enhancement-no" and "openjfx15-enhancement-nmi" as corresponding labels. 3. No explicit approval (no JBS label) is needed to integrate P4 bugs to the jfx15 branch during RDP1, as long as those bugs have otherwise met the usual code review criteria. Having said that, most P4 bugs should now go into master for openjfx16, since we do not want to risk anything that would destabilize the openjfx15 release without a compelling reason. Also, we have only 4 weeks until RDP2 of openjfx15 and we would be better served fixing higher priority bugs. Note that doc bugs and test bugs of any priority are fine to fix for openjfx15 during this time. Let me know if there are any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-March/025410.html [2] https://github.com/openjdk/jfx/tree/jfx15 [3] https://github.com/openjdk/jfx/branches/all [4] http://openjdk.java.net/jeps/3
Integrated: 8248317: Change JavaFX release version to 16
On Tue, 30 Jun 2020 15:30:31 GMT, Kevin Rushforth wrote: > Bump the version number of JavaFX to 16. I will integrate this immediately > after forking the `jfx15` stabilization > branch. This pull request has now been integrated. Changeset: a4f31505 Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/a4f31505 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod 8248317: Change JavaFX release version to 16 Reviewed-by: arapte, jvos - PR: https://git.openjdk.java.net/jfx/pull/260
Integrated: 8201570: Get two bytes for the Linux input event type, not four
On Sat, 27 Jun 2020 00:12:41 GMT, John Neffenger wrote: > Fixes [JDK-8201570](https://bugs.openjdk.java.net/browse/JDK-8201570). This pull request has now been integrated. Changeset: 126637f5 Author:John Neffenger Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/commit/126637f5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8201570: Get two bytes for the Linux input event type, not four Reviewed-by: jvos - PR: https://git.openjdk.java.net/jfx/pull/257
Integrated: 8247963: Update SQLite to version 3.32.3
On Wed, 1 Jul 2020 17:14:30 GMT, Arun Joseph wrote: > We currently use SQLite version 3.31.1. We should update to the latest stable > release version 3.32.3 released on > 2020-06-18. https://www.sqlite.org/index.html This pull request has now been integrated. Changeset: f3a04465 Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/f3a04465 Stats: 4413 lines in 4 files changed: 1061 ins; 2492 del; 860 mod 8247963: Update SQLite to version 3.32.3 Reviewed-by: kcr, ghb - PR: https://git.openjdk.java.net/jfx/pull/261
Re: RFR: 8247963: Update SQLite to version 3.32.3
On Wed, 1 Jul 2020 17:14:30 GMT, Arun Joseph wrote: > We currently use SQLite version 3.31.1. We should update to the latest stable > release version 3.32.3 released on > 2020-06-18. https://www.sqlite.org/index.html Looks good to me - Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/261
Re: MacOS Big Sur and OpenJFX on Arm Macs
This is probably a toolchain issue indeed. There shouldn't be a real difference between OpenJFX and other Mac applications. It's probably (hopefully) just compiling/linking with a few specific flags to set the CPU. - Johan On Thu, Jul 2, 2020 at 2:51 PM Kevin Rushforth wrote: > At WWDC, Apple indicated that they have run the JDK on prototype Arm HW > using Rosetta2. Once we get our hands on some HW we'll test JavaFX as > well. I expect that it will run reasonably well. > > I think that an ARM port for JavaFX won't be too difficult, although I > doubt the existence of Linux ARM for embedded platforms will help much > with the Mac. Most of the work will be upgrading to Xcode 12 and > producing universal (fat) binaries again, which we did back in the very > early days for ppc and intel. > > As for a Metal port, we do plan to get started on that soon (we've done > some very preliminary looking). > > -- Kevin > > > On 7/1/2020 5:46 PM, Scott Palmer wrote: > > JavaFX already runs on some Arm-based devices like the Raspberry Pi, so > I expect an Arm-based port for new Macs won’t be that big of a job > (relatively speaking) > > > > Hopefully by that time there will be a Metal-base rendering pipeline as > well. The Metal-based pipeline for Swing seems to be coming along nicely. > > > > I don’t know if Oracle has access to one of the early developer boxes > that runs macOS on arm or not. If they don’t, then a Java/Java FX port may > not be available on day 1. That being said, perhaps Rosetta 2 will run the > JDK/JRE until a proper port is available. I don’t know if the JIT compiler > will work with Rosetta though. If it doesn’t then that certainly makes a > proper port more urgent. > > > > > > Scott > > > >> On Jul 1, 2020, at 2:13 PM, Danny Gonzalez < > danny.gonza...@screamingfrog.co.uk> wrote: > >> > >> Hi All, > >> > >> Not sure if this is the correct place to direct this conversation but > here goes. > >> > >> With the imminent arrival of Arm Macs in late 2020 running MacOS Big > Sur, what are the plans to ensure that OpenJFX and Java will run on this > platform? > >> > >> Are there plans to get the Developer Transition Kit to test on real > hardware prior to the release of consumer hardware? > >> Are there testers testing on MacOs beta? > >> > >> Will OpenJFX and Java be able to run natively in this new Arm Mac > environment? > >> Will OpenJFX and Java be able to run in the Rosetta emulator? > >> > >> We have many MacOS customers, many of whom will be early adopters and > upgrade to the new Arm Macs so this could be a big issue for us. > >> > >> Thanks > >> > >> Danny > >> > >> > >
Re: MacOS Big Sur and OpenJFX on Arm Macs
At WWDC, Apple indicated that they have run the JDK on prototype Arm HW using Rosetta2. Once we get our hands on some HW we'll test JavaFX as well. I expect that it will run reasonably well. I think that an ARM port for JavaFX won't be too difficult, although I doubt the existence of Linux ARM for embedded platforms will help much with the Mac. Most of the work will be upgrading to Xcode 12 and producing universal (fat) binaries again, which we did back in the very early days for ppc and intel. As for a Metal port, we do plan to get started on that soon (we've done some very preliminary looking). -- Kevin On 7/1/2020 5:46 PM, Scott Palmer wrote: JavaFX already runs on some Arm-based devices like the Raspberry Pi, so I expect an Arm-based port for new Macs won’t be that big of a job (relatively speaking) Hopefully by that time there will be a Metal-base rendering pipeline as well. The Metal-based pipeline for Swing seems to be coming along nicely. I don’t know if Oracle has access to one of the early developer boxes that runs macOS on arm or not. If they don’t, then a Java/Java FX port may not be available on day 1. That being said, perhaps Rosetta 2 will run the JDK/JRE until a proper port is available. I don’t know if the JIT compiler will work with Rosetta though. If it doesn’t then that certainly makes a proper port more urgent. Scott On Jul 1, 2020, at 2:13 PM, Danny Gonzalez wrote: Hi All, Not sure if this is the correct place to direct this conversation but here goes. With the imminent arrival of Arm Macs in late 2020 running MacOS Big Sur, what are the plans to ensure that OpenJFX and Java will run on this platform? Are there plans to get the Developer Transition Kit to test on real hardware prior to the release of consumer hardware? Are there testers testing on MacOs beta? Will OpenJFX and Java be able to run natively in this new Arm Mac environment? Will OpenJFX and Java be able to run in the Rosetta emulator? We have many MacOS customers, many of whom will be early adopters and upgrade to the new Arm Macs so this could be a big issue for us. Thanks Danny
Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2]
On Wed, 1 Jul 2020 05:43:29 GMT, John Neffenger
wrote:
>>> It will also need to be tested using the SW pipeline on all platforms.
>>
>> Thanks for the reminder. I managed to build JavaFX on Windows and macOS
>> today, so I'll test this pull request on those
>> platforms in addition to Linux desktop and embedded.
>
> I tested this pull request on all of the following platforms:
>
> * JavaFX desktop platforms (*amd64* architecture)
> * Windows SDK on Windows 10 Pro Version 2004
> * Mac OS X SDK on macOS 10.15.5 (Catalina)
> * Linux SDK on Ubuntu 16.04.6 LTS (Xenial Xerus)
>
> * JavaFX embedded platforms (*armhf* architecture)
> * armv6hf SDK (Monocle EPD) on Ubuntu 14.04.6 LTS (Trusty Tahr)
> * armv6hf SDK (Monocle VNC) on Ubuntu 20.04 LTS (Focal Fossa)
>
> This is a tricky timing problem on most platforms, so I used rather intrusive
> techniques to catch the error and verify
> it was fixed. The bug is easily visible only on the Monocle VNC platform.
> ### Desktop
>
> I tested the desktop platforms as follows:
>
> 1. I added `assert` statements and calls to `Thread.sleep` as shown by [this
> commit](https://github.com/jgneff/javafx-graphics/commit/ffc639e4) to catch
> the error. It looks like a lot of changes,
> but they simply call `sleep` to change the timing of the threads so that the
> JavaFX Application Thread is unable to
> keep up with the QuantumRenderer. The `assert` statements catch the error
> when the rendering thread starts looking for
> an unused buffer.
> All platforms printed many `InvalidMarkException` errors as the buffer
> position was modified while in use on the JavaFX
> application thread. The Linux and Windows platforms printed, "Exception
> in thread 'JavaFX Application Thread'
> java.nio.InvalidMarkException," while the macOS platform printed,
> "Exception in thread 'AppKit Thread'
> java.nio.InvalidMarkException."
>
> 2. I applied the fix to call `getBuffer` instead of `getPixels` in
> `QueuedPixelSource`.
>
> 3. After the fix, no errors were detected by the assertions on any of the
> platforms.
>
> ### Embedded
>
> I tested the embedded platforms as follows:
>
> 1. I added only `assert` statements to the `HeadlessScreen` and `EPDScreen`
> classes, as shown below. Both platforms
> printed many `InvalidMarkException` errors as the buffer position was
> modified while in use on the JavaFX application
> thread. 2. I applied the fix to call `getBuffer` instead of `getPixels` in
> `QueuedPixelSource`.
>
> 3. After the fix, no errors were detected by the assertions on either
> platform.
>
> `HeadlessScreen` and `EPDScreen`
>
> @Override
> public synchronized void uploadPixels(Buffer b, int x, int y,
> int width, int height, float alpha) {
> +assert b.mark() == b;
> pixels.composePixels(b, x, y, width, height, alpha);
> +assert b.reset() == b;
> }
>
> For the Monocle VNC platform, you can also simply connect and watch the bug
> corrupt the frames sent to the VNC client,
> as shown in my prior comment on this pull request.
> ### Other results
>
> I found some unexpected results, listed below.
>
> * JavaFX on Linux does not limit its frame rate to 60 Hz when using the
> hardware pipeline, reaching over 350 frames per
> second.
>
> * JavaFX on macOS ignores the system property `-Djavafx.animation.pulse=8`
> and runs at 60 Hz, even though it prints the
> message "Setting PULSE_DURATION to 8 hz."
>
> * JavaFX on macOS prints the error shown below when `Platform.exit` is called
> to end the application. The error also
> occurs on JavaFX 14.0.1 and 15-ea+6. The error does not occur when the
> window is closed manually using the mouse.
>
> Java has been detached already, but someone is still trying to use it at
> -[GlassViewDelegate dealloc]:
> /Users/john/src/jfx/modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m:204
> 0 libglass.dylib 0x00010eb6c05d -[GlassViewDelegate dealloc] + 221
> 1 libglass.dylib 0x00010eb71af6 -[GlassView3D dealloc] + 246
> 2 libobjc.A.dylib 0x7fff66937054
> _ZN19AutoreleasePoolPage12releaseUntilEPP11objc_object + 134
> 3 libobjc.A.dylib 0x7fff6691bdba objc_autoreleasePoolPop + 175
> 4 CoreFoundation 0x7fff2dad23c5
> __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
> 5 CoreFoundation 0x7fff2dad22f7 __CFRunLoopDoObservers + 457
> 6 CoreFoundation 0x7fff2dad1895 __CFRunLoopRun + 874
> 7 CoreFoundation 0x7fff2dad0ece CFRunLoopRunSpecific + 462
> 8 libjli.dylib 0x00010be945c1 CreateExecutionEnvironment + 399
> 9 libjli.dylib 0x00010be90752 JLI_Launch + 1354
> 10 java 0x00010be83ca1 main + 375
> 11 libdyld.dylib0x7fff67acdcc9 start + 1
> 12 ??? 0x000b 0x0 + 11
>
> ### Test scripts
>
> Below are the scripts I used to run the tests. The scripts include the system
>
