Issues porting to Monocle EPD platform

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

Re: More community participation in JavaFX

On 02/01/2018 03:26 PM, Kevin Rushforth wrote: We are specifically looking to discuss ideas around the following areas: * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) Thank you for asking. In my case, the

Re: future content of OpenJFX

On 02/05/2018 08:14 PM, John-Val Rose wrote: ... is it possible that there are lots and lots of “observers” or “lurkers” out there just waiting until all the hard work of setting-up the physical and formal infrastructure to enable community contribution has been finalised before they’ll put

Re: The "javafx might not be present" problem

On 02/09/2018 05:29 AM, Mark Raynsford wrote: I've been exploring the possibility of migrating to JavaFX on and off, but the biggest showstopper for me is that JavaFX may not actually be present in any given user's installation. If someone installs the jre9-openjdk package on Arch Linux, for

Re: Monocle Headless BufferOverflowException (Issue + Fix)

On 02/23/2018 02:29 PM, Michael Ennen wrote: Here is the issue: https://gitlab.com/openjfxepd/jfxpatch/issues/1 Thanks to John Neffenger for taking the time to put this together! I wanted to make this work was known to Kevin and the team. I'm so glad you found it! I posted a link

Re: Monocle Headless BufferOverflowException (Issue + Fix)

On 02/23/2018 03:12 PM, Michael Ennen wrote: Good point about the OCA, I have sent an email just now to John Neffenger. Hopefully he is still interested in this topic :). I filed the bug report yesterday, along with two others. It was assigned the internal review ID 9053385 and has

Setting the FreeType LCD filter

I think I found the cause of the text rendering problem I have always seen in JavaFX applications on Linux: Reduce color fringes in FreeType subpixel rendering https://github.com/javafxports/openjdk-jfx/issues/229 I'm finally seeing the fonts as they were intended! I used the Oracle bug

Bitwise puzzle in com.sun.glass.ui.monocle.Framebuffer

I am completely puzzled by the bitwise operations in the Framebuffer class (package com.sun.glass.ui.monocle). I'm overriding its methods to support a "Y8" 8-bit grayscale frame buffer, yet I have no idea why it's doing what it's doing. Can anyone shed light on its complexity? The Framebuffer

OpenJFX FreeType Tests

I ran tests of the latest OpenJFX, built with and without the fix to set the LCD filter, against 5 versions of the FreeType library, built with and without the ClearType subpixel rendering techniques enabled, and posted the results of all 20 tests on the page below. OpenJFX FreeType Tests

Review request for 8188810, "Fonts are blurry on Ubuntu 16.04 and Debian 9"

Please review the GitHub pull request: JDK-8188810: Fonts are blurry on Ubuntu 16.04 and Debian 9 https://github.com/javafxports/openjdk-jfx/pull/235 which fixes: Fonts are blurry on Ubuntu 16.04 and Debian 9 https://bugs.openjdk.java.net/browse/JDK-8188810 Thank you, John

HTTPS download location or checksum available?

Is it possible to change the following page either to download the files over HTTPS or provide their checksums on an HTTPS page (as Oracle does for the JDK)? JavaFX - Gluon https://gluonhq.com/products/javafx/ The page redirects to an insecure HTTP connection when downloading the Linux

Re: JavaFX Content Rendering & Resizing and Font Bugs In Linux

On 1/15/19 6:36 PM, Ty Young wrote: In otherwords, similar to double and triple buffering. Of course, just like with double/triple buffering this can cause side affects. Yes, JavaFX does all that. I was trying to help out by informing you of at least one concurrency bug between the

Re: Text rendering on Mojave (macOS)

On 11/28/18 7:47 AM, Kirill Grouchnikov wrote: No matter if that new platform setting is off or on, all the texts look halo'd - zoom in on https://www.pushing-pixels.org/wp-content/uploads/2018/11/javafx-mojave.png and see all those pink / light blue pixels around glyphs. The text in that

Re: Bitwise puzzle in com.sun.glass.ui.monocle.Framebuffer

On 11/17/18 5:40 AM, Nir Lisker wrote: I agree with your math. I guess you could submit an enhancement request to have it evaluated. Thank you for looking into it, Nir. I plan to include the simplified RGB565 conversion along with my Y8 grayscale support, as it's all done in the same two

