I've just tried to build the soft float version following the instructions
on the wiki. However when doing a 'gradle -PCOMPILE_TARGETS=armv6sf'. It
complains 'Error: missing tool packages: [arm-linaro-4.7.tgz]'.
I assume the shellscript that downloads the cross compiler tools is
the client rendering loop works? Like in X, in wayland you have
to flush queued op requests to the compositor. How/where should that be
On Thu, Jan 29, 2015 at 10:49 PM, David Hill david.h...@oracle.com wrote:
On 1/29/15, 4:35 PM, Erik De Rijcke wrote:
I'll probably test
/ instead of it's own
bug-risky evdev/raw kernel input implementation. ;)
Now if just somebody would sponser me so I can work fulltime to implement
these things ;)
On Tue, Mar 17, 2015 at 7:39 PM, David Hill david.h...@oracle.com wrote:
On 3/17/15, 8:04 AM, Erik De Rijcke wrote:
Why are there limitations on the embedded port of javafx to begin with?
Are there technical reasons for it?
If you think about it, It's arm, so it's embedded. It's x86 so it's
desktop doesn't make much sense... (atom is embedded, and there are arm
windows netbooks that are not).
Anyway, as a
-- Forwarded message --
From: Erik De Rijcke derijcke.e...@gmail.com
Date: Thu, Jan 29, 2015 at 10:35 PM
Subject: Re: Wayland support for JavaFX
To: David Hill david.h...@oracle.com
I'll probably test it on the Weston (the Wayland reference compositor) and
secretly also on my own
I'm looking at running javafx on wayland ( http://wayland.freedesktop.org
). First of all, I was wondering if anyone else knows of any attempts to
avoid duplicate work, as for now google turns op empty.
Secondly, I'm looking for sources on how to write a new javafx platform.
Disclaimer: I have not looked at the demo you're trying to run. I'm no
opengl expert so my advice might be a bit off, but I do know the basics of
I'm not familiar with JavaFX opengl rendering algorithm but is it really
needed to create a new (sub)texture object so many times?
We use JavaFX in an OSGi container, as a service component, in production,
so it's perfectly possible.
However there are a few gotcha's you need to take into account (I can not
c/p the code for obvious reasons...) which makes using it in osgi... quite
When triggering a
This way only the app will be accessible by other components through the
service registry. The app itself can not have any @reference because it it
is javafx itself that instantiates the app object and not the osgi
declarative services framework (which also takes care of injecting your
I'm not a shader expert either but I have worked (and written some myself)
with them, so I'll give my 0.02$ (given that I have no idea what the
complete shader looks like)
It looks to me like the initialization of a default scoped global (eg
Johan's vec2 pixcoord) is done using non constant
I tested the patch.
Without the dependency I get a an enormous stage (I explicitly set it to be
100x100). Debugging shows me the screen is initialized with these values:
of it, that's fine as I have a backup plan".
>> The only way around this will be to enumerate all schemas and all keys
>> and see if the ones we want are found in the list - a rather extreme
>> workaround for bad error handling behavior in their APIs...)
does it work as intended?
> On 5/18/16 11:59 AM, Erik De Rijcke wrote:
>> I tested the patch.
>> Without the dependency I get a an enormous stage (I explicitly set it to
>> be 100x100). Debugging shows me the screen is
Are there any known limitations on the gtk3 backends (html5, wayland, ...)
that could be used?
On Mon, May 9, 2016 at 3:18 PM, David Hill wrote:
> I added a new feature Friday and would like some help testing it.
> This new feature (8087516:
I ran into several issues, however I'm not sure they are related to gtk3
first of all it seems there is a dependency on: gsettings-desktop-schemas.
I'm not sure how desirable this is (I did not have it installed, installing
it fixed the error but I can image people not wanting to install it?)
I'm currently looking if I can get some robovm fork kickstarted. (
It's really a shame that for this one time Java has a real nice aot
llvm compiler, MS kills it. Being able to compile Java (or any
bytecode language) to a native, fast and small
In regard to your input issue. If it's a possibility, I'd recommend looking
at 'libinput'. It's an generic input abstraction library. It might be more
up to date and provide quirk fixes for (all kind of) input hardware.
On of the major problems we have here using javafx is the the extremely
slow loading speed of the fxmls (we have about 15000+ arm cortex devices
running javafx in production). Sure, there is a lot to gain in manually
optimizing and reducing the number of nodes and whatnot, but that kinda
Mail list logo