On Thu, 7 May 2020 09:19:28 GMT, Bhawesh Choudhary
wrote:
> Root cause of issue is Specifying a image mask from GraphicsContextJava.cpp
> in WebKit was not implemented, so masking
> doesn't take place at all while rendering SVGRect. to fix this issue add
> implementation of function clipToImag
I think I know quite a bit about JavaFX graphics and I do not generally
agree with your statements.
Especially the statement that the Canvas is so much superior is a myth
from the old days of Java 8
where there were a few performance bugs in the scene graph handling. But
that's a long time ago.
I can see the value in a Shape.toPath() method (or alternatively a
Path.of(Shape) method). I'm still not sold on the value proposition of a
similar method to GraphicsContext (and "just make this internal
information public" isn't a recipe for adding new API).
You can file an Enhancement reque
>From the JavaDoc "Canvas is an image that can be drawn on using a set of
graphics commands provided by a GraphicsContext." This a bit of a
misnomer. While canvas can be used to draw in image (actually
GraphicsContext not canvas itself), the image based methods of
GraphicsContext are far outweigh
On Thu, 7 May 2020 21:15:02 GMT, Joeri Sykora wrote:
> Adds support for building static libraries of the OpenJFX modules for the
> Windows platform. Building static libraries
> is done by providing the gradle property `-PSTATIC_BUILD=true`.
> Changes include:
>
> - add static flags for the comp
Hi,
I have to say that your requirements sound a little bit strange to me,
but maybe you can make it clearer what your real use-case behind them is.
What I do not understand is why you are using the canvas at all.
Conceptually the canvas is for direct mode rendering into an image. The
fact that
No... given a Shape, create a Path that represents the outline of that shape.
If I had a Path I wouldn’t be requesting the new methods.
One of the workarounds for getting a Path from a GraphicsContext is to keep
track of it as I’m drawing... however, this is overhead in the gc call that can
be
The performance tracker was identified back in the JDK 9 time frame as a
possible candidate for a public API. The following request is tracking it:
https://bugs.openjdk.java.net/browse/JDK-8145154
If someone wants to spend the effort to take this feature request and
drive it to completion, inc
On Fri, 8 May 2020 19:12:48 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/native-prism-d3d/D3DPipeline.cc line 39:
>>
>>> 38:
>>> 39: static jboolean checkAndClearException(JNIEnv *env) {
>>> 40: if (!env->ExceptionCheck()) {
>>
>> while this looks ok to me, I'm not sure w
The current path is defined by the application - you - and yet you don't
know what it is ?
You do say
> I have other workarounds where I have to maintain a path as I’m
drawing in the canvas
Why can't you do that ? No internal API digging.
-phil
On 5/8/20, 12:02 PM, jfx user2 wrote:
Ok, the
On the topic of private APIs that should probably be public... can the
performance tracker class be made public too? I'd very much like to know
the FPS at which my application is running at.
On Fri, 8 May 2020 19:01:28 GMT, Johan Vos wrote:
>> Adds support for building static libraries of the OpenJFX modules for the
>> Windows platform. Building static libraries
>> is done by providing the gradle property `-PSTATIC_BUILD=true`.
>> Changes include:
>>
>> - add static flags for the c
On Fri, 1 May 2020 15:22:39 GMT, Ambarish Rapte wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TabPaneSkin.java
>> line 994:
>>
>>> 993: private void moveTab(int moveToIndex, TabHeaderSkin
>>> tabHeaderSkin) {
>>> 994: if (moveToIndex !=
>>> head
On Wed, 15 Apr 2020 02:35:44 GMT, Bernhard M. Wiedemann
wrote:
>> @bmwiedemann are you planning to pursue this PR?
>
> Long term, yes.
>
> I am currently low on time and my Java-foo is not that great, so I was hoping
> that someone would pick it up.
I note that the JDK build recently implemen
Ok, then please consider the GraphicsContext request that I’ve made. It simply
enables you to get the Path from the context without exposing com classes at
all. I have other workarounds where I have to maintain a path as I’m drawing
in the canvas or I have to do hit testing on a non vector ima
On Thu, 7 May 2020 21:15:02 GMT, Joeri Sykora wrote:
> Adds support for building static libraries of the OpenJFX modules for the
> Windows platform. Building static libraries
> is done by providing the gradle property `-PSTATIC_BUILD=true`.
> Changes include:
>
> - add static flags for the comp
On Fri, 8 May 2020 11:25:03 GMT, Jose Pereda wrote:
> There is a visual glitch when the scrollbar controls are laid out on touch
> enabled devices.
>
> The first time they are laid out in the wrong location (20 px from right or
> bottom), while the next passes are correct
> (8 px from right or
On Thu, 5 Mar 2020 16:01:10 GMT, Robert Lichtenberger
wrote:
> This PR fixes JDK-8176270 by clamping the end index of the selected text to
> the length of the text.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jfx/pull/138
On Sat, 21 Dec 2019 15:36:14 GMT, Oliver Kopp
wrote:
> This is a WIP PR. Requesting for comments.
>
> I could not replicate the test given at
> https://bugs.openjdk.java.net/browse/JDK-8176270 without TestFX. I
> nevertheless
> let my try to replicate the @Test things in here.
> The fix is ju
On Fri, 6 Mar 2020 06:00:36 GMT, Robert Lichtenberger
wrote:
>> I have exactly the same question.
>>
>> In general, it's better to work with the author of an existing PR instead of
>> creating a new one. If the original PR #73
>> is completely stalled, then it might make sense, but not until t
On Tue, 14 Apr 2020 11:47:21 GMT, Kevin Rushforth wrote:
>> Just a comment on how to add a failing test: we can replace the actual
>> typing (in the TestFx context) by
>> programmatically replacing the selection, actually, it doesn't even need the
>> skin (so no scene nor parent) because all
>
Since Canvas is an immediate mode graphics API, I presume you are
interested in the most recent drawing primitive? (we don't keep the
composite shape for all drawing primitives -- that would be both too
expensive and not really appropriate). How would you expect current
rendering attributes (e.
Kevin, go easy please :0). There is a need.
Access to the outline of the path in the canvas is great for edge following,
node attachment points, animating around the non-rectangular border of what’s
actually displayed, etc.
The other request that I haven’t posted yet is to do the same for Shap
While there is no plan to "open up" more of com.sun.javafx (and that
isn't really the right way to look at it), if you have a proposed
enhancement to the existing public javafx.* classes we could discuss it.
As for your specific example, can you say more about what your use case
is? The Graphi
I am aware of this and that’s why I am asking. There are useful private
features in com.sun.javafx and I explained one of them in my message. I have
an additional related example but the larger question is if there is a plan to
open more of com.sun.javafx to the public api, documentation surro
Wondering which JavaScript engine gets referred to in WebEngine [1].
In case it is currently (JavaFX 14) Nashorn [2], what happens after Nashorn
gets removed from the
next [3] version? In case it is WebKit's JavaScriptCore [4] where can one study
the interface from
WebEngine to it?
---rony
[1]
On Fri, 8 May 2020 12:21:48 GMT, Ajit Ghaisas wrote:
> Issue :
> https://bugs.openjdk.java.net/browse/JDK-8244418
>
> Root Cause :
> Incorrect assumption about menu list size.
>
> Fix :
> Added check for empty menu list before trying to access it.
>
> Test :
> Added a unit test that fails befo
Only javafx.* packages are part of the public API. Anything else,
including com.sun.javafx.*, is internal implementation details that an
application should never call.
-- Kevin
On 5/8/2020 12:38 AM, jfx user2 wrote:
Is there documentation around the packages (com.sun.javafx vs javafx) used
i
> CSR: https://bugs.openjdk.java.net/browse/JDK-8218264
Nir Lisker has updated the pull request with a new target base due to a merge
or a rebase. The pull request now
contains 11 commits:
- Merge branch 'master' into 8217472_Add_attenuation_for_PointLight
- Attenuation and range changed inter
Issue :
https://bugs.openjdk.java.net/browse/JDK-8244418
Root Cause :
Incorrect assumption about menu list size.
Fix :
Added check for empty menu list before trying to access it.
Test :
Added a unit test that fails before fix and passes after it.
-
Commit messages:
- 8244418_fix
On Tue, 5 May 2020 10:50:40 GMT, Jeanette Winzenburg
wrote:
> The issue is that ChoiceBox didn't sync its value to the replaced
> SelectionModel's selectedItem if the item is null.
>
> Fixed by removing the constraint from selectionModel property.
>
> Added tests that failed before and passed
There is a visual glitch when the scrollbar controls are laid out on touch
enabled devices.
The first time they are laid out in the wrong location (20 px from right or
bottom), while the next passes are correct
(8 px from right or bottom).
The reason for this glitch is the use of `getWidth()` o
On Tue, 5 May 2020 10:50:40 GMT, Jeanette Winzenburg
wrote:
> The issue is that ChoiceBox didn't sync its value to the replaced
> SelectionModel's selectedItem if the item is null.
>
> Fixed by removing the constraint from selectionModel property.
>
> Added tests that failed before and passed
On Tue, 5 May 2020 16:49:09 GMT, Jose Pereda wrote:
> `VirtualFlow` makes use of `VirtualScrollBar` controls, that are laid out
> next to the clipped container region, by
> default.
> However, when touch is supported, these scrollBars are floating controls laid
> out over the container. Therefo
On Tue, 5 May 2020 16:49:09 GMT, Jose Pereda wrote:
> `VirtualFlow` makes use of `VirtualScrollBar` controls, that are laid out
> next to the clipped container region, by
> default.
> However, when touch is supported, these scrollBars are floating controls laid
> out over the container. Therefo
Multitouch display support JavaFX on Windows, iOS, and Android seems
straightforward. If the OS recognizes the display as multitouch, then the
chances are that JavaFX will also work with it since it relies on the
native multitouch support of the OS.
When it comes to Linux and OSX, it's not always
Is there documentation around the packages (com.sun.javafx vs javafx) used
in JavaFX?
For example, why is there a com.sun.javafx.geom that isn't fully mirrored
in the javafx.scene.shape package? Why are there missing features from
Graphics2D?
I have a specific example that prompted the question:
Adds support for building static libraries of the OpenJFX modules for the
Windows platform. Building static libraries
is done by providing the gradle property `-PSTATIC_BUILD=true`.
Changes include:
- add static flags for the compiler and linker
- use `lib` for linking instead of `link`
- only b
38 matches
Mail list logo