RFE: Add support for e-paper displays

I submitted the following GitHub issue requesting an enhancement that I would like to see in JavaFX. I used the JDK Enhancement Proposal template as a guide in writing the request. I would greatly appreciate any comments you can provide. I also have an implementation ready for a pull request.

Re: New unit tests 12 times slower under Gradle (solved)

I figured it out. It's the old version of JUnit that we're using. Although we're building OpenJFX with Gradle 4.8, which bundles JUnit 4.12, our "build.gradle" file specifies the older JUnit 4.8.2 (which is downloaded, along with Hamcrest 1.1, into the Gradle cache under "~/.gradle/caches").

New unit tests 12 times slower under Gradle

I have four new JavaFX Graphics unit tests that copy bytes from a byte buffer to another byte buffer or write them to a byte channel [1]. They take less than 3 seconds to run under Ant, whether within NetBeans or from the command line. Those same tests take 34 seconds to run in the JavaFX

RFR: 8217605: Add support for e-paper displays

Please review the changes for "Add support for e-paper displays." https://bugs.openjdk.java.net/browse/JDK-8217605 https://github.com/javafxports/openjdk-jfx/pull/369 The "18 changed files with 3,622 additions and 2 deletions" reported by GitHub breaks down into the following actual lines

Re: JMODs and Arm support

On 4/30/19 8:41 AM, Scott Palmer wrote: I noticed that there is a download on openjfx.io for an 11.0.2 Arm SDK, but no JMOD download for Arm. Nor is there any 64-bit Arm download, making it a bit of an outlier since there are no 32-bit binaries for the other platforms.

Re: RFR: 8087980: Add property to disable Monocle cursor

On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgr...@users.noreply.github.com> wrote: > Often on embedded systems a cursor is not a valid input modality. On some of > these systems, when the javafx toolkit initialises the native hardware > cursor, it produces artefacts which can be

Re: RFR: 8087980: Add property to disable Monocle cursor

On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green wrote: > On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger > wrote: > >> On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green >> <12861109+dellgr...@users.noreply.github.com> wrote: >> >>> Often on embedded syst

Re: RFR: 8087980: Add property to disable Monocle cursor

On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgr...@users.noreply.github.com> wrote: > Often on embedded systems a cursor is not a valid input modality. On some of > these systems, when the javafx toolkit initialises the native hardware > cursor, it produces artefacts which can be

Re: RFR: 8087980: Add property to disable Monocle cursor

On Sat, 16 Nov 2019 06:09:35 GMT, Dell Green wrote: > On Sat, 16 Nov 2019 00:32:31 GMT, John Neffenger > wrote: > >> On Wed, 13 Nov 2019 22:04:36 GMT, Dell Green >> wrote: >> >>> On Wed, 13 Nov 2019 21:34:06 GMT, John Neffenger >>> wrote: &g

Re: RFR: 8227425: Add support for e-paper displays on i.MX6 devices

