Hello Kevin,
thanks for the analysis.
I think this is the cause since each Eclipse plugins have their own classloader
and I have several plugins with JavaFX classes. I will write a bug report on:
https://bugs.java.com/
Gesendet: Donnerstag, 04. Oktober 2018 um 16:13 Uhr
Von: "Kevin Ru
Glad you were able to fix your issue. If you don't need to apply the
effect to the group with the animating content, then it will be able to
be cached, which is where I guess the speedup is coming from.
-- Kevin
On 10/4/2018 1:44 PM, Tom Schindl wrote:
Hi Kevin,
Thank you for the comment so
Hi Kevin,
Thank you for the comment so the trick to fix my problems is that I
don't apply the effect on the container but create a 2nd node who has
the same size and is a sibling of my area and apply the effect there?
This looks like it is working ;-)
package fxbugs;
import javafx.animation.Sca
Johan,
I’m guessing that Gluon Mobile and GluonVM will run on Android with JavaFX 11
(eventually at least).
Is this correct?
Graciously,
John-Val Rose
Rosethorn Technology
> On 5 Oct 2018, at 06:00, Kevin Rushforth wrote:
>
>
>> My proposal would therefore be that I split the changes into
Any effect has the potential for slowing down depending on the size if
the node being rendered, since it is done as an image operation on the
entire area (bounding box) covered by the Parent. Have you noticed
whether DropShadow is worse than other effects, say, GaussianBlur? One
other thing to
My proposal would therefore be that I split the changes into
Android/Dalvik/Monocle changes that do not affect any other platform, and
create PR's for merging these changes in upstream. While my prototype is
working (see https://twitter.com/johanvos/status/1047804607320260608) I
need to clean
You just need Android Studio 3 for try-with-resources. See
https://developer.android.com/studio/write/java8-support
I've never had a problem using java.util.logging with Android. Logging
ends up in logcat.
On 10/4/18 2:45 PM, Nir Lisker wrote:
But indeed, there are other things (e.g. try-res
>
> But indeed, there are other things (e.g. try-resource with variable) that
> can not be used on Android. In general, there are too much restrictions,
> which is why we need a bundled Java 11 in the longer term.
How does JavaFXPorts deal with this?
We use java.util.logging for now.
That will
Yes, I also noticed that DropShadow causes severe performance degradation.
Dirk
> On 4 Oct 2018, at 13:10, Tom Schindl wrote:
>
> Hi,
>
> Why does applying a DropShadow on a large region cause problem when
> animating nodes contained in that region?
>
>> package fxbugs;
>>
>> import javafx.a
On 04.10.18 20:00, Nir Lisker wrote:
> Hi Johan,
>
> Thanks for the work. A couple of questions:
>
>
>> I worked from the openjfx/develop repository and created a version that
>> works on Android (will work on iOS soon).
>
>
> I'm not very familiar with the state of mobile. Doesn't Android
On Thu, Oct 4, 2018 at 8:01 PM Nir Lisker wrote:
> Hi Johan,
>
> Thanks for the work. A couple of questions:
>
>
>> I worked from the openjfx/develop repository and created a version that
>> works on Android (will work on iOS soon).
>
>
> I'm not very familiar with the state of mobile. Doesn't An
On Thu, Oct 4, 2018 at 7:10 PM Sverre Moe wrote:
> Den tor. 4. okt. 2018 kl. 19:01 skrev Johan Vos :
>
>> Hi,
>>
>> I worked from the openjfx/develop repository and created a version that
>> works on Android (will work on iOS soon).
>> This required some changes, as we're running on top of the An
Hi Johan,
Thanks for the work. A couple of questions:
> I worked from the openjfx/develop repository and created a version that
> works on Android (will work on iOS soon).
I'm not very familiar with the state of mobile. Doesn't Android support
only up to Java 8 API? What happens if there is 'v
Den tor. 4. okt. 2018 kl. 19:01 skrev Johan Vos :
> Hi,
>
> I worked from the openjfx/develop repository and created a version that
> works on Android (will work on iOS soon).
> This required some changes, as we're running on top of the Android VM,
> which is not really Java (not even close).
>
>
Hi,
I worked from the openjfx/develop repository and created a version that
works on Android (will work on iOS soon).
This required some changes, as we're running on top of the Android VM,
which is not really Java (not even close).
The longer-term goal is to run a JVM on Android as well, but that
Hi,
Just to make sure I understand. Do you say that other OSGi-Bundles bring
with them their own FXCanvas?
I've been looking at the e(fx)clipse code [1] who deals with FXCanvas,
... but I can't think of a situation where we create multiple classloaders.
Tom
[1]
https://github.com/eclipse/efxcli
Hi,
FXCanvas should not be loaded multiple times. This sounds like a severe
bug in e(fx)clipse OSGi-Adapterhooks.
Tom
On 04.10.18 16:13, Kevin Rushforth wrote:
> I think I see what caused this. In FX 8 we called FXCanvas::initFx from
> the constructor of every FXCanvas. It then called an interna
I think I see what caused this. In FX 8 we called FXCanvas::initFx from
the constructor of every FXCanvas. It then called an internal startup
method, PlatformImpl::startup, that permits calling it when the Toolkit
is already initialized, turning it into a runLater if it is. As part of
the refac
Hello Kevin,
I still have problems with the error: "java.lang.IllegalStateException: Toolkit
already initialized".
However I found out that this error only occurs if I call SWT FXCanvas classes
located in different Eclipse plugins.
I can create multiple JavaFX canvas if they are located in
Hi,
Why does applying a DropShadow on a large region cause problem when
animating nodes contained in that region?
> package fxbugs;
>
> import javafx.animation.ScaleTransition;
> import javafx.application.Application;
> import javafx.geometry.Insets;
> import javafx.scene.Node;
> import javafx.s
21 matches
Mail list logo
