On Sat, 6 Mar 2021 16:36:27 GMT, Kevin Rushforth wrote:
> Two additional comments, and otherwise looks good to me.
Thanks for the review, both the comments are addressed in next commit. Please
take a look.
-
PR: https://git.openjdk.java.net/jfx/pull/397
> Issue is that the size of properties that are relatively(`em`) sized is not
> computed correctly when the reference `-fx-font-size` is also specified
> relatively and is nested.
>
> Fix is a slight variation of an earlier suggestion in [the
>
> 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 2021-03-07T12:22:11 +
Neil C Smith wrote:
> Hi,
>
> A few comments from my perspective here, mainly coming from
> frustration at the number of times I've had to tell clients or users
> that JavaFX isn't a viable option for them ..
>
> On Sat, 6 Mar 2021 at 12:22, Mark Raynsford wrote:
Hi,
If I got you right you now changed your idea to render JavaFX into an
PixelBuffer and integrate that into a scene renderer with Vulkan, ... .
This exactly how the integration into SWT and Swing is done, the
internal API for that is found in "com.sun.javafx.embed". Before we
implemented
Why don't you just give it a try?
I'd start with the native PixelBuffer option first because it is
relatively simple and the performance is sufficient for most use cases.
There is, of course, an overhead caused by the GPU -> CPU -> GPU memory
transfer but it is not so bad if done right. I've
Hi,
A few comments from my perspective here, mainly coming from
frustration at the number of times I've had to tell clients or users
that JavaFX isn't a viable option for them ..
On Sat, 6 Mar 2021 at 12:22, Mark Raynsford wrote:
> there is a
> combinatorial explosion of possibilities with