On Thu, 5 Dec 2019 12:06:18 GMT, John Neffenger wrote: > This pull request adds support for e-paper displays with the i.MX 6 Series of > Applications Processors and implements [Issue > #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete > *javafxports

RFR: 8227425: Add support for e-paper displays on i.MX6 devices

This pull request adds support for e-paper displays with the i.MX 6 Series of Applications Processors and implements [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the obsolete *javafxports/openjdk-jfx* repository. Some of the changes were made to support the new device

Re: [Rev 01] RFR: 8087980: Add property to disable Monocle cursor

On Mon, 18 Nov 2019 14:04:25 GMT, Dell Green wrote: > The pull request has been updated with additional changes. > > > > Added commits: > - 1f6e282d: changed from system propert debug logging to javafx platform > logger > > Changes: > - all:

Re: RFR: 8231870: Updated armv6hf crosslibs script with new domains

On 10/8/19 1:41 AM, Johan Vos wrote: Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. It would be nice to use the cross-compile tools that come with my system (Ubuntu 16.04) as I do when

GitHub glitch - merging master into an old pull request

I was surprised to see GitHub listing in my pull request all of the changes I merged from the upstream master branch, as I commented here: Did I merge the upstream master branch correctly? https://github.com/openjdk/jfx/pull/60#issuecomment-614885532 Unfortunately, GitHub also pulled into my

Re: [Rev 02] RFR: 8227425: Add support for e-paper displays on i.MX6 devices

buffer. I plan to investigate the cause of the performance difference. > > * In general, the faster processor and memory bus of the newer models does > not fully compensate for the threefold > increase in the number of pixels in their displays. The table below shows > the ani

Re: [Rev 01] RFR: 8227425: Add support for e-paper displays on i.MX6 devices

buffer. I plan to investigate the cause of the performance difference. > > * In general, the faster processor and memory bus of the newer models does > not fully compensate for the threefold > increase in the number of pixels in their displays. The table below shows > the ani

Re: RFR: 8227425: Add support for e-paper displays on i.MX6 devices

On Thu, 5 Dec 2019 00:14:34 GMT, John Neffenger wrote: >> This pull request adds support for e-paper displays with the i.MX 6 Series >> of Applications Processors and implements >> [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the >> obsolete

Re: RFR: 8227425: Add support for e-paper displays on i.MX6 devices

On Fri, 17 Apr 2020 15:14:19 GMT, Kevin Rushforth wrote: > I just checked and there is nothing wrong with your merge. But somehow it > managed to confuse GitHub. Thanks, Kevin. A simple `git rebase master` and `git push --force` did the trick! I hope it's okay for me to add some advocacy to

Re: [Rev 01] RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi

On Mon, 27 Apr 2020 11:09:51 GMT, Alexander Scherbatiy wrote: >> See the detailed issue description on: >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html >> >> The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes >>

Re: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi

On Thu, 23 Apr 2020 23:58:19 GMT, John Neffenger wrote: >> I couldn't understand why I wasn't hitting this error on the embedded >> Monocle EPD platform. Stepping through the code >> with the debugger, I found that JavaFX is looking for the >> *javafx.platform.prope

Re: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi

On Thu, 23 Apr 2020 22:43:30 GMT, John Neffenger wrote: >> See the detailed issue description on: >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html >> >> The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes >> [MonocleAppli

Re: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi

On Fri, 24 Apr 2020 08:20:02 GMT, Alexander Scherbatiy wrote: > To debug the JavaFX on Raspberry Pi I built armv6hf-sdk and just copied the > file _javafx.platform.properties_ from the > full jdk version with JavaFX to jdk-14.0.1/lib directory of jdk without > JavaFX which I used to run my

Re: [Integrated] RFR: 8227425: Add support for e-paper displays on i.MX6 devices

On Thu, 5 Dec 2019 00:06:21 GMT, John Neffenger wrote: > This pull request adds support for e-paper displays with the i.MX 6 Series of > Applications Processors and implements > [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the > obsolete *javafxports

Re: RFR: 8243255: Font size is large in JavaFX app with enabled Monocle on Raspberry Pi

On Tue, 21 Apr 2020 16:47:44 GMT, Alexander Scherbatiy wrote: > See the detailed issue description on: > http://mail.openjdk.java.net/pipermail/openjfx-dev/2020-April/025975.html > > The fix 8236448 https://github.com/openjdk/jfx/pull/75 changes >

Re: [Rev 02] RFR: 8227425: Add support for e-paper displays on i.MX6 devices

On Tue, 28 Apr 2020 23:33:31 GMT, Kevin Rushforth wrote: >> John Neffenger has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. > > Lo

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2]

On Mon, 21 Sep 2020 18:34:29 GMT, John Neffenger wrote: >> Based on my notes below, I believe this change is safe for any Linux input >> device driver because the driver shouldn't >> receive the intermediate *open* and *close* calls at all. >> Nonetheless, it would

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

On Mon, 29 Jun 2020 18:49:33 GMT, John Neffenger wrote: > Nonetheless, it would be reassuring if someone could try [this > change](https://github.com/openjdk/jfx/pull/258/files) > just once on a mainstream device, such as the Raspberry Pi with a touchscreen > LCD panel. I

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2]

> Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). John Neffenger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additio

Re: Font rendering issue on macOS - cut off characters

On 5/25/20 11:47 AM, Philip Race wrote: Mmm .. it can't be the same bug even if the effect is similar. We don't use freetype on macOS, that's for Linux. Right. I meant the same visible bug (severe color fringes). Can you check your display's settings ? I'm using a Dell UltraSharp U2715H

Re: Font rendering issue on macOS - cut off characters

On 5/24/20 4:27 PM, Rob Nikander wrote: You can see the shaved “o” characters there, but I’m just talking about the colors now. Is that normal? No. I think it's a bug. See my comment dated May 20, 2020, on the old GitHub issue that reported the same bug on Linux in 2018 and was fixed for

Re: Font rendering issue on macOS - cut off characters

On 5/25/20 1:34 PM, Philip Race wrote: Hmm. Some of the glyphs are grey scale. I see that, too. Notice the first "A" in "Animation" is anti-aliased in grayscale, yet the other letters use subpixel rendering and result in severe color fringes:

Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread

On Sat, 27 Jun 2020 15:37:52 GMT, Kevin Rushforth 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

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

[jfx15] Integrated: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread

On Fri, 26 Jun 2020 03:47:55 GMT, John Neffenger wrote: > Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). This pull request has now been integrated. Changeset: d67c47fd Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/

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

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

On Wed, 1 Jul 2020 12:10:23 GMT, Johan Vos wrote: > I don't have access to a Pi right now, so I can't test this (I'll be able to > test in about 10 days from now though) Thank you, Johan. If you have the time, that would be great. Otherwise, merging this for early-access builds of JavaFX 16

Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2]

> Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Remove assert statements - Changes: - all: https://git.openjdk.java.net/jfx/pull/255/fi

Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread [v2]

On Tue, 30 Jun 2020 06:05:08 GMT, John Neffenger wrote: >> At first glance the fix looks fine (aside from the `assert` statements that >> need to be removed). It will also need to >> be tested using the SW pipeline on all platforms. > >> It will also need to be t

RFR: 8248381: Create a daemon thread for MonocleTimer

Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). - Commit messages: - 8248381: Create a daemon thread for MonocleTimer Changes: https://git.openjdk.java.net/jfx/pull/256/files Webrev: https://webrevs.openjdk.java.net/jfx/256/webrev.00 Issue:

RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread

Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). - Commit messages: - 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread Changes: https://git.openjdk.java.net/jfx/pull/255/files Webrev:

Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread

