Re: JavaFX-Bugs on GraalVM 19.3 (Java 11)
I am also observing issues related to text color. All of my labels show up in blue instead of the color defined globally in my css file. > On 20 Nov 2019, at 22:20, Michael Paus wrote: > > Hi, > > I would just like to know where JavaFX problems or bugs should be reported > which are strictly related to running on the just released GraalVM 19.3 with > Java 11 support. Should they go into the regular JBS or should they be > reported > elsewhere? > > For example: I have observed that a large JavaFX application seems to work > correctly at first but then suddenly all text on all controls turns white and > white on white or light grey is not really readable anymore. I've never > observed > such a behaviour on any other VM before. There is also no error message or > warning associated with this. It just happens. > > There even seem to be more issues when you try to use native-image. > > --Michael >
JavaFX-Bugs on GraalVM 19.3 (Java 11)
Hi, I would just like to know where JavaFX problems or bugs should be reported which are strictly related to running on the just released GraalVM 19.3 with Java 11 support. Should they go into the regular JBS or should they be reported elsewhere? For example: I have observed that a large JavaFX application seems to work correctly at first but then suddenly all text on all controls turns white and white on white or light grey is not really readable anymore. I've never observed such a behaviour on any other VM before. There is also no error message or warning associated with this. It just happens. There even seem to be more issues when you try to use native-image. --Michael
Typo in native-glass/win/OleUtils.h checkJavaException
I discovered this by accident while trying to figure out where a certain
console message was coming from while debugging.
I saw this printed to the console when testing my (broken) code:
Java Messsge:com/openalpr/jni/AlprException
Note the typo in "Messsge" (the class name that follows is specific to what
I was testing).
I couldn't find the string "Java Messsge" in any of my code or the library
I was trying out (OpenALPR). Eventually I found it was in glass.dll and
traced it to the checkJavaException function in OleUtils.h, line 230.
On another note, I see that function is declared as "inline", though I
suspect the body of the "else" really doesn't need to be inlined and the
extra size it adds to the method could make it less likely to actually get
inlined. It seems the part that you want inlined is the if
(!env-ExceptionCheck()) { return S_OK; }. Wouldn't the rest run very rarely
and not benefit from being inlined? If that code does get inlined it would
bloat the code unnecessarily. The premature optimizer in me (it's an evil
I have trouble controlling) thinks this just makes stuff less
cache-friendly. I would put it in another not-inlined method. Also note
that using "else" is redundant.
Scott
Re: RFR: 8233747: JVM crash in com.sun.webkit.dom.DocumentImpl.createAttribute
On Wed, 20 Nov 2019 07:05:40 GMT, Arun Joseph wrote: > Issue: Native part of WebView throws a DOMException and then, continues > executing the rest of the function assuming that value is present. This > causes the JVM to crash when retrieving the value. > > Fix: Return from the function if exception was raised (code is similar to > exception handling in > [WebKitLegacy/java/DOM/JavaTreeWalker.cpp](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM/JavaTreeWalker.cpp)) > > This fix also needs to be applied to all function calls in > [WebKitLegacy/java/DOM](https://github.com/openjdk/jfx/tree/master/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/DOM) > functions which raises DOMError similar to createAttributeImpl(). > > > > Commits: > - acc52780: 8233747: JVM crash in > com.sun.webkit.dom.DocumentImpl.createAttribute > > Changes: https://git.openjdk.java.net/jfx/pull/47/files > Webrev: https://webrevs.openjdk.java.net/jfx/47/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8233747 > Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod > Patch: https://git.openjdk.java.net/jfx/pull/47.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/47/head:pull/47 The proposed fix seems more like a workaround to me. There are dozens of very similar calls to `raiseOnDOMError` in this and other files, so I would think a more general solution is needed. PR: https://git.openjdk.java.net/jfx/pull/47
Re: [Approved] RFR: 8234056: Upgrade to libxslt 1.1.34
Hello folks!How can I remove myself from this mailing list?Thank in advance.Sent from my Samsung Galaxy smartphone. Original message From: Kevin Rushforth Date: 2019-11-20 9:07 AM (GMT-05:00) To: openjfx-dev@openjdk.java.net Subject: Re: [Approved] RFR: 8234056: Upgrade to libxslt 1.1.34 On Mon, 18 Nov 2019 13:29:32 GMT, Arun Joseph wrote:> We need to update the version of libxslt to the latest version, 1.1.34.> > > > Commits:> - 2d9c0bf3: 8234056: Upgrade to libxslt 1.1.34> > Changes: https://git.openjdk.java.net/jfx/pull/45/files> Webrev: https://webrevs.openjdk.java.net/jfx/45/webrev.00> Issue: https://bugs.openjdk.java.net/browse/JDK-8234056> Stats: 868 lines in 34 files changed: 419 ins; 263 del; 186 mod> Patch: https://git.openjdk.java.net/jfx/pull/45.diff> Fetch: git fetch https://git.openjdk.java.net/jfx pull/45/head:pull/45Looks good. This will need a second reviewer.Approved by kcr (Lead).PR: https://git.openjdk.java.net/jfx/pull/45
Re: [Approved] RFR: 8234056: Upgrade to libxslt 1.1.34
On Mon, 18 Nov 2019 13:29:32 GMT, Arun Joseph wrote: > We need to update the version of libxslt to the latest version, 1.1.34. > > > > Commits: > - 2d9c0bf3: 8234056: Upgrade to libxslt 1.1.34 > > Changes: https://git.openjdk.java.net/jfx/pull/45/files > Webrev: https://webrevs.openjdk.java.net/jfx/45/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8234056 > Stats: 868 lines in 34 files changed: 419 ins; 263 del; 186 mod > Patch: https://git.openjdk.java.net/jfx/pull/45.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/45/head:pull/45 Looks good. This will need a second reviewer. Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/45
Re: RFR: 8087980: Add property to disable Monocle cursor
On Mon, 18 Nov 2019 14:07:23 GMT, Dell Green
wrote:
> On Sun, 17 Nov 2019 10:04:36 GMT, Dell Green
> wrote:
>
>> On Sat, 16 Nov 2019 17:51:56 GMT, John Neffenger
>> wrote:
>>
>>> 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:
>>
>>> 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 seen on screen (in
the framebuffer for example). This change adds a system property
"monocle.cursor.enabled" that can disable the creation of a native
cursor in each of the Monocle NativePlatform implementations in favour
of a NullCursor which is a no-op implementation of the NativeCursor
abstract class that all native cursors have to implement.
NullCursor class already existed and was being returned for some
implementations like AndroidPlatform and HeadlessPlatform. This change
builds upon that and conditionally returns NullCursor for all
platforms.
A system property "monocle.debugcursor" has also been added to turn on
logging of which NativeCursor has been selected when the toolkit
initialises.
Commits:
- cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor
Changes: https://git.openjdk.java.net/jfx/pull/5/files
Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00
Issue: https://bugs.openjdk.java.net/browse/JDK-8087980
Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod
Patch: https://git.openjdk.java.net/jfx/pull/5.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5
>>>
>>> modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/NativePlatform.java
>>> line 50:
>>>
49: AccessController.doPrivileged((PrivilegedAction)
() -> {
50: final String str =
51: System.getProperty("monocle.debugcursor", "");
>>>
>>> Just a nit, but why `monocle.debugcursor` rather than
>>> `monocle.cursor.debug` (my preference), or at least
>>> `monocle.debugCursor`? Below is the full list, for comparison,
>>> including the two added by this pull request.
>>>
>>> monocle.cursor.enabled
>>> monocle.debugcursor
>>> monocle.epd.bitsPerPixel
>>> monocle.epd.enableInversion
>>> monocle.epd.forceMonochrome
>>> monocle.epd.noWait
>>> monocle.epd.rotate
>>> monocle.epd.useDitheringY1
>>> monocle.epd.useDitheringY4
>>> monocle.epd.waveformMode
>>> monocle.epd.y8inverted
>>> monocle.input..flipXY
>>> monocle.input..maxX
>>> monocle.input..maxY
>>> monocle.input..minX
>>> monocle.input..minY
>>> monocle.input..touchFilters
>>> monocle.input.touchFilters
>>> monocle.input.touchRadius
>>> monocle.input.traceEvents
>>> monocle.input.traceEvents.verbose
>>> monocle.maliSignedStruct
>>> monocle.platform
>>> monocle.platform.traceConfig
>>> monocle.screen.fb
>>> monocle.stackSize
>>>
>>> I'm nervous about our hidden API of system properties, and I'm as
>>> guilty as anyone with the nine properties I added for Monocle EPD. I
>>> think it might be okay as long as the code gets the property values
>>> only during class initialization. That should restrict their use to
>>> startup scripts and keep them out of application code trying to modify
>>> them *on-the-fly* at run time.
>>
>> if i recall i originally started with the format you recommend as it
>> made more sense, and when looking for other debug logging across the
>> javafx stack I picked up on somewhat of a loose existing convention so
>> changed to match it. I guess it can be whatever everyone agrees upon. :)
>
> On second thought, let's remove `monocle.debugcursor` and use a
> [PlatformLogger](https://github.com/openjdk/jfx/blob/master/modules/javafx.base/src/main/java/com/sun/javafx/logging/PlatformLogger.java).
> The JavaFX loggers are available from
> [Logging](https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/javafx/util/Logging.java).
> In retrospect, that's how I managed to avoid any new *debug* properties
> for Monocle EPD even though it's packed with debugging and trace
> messages. For examples, see the varia
