There was a thread around obsolete rendering code (1) around removal of
Prisim rendering and related api layers architectural elements later on.
Is this relevant here?
Eric
(1)
https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-January/028581.html
On Wed, Feb 17, 2021 at 8:11 AM Herve
On Wed, 17 Feb 2021 22:52:01 GMT, John Hendrikx wrote:
>> This is a PoC for performance testing.
>>
>> It contains commented out code in PopupWindow and ProgressIndicatorSkin and
>> two tests are failing because of that.
>>
>> This code avoids registering two listeners (on Scene and on
On Wed, 17 Feb 2021 22:52:01 GMT, John Hendrikx wrote:
>> This is a PoC for performance testing.
>>
>> It contains commented out code in PopupWindow and ProgressIndicatorSkin and
>> two tests are failing because of that.
>>
>> This code avoids registering two listeners (on Scene and on
On Tue, 16 Feb 2021 18:59:30 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java line 2:
>>
>>> 1: /*
>>> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
>>
>> The initial year needs to be preserved. Please restore as
On Tue, 16 Feb 2021 17:55:45 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add missed null checks to fix test failure
>
> modules/javafx.graphics/src/main/java/javafx/scene/SubScene.java
> This is a PoC for performance testing.
>
> It contains commented out code in PopupWindow and ProgressIndicatorSkin and
> two tests are failing because of that.
>
> This code avoids registering two listeners (on Scene and on Window) for each
> and every Node to support the aforementioned
> This is a new approach to rewrite parts of gtk glass backend to be more clean.
>
> I will provide small "manageable" PR to incrementally make the backend better.
>
> This PR adresses cleanup of the Size and Positioning code. It makes code more
> "straightforward" and easier to maintain.
>
>
On Wed, 17 Feb 2021 18:45:28 GMT, Kevin Rushforth wrote:
>> `Tooltip` is no longer hiding upon receiving
>> `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on
>> overlaying tooltip also kills the tooltip, so the infinite duration tooltip
>> can be closed.
>
> I'll review and
On Fri, 5 Feb 2021 10:46:49 GMT, Paweł Kruszczyński
wrote:
> `Tooltip` is no longer hiding upon receiving
> `MouseEvent.MOUSE_ENTERED_TARGET` event inside it. Pressing mouse on
> overlaying tooltip also kills the tooltip, so the infinite duration tooltip
> can be closed.
I'll review and
`Tooltip` is no longer hiding upon receiving `MouseEvent.MOUSE_ENTERED_TARGET`
event inside it. Pressing mouse on overlaying tooltip also kills the tooltip,
so the infinite duration tooltip can be closed.
-
Commit messages:
- 8261221: Tooltip bigger than screen size blinks - shows
On Wed, 17 Feb 2021 14:14:35 GMT, Arun Joseph wrote:
> Timer in RunLoopGeneric has an open bug in WebKit
> (https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain
> active even after firing.
>
> Reverting back to WebCore Timer for ScrollAnimation in Linux.
Looks good.
Timer in RunLoopGeneric has an open bug in WebKit
(https://bugs.webkit.org/show_bug.cgi?id=189335) causing the timer to remain
active even after firing.
Reverting back to WebCore Timer for ScrollAnimation in Linux.
-
Commit messages:
- 8260257: [Linux] WebView no longer reacts to
There is also something that we should be aware of. The external graphic
context is a fragile thing. In our case, for example with OpenGL, it was
very easy to create problems with the Java app which try to paint things on
the context. Which can lead to crashes or artefacts.
Le mer. 17 févr. 2021
On Tue, 16 Feb 2021 at 23:33, Michael Strauß wrote:
> The main problem with this idea is that there is no universally available
> hardware rendering backend in JavaFX. There's OpenGL on Linux and macOS,
> Direct3D on Windows, and potentially a software renderer on all platforms.
How is that a
On Tue, 16 Feb 2021 at 20:41, Mark Raynsford wrote:
> I've used
> GStreamer outside of Java quite a bit for aggregating feeds from
> network cameras...
Yes, just working with a client doing exactly that - and the UI won't
be using JavaFX there, in fact they're still using Swing/AWT because
it's
15 matches
Mail list logo