On Fri, 26 Jun 2020 03:47:55 GMT, John Neffenger wrote: > Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). The method `QueuedPixelSource.usesSameBuffer` calls `Pixels.getPixels` on the QuantumRenderer thread while trying to find a buffer that's not in use, yet in do

RFR: 8201570: Get two bytes for the Linux input event type, not four

Fixes [JDK-8201570](https://bugs.openjdk.java.net/browse/JDK-8201570). - Commit messages: - 8201570: Get two bytes for the Linux input event type, not four Changes: https://git.openjdk.java.net/jfx/pull/257/files Webrev: https://webrevs.openjdk.java.net/jfx/257/webrev.00 Issue:

RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). - Commit messages: - 8201568: zForce touchscreen input device fails when closed and immediately reopened Changes: https://git.openjdk.java.net/jfx/pull/258/files Webrev:

Re: RFR: 8248381: Create a daemon thread for MonocleTimer

On Fri, 26 Jun 2020 23:23:43 GMT, Kevin Rushforth wrote: >> Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). > > It looks simple enough for a single reviewer. Since it is in Monocle, > @johanvos will probably want to review it. Note that this is a regression error that is

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

On Sat, 27 Jun 2020 00:21:06 GMT, John Neffenger wrote: > Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). I thought I could avoid fixing this bug simply by waiting a few years, but the old devices from 2012 and 2013 where the problem occurs are still supported and st

Re: RFR: 8248381: Create a daemon thread for MonocleTimer

On Sat, 27 Jun 2020 14:34:09 GMT, Johan Vos wrote: >> Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). > > modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MonocleTimer.java > line 38: > >> 37: private static final String THREAD_NAME = "Monocle Timer";

