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
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
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.
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
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
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
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
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]
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
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
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
18 matches
Mail list logo