Re: RFR: 8248381: Create a daemon thread for MonocleTimer

The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Sat, 27 Jun 2020 16:14:36 GMT, Kevin Rushforth

Re: RFR: 8248381: Create a daemon thread for MonocleTimer

On Sat, 27 Jun 2020 19:37:01 GMT, Kevin Rushforth wrote: > OK, that seems fine then. I'll take a closer look and then finish my review. Actually, I think you may be right, though. Sorry for replying before looking into it. I now think the `ScheduledThreadPoolExecutor` should be shut down, but

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Mon, 29 Jun 2020 11:26:50 GMT, Johan Vos wrote:

Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread

The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Sat, 27 Jun 2020 15:36:01 GMT, Kevin Rushforth

Re: RFR: 8248381: Create a daemon thread for MonocleTimer [v2]

> Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). John Neffenger has updated the pull request incrementally with one additional commit since the last revision: Remove POOL_SIZE constant - Changes: - all: https://git.openjdk.java.net/jfx/pull/256/fi

Re: RFR: 8248381: Create a daemon thread for MonocleTimer

The message from this sender included one or more files which could not be scanned for virus detection; do not open these files unless you are certain of the sender's intent. -- On Sat, 27 Jun 2020 19:40:53 GMT, John Neffenger

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened

On Mon, 27 Jul 2020 14:26:44 GMT, Tor (torbuntu) wrote: > Is there somewhere I can find an embedded aarch64 version? If I had a PinePhone, I would try to get the 32-bit *armhf* build of JavaFX working. That's the one you build with `gradle -PCOMPILE_TARGETS=armv6hf sdk jmod`. You may need to

[jfx15] Integrated: 8248381: Create a daemon thread for MonocleTimer

On Fri, 26 Jun 2020 03:50:02 GMT, John Neffenger wrote: > Fixes [JDK-8248381](https://bugs.openjdk.java.net/browse/JDK-8248381). This pull request has now been integrated. Changeset: 5f60ea5d Author: John Neffenger Committer: Kevin Rushforth URL: https://git.openjdk.java.net/

Re: RFR: 8256012: Fix build of Monocle for Linux

On Tue, 24 Nov 2020 21:18:03 GMT, Johan Vos wrote: > I don't see any harm in this PR, but I wonder which toolchains are still not > having `RTLD_NEXT` without specifying GNU_SOURCE. Thanks, Johan. I've been following the instructions in the [OpenJFX Wiki][1]. I use the GCC cross-compiler

Integrated: 8201568: zForce touchscreen input device fails when closed and immediately reopened

On Sat, 27 Jun 2020 00:21:06 GMT, John Neffenger wrote: > Fixes [JDK-8201568](https://bugs.openjdk.java.net/browse/JDK-8201568). This pull request has now been integrated. Changeset: ebb59e9f Author: John Neffenger Committer: Johan Vos URL: https://git.openjdk.java.net/jfx/com

Re: RFR: 8201568: zForce touchscreen input device fails when closed and immediately reopened [v2]

On Tue, 29 Sep 2020 19:47:54 GMT, John Neffenger wrote: >> I don't have access to a Pi right now, so I can't test this (I'll be able to >> test in about 10 days from now though) > > @johanvos, would you mind approving this pull request again? It looks as if > the *rea

Integrated: 8256012: Fix build of Monocle for Linux

On Sat, 7 Nov 2020 23:13:48 GMT, John Neffenger wrote: > This pull request fixes the error when building embedded JavaFX for Linux. > > The error occurs because `MonocleGLFactory.c` does not define the macro > `__USE_GNU` before including the header file `dlfcn.h`. T

Re: RFR: 8256012: Fix build of Monocle for Linux [v2]

mation in the following two > Stack Overflow conversations: > > * ['RTLD_NEXT' undeclared][1] > * [_GNU_SOURCE and __USE_GNU][2] > > [1]: https://stackoverflow.com/q/1777397 > [2]: https://stackoverflow.com/q/7296963 John Neffenger has updated the pull request with a new tar

RFR: 8256012: Fix build of Monocle for Linux

This pull request fixes the error when building embedded JavaFX for Linux. The error occurs because `MonocleGLFactory.c` does not define the macro `__USE_GNU` before including the header file `dlfcn.h`. The two lines in the conditional group "`#ifndef ANDROID`" below have no effect because the

Re: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v4]

On Wed, 4 Nov 2020 16:14:06 GMT, Johan Vos wrote: >> Allow the EGL functionality in monocle to leverage EGL-based systems. The >> low-level specific details about how the EGL calls should be constructed are >> left out, and a native interface (egl_ext.h) is created that can be mapped >> to

Re: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6]

On Thu, 5 Nov 2020 20:33:05 GMT, Kevin Rushforth wrote: >> Johan Vos has updated the pull request incrementally with one additional >> commit since the last revision: >> >> change invocation of getEGLDisplayHandle into getEglDisplayHandle >> Conditionally add dlfcn > > Marked as reviewed

Re: RFR: 8254569: Remove hard dependency on Dispman in Monocle fb rendering [v6]

On Thu, 5 Nov 2020 18:16:58 GMT, Jose Pereda wrote: >> Johan Vos has updated the pull request incrementally with one additional >> commit since the last revision: >> >> change invocation of getEGLDisplayHandle into getEglDisplayHandle >> Conditionally add dlfcn > > Marked as reviewed by

Re: RFR: 8256012: Fix build of Monocle for Linux [v3]

mation in the following two > Stack Overflow conversations: > > * ['RTLD_NEXT' undeclared][1] > * [_GNU_SOURCE and __USE_GNU][2] > > [1]: https://stackoverflow.com/q/1777397 > [2]: https://stackoverflow.com/q/7296963 John Neffenger has updated the pull request incrementally

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v3]

On Fri, 16 Apr 2021 19:05:34 GMT, Kevin Rushforth wrote: >> John Neffenger has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Include WebKit shared library for Windows >> >> Enable reproducibl

Withdrawn: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH

On Tue, 9 Mar 2021 22:20:10 GMT, John Neffenger wrote: > This is a continuation of the [pull request][1] started by @bmwiedemann in > January 2020. After this change is integrated, I can follow up immediately > with additional pull requests that get us much closer to provid

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5]

ies the Gradle and Groovy build files to fix the first > three sources of non-determinism. A later pull request can modify the Java > files to fix the fourth. > > [1]: https://reproducible-builds.org/docs/source-date-epoch/ > [2]: https://salsa.debian.org/reproducible-builds/strip-nond

Re: RFR: 8238650: Allow to override buildDate with SOURCE_DATE_EPOCH [v2]

On Fri, 30 Apr 2021 00:10:30 GMT, John Neffenger wrote: >> This is a continuation of the [pull request][1] started by @bmwiedemann in >> January 2020. After this change is integrated, I can follow up immediately >> with additional pull requests that get us much closer

Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v5]

On Mon, 14 Jun 2021 20:53:50 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a

Command Line Tools for Xcode 12.4 → 12.5

Just a heads-up about using the latest Xcode 12.5 ... I use the Command Line Tools for Xcode 12.4 (at 431 MB) to build JavaFX on macOS as an alternative to the full Xcode package (at 11.86 GB). Thank you, Arunprasad Rajkumar! [1] Then Apple Software Update installed the latest Command Line

Re: Command Line Tools for Xcode 12.4 → 12.5

On 6/16/21 9:56 AM, Philip Race wrote: 1) Don't let macOS upgrade my xcode tools automatically Lesson learned! But then there's that annoying red badge on your System Preferences forever. :-) Actually, it was worse, and went more like this (just in case any else gets led off-course by the

Re: Command Line Tools for Xcode 12.4 → 12.5

On 6/16/21 10:21 AM, John Neffenger wrote: 4. Finally look up what the GitHub Actions are using (12.4). Oops, make that "Finally look up what the project uses (12.4)." For the record, our GitHub Actions use Xcode_11.3.1. [1] John [1]: https://github.com/openjdk/jfx/blob/mast

Re: RFR: 8268915: WebKit build fails with Xcode 12.5

On Thu, 17 Jun 2021 14:52:53 GMT, Kevin Rushforth wrote: > The JavaFX WebKit build fails with Xcode 12.5 + MacOS 11.3 SDK. This is > related to the added C++20 support where some of the system include files now > do `#include `. Because the macOS file system is case insensitive, > it matches

Re: Moving src.zip out of the lib directory of the JavaFX SDK

On 6/23/21 6:50 AM, Kevin Rushforth wrote: Are there any IDE users who are currently having problems as a result of this? If not, I'll retarget this for a future release. I haven't seen problems with the current location of the 'src.zip' file in NetBeans. For Apache Ant projects, though, I do

Re: RFR: JDK-8266396: Allow VSCMD_DEBUG to work as intended [v2]

On Mon, 10 May 2021 05:54:51 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio >> paths and environment variables. The batch files are a black box: any >> messages they print are discarded. If anything goes wro

Re: RFR: JDK-8266396: Allow VSCMD_DEBUG to work as intended [v3]

On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio >> paths and environment variables. The batch files are a black box: any >> messages they print are discarded. If anything goes wro

Re: RFR: JDK-8266396: Allow VSCMD_DEBUG to work as intended [v3]

gt; > ︙ > > 'powershell.exe' is not recognized as an internal or external command, > operable program or batch file. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What

Re: RFR: JDK-8266396: Allow VSCMD_DEBUG to work as intended [v3]

On Tue, 11 May 2021 01:17:32 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio >> paths and environment variables. The batch files are a black box: any >> messages they print are discarded. If anything goes wro

Re: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3

On Wed, 3 Mar 2021 22:07:34 GMT, Alessadro Parisi wrote: >> This is a toolchain upgrade on Windows from the current Visual Studio 2017 >> (version 15.9.16) to Visual Studio 2019 (version 16.5.3). This will match a >> recent upgrade done for JDK 15 -- see >>

Re: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error [v2]

On Mon, 10 May 2021 05:54:51 GMT, John Neffenger wrote: >> The Windows build calls a series of batch files to get the Visual Studio >> paths and environment variables. The batch files are a black box: any >> messages they print are discarded. If anything goes wro

Re: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error [v2]

gt; > ︙ > > 'powershell.exe' is not recognized as an internal or external command, > operable program or batch file. > > FAILURE: Build failed with an exception. > > * Where: > Script 'C:\cygwin64\home\john\src\jfx\buildSrc\win.gradle' line: 108 > > * What

Re: RFR: 8242508: Upgrade to Visual Studio 2019 version 16.5.3

On Wed, 6 May 2020 20:37:10 GMT, Kevin Rushforth wrote: > This is a toolchain upgrade on Windows from the current Visual Studio 2017 > (version 15.9.16) to Visual Studio 2019 (version 16.5.3). This will match a > recent upgrade done for JDK 15 -- see >

Re: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error

On Fri, 7 May 2021 13:42:49 GMT, Kevin Rushforth wrote: > It would be more convenient to ask the developer set `VSCMD_DEBUG` via an env > variable, rather than asking them to edit `win.gradle`. Thanks, Kevin. That is the most direct approach. I didn't document it that way for the following

Re: Build error with gradle (command line)

On 5/11/21 5:24 AM, Jeanette Winzenburg wrote: deleting the caches did work, at last ;) That's also what I had to do after similar errors. I thought there might be some bumps in the road when I proposed adding the Gradle dependency verification, but I hope we can retain enough of it to make

Re: Build error with gradle (command line)

On 5/11/21 10:27 AM, Johan Vos wrote: I'm still +1 to keep Gradle for OpenJFX. The OpenJFX build is shockingly complicated. It's not just a Gradle build. It's a Gradle, Groovy Custom Task, Apache Maven, Apache Ant, GNU Make, CMake, Ninja, ANTLR, JUnit, GNU GCC, XCode, Visual Studio,

Re: RFR: JDK-8266396: Add VSCMD_DEBUG for solving WINSDK_DIR build error

On Thu, 6 May 2021 20:39:11 GMT, John Neffenger wrote: > The Windows build calls a series of batch files to get the Visual Studio > paths and environment variables. The batch files are a black box: any > messages they print are discarded. If anything goes wrong, the only signs are

  1   2   >