ve me that idea.
This leads me to the idea that I have to look inside the JavaFX
implementation. However, it would be nice if I could have some pointer
of where to start and what to look for.
For the record, I'm on JavaFX 8.
font loader. The font loader opens the input stream, downloads the file
to a temporary folder and then opens the file, whereas the sound locator
just balks at the protocol.
Given that development of JavaFX 9 will switch to JRE 9 completely
anytime soon I'm thinking of switching to JavaFX 9 and a JRE 9. However,
do the freely available JVMs for ARMv7 32bit have a JIT?
Looks like you are using a 64-bit library on a 32-bit ARM.
Op 06-03-16 om 19:06 schreef Hrvoje Crnjak:
first of all, sorry for spamming your mailing list.
Recently I started building JavaFX appllication on RaspberryPi.
The idea of this application is to play .*mp4* videos
, and I did see the rc is 0.
Although ignoring the result does work, can it be something that is
lacking in the environment? The Yocto embedded Linux is naked from the
start, so it is totally possible that something else is missing.
(my pride on finding the flaw is quickly diminishing
, 2016 at 2:48 PM, Maurice <i...@cuhka.com> wrote:
At the moment the embedded environment I'm using is not able to use
downloaded or external supplied fonts. I've traced through the system and
found that it looks like it fails in pango.c FcConfigAppFontAddFile, at
d out! I removed the comment, but still the
result is false. I then overruled the return code in FTFactory.java
registerEmbeddedFont to be always true after it has called the native
function, and voilà, there are my external fonts.
What a journey.... :-)
. This seems
unnecessary, as long as the screen is the same screen all transforms and
scalars will remain the same for each touch event.
A solution in line of that of Johan Vos  works. JavaFX can be run and
doesn't crash on startup when compiling the shaders. I think they should
be taken into account for at least JavaFX 9, as it reduces a very
serious bug to a possible optimization.
Not only does it reduce the amount of errors, but I'm able to run
Ensemble, until now without any errors. Therefore it seems to be the
Prism pipeline init order: es2 sw
Using native-based Pisces rasterizer
Using dirty region optimizations
Using system sized mask
Moving the declaration into the main() method reduces the amount of
errors found by the glslangValidator drastically, though it still finds
ERROR: 0:53: 'oTexCoords' : undeclared identifier
I've included the generated source code of
FillRoundRect_LinearGradient_PAD. I've made the offending lines bold.
I've experimented with adding some modifiers, but to no avail.
#extension GL_OES_standard_derivatives : enable
I'm not very familiar with shader coding, but can't this be solved by
putting a non-constant modifier in fron of it? I notice other variables
are declared as 'varying' or 'uniform'.
Op 29-02-16 om 20:45 schreef Johan Vos:
It seems to me you might be running in the same issue we
3: 'return' : type conversion on return values was not
explicitly allowed until version 420
Should I still file a bug, or put additional information in an existing one?
As an aside, for me to continue, should I try to build a Yocto image
with an older driver?
Op 29-02-16 om 20:45 sch
Should I file a bug? I can't determine whether this is a client platform
issue or a major bug in the EGL that JavaFX is using. In any case, it
does not work on my embedded device.
Op 28-02-16 om 18:33 schreef Maurice:
When I run the glslangValidator
For those searching for an answer, I could fix it by adding pango and
fontconfig to the Yocto build.
ompilation errors. No code generated.
ERROR: 0:19: 'non-constant global initializer' : not supported with this
ERROR: 1 compilation errors. No code generated.
Op 27-02-16 om 19:10 schreef Maurice:
I'm running into the following exception when I start a simple JavaFX
Even though the system did not output to my LVDS screen JavaFX seemed to
be content initializing with ES2.
GLFactory using com.sun.prism.es2.MonocleGLFactory
(X) Got class = class com.sun.prism.es2.ES2Pipeline
Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline
Graphics Vendor: Vivante
I make sure that the application is basically only the primary stage,
therefore it only needs to publish itself. All other UI and business
logic is done by other bundles.
Op 20-02-16 om 15:50 schreef Stephen Winnall:
I have been trying a similar approach. I’m using declarative services
Dictionary<String, ?> properties = createDictionary();
BundleContext bundleContext =
Op 20-02-16 om 15:08 schreef Stephen Winnal
, but that is why the desktop exists.
On startup it registers itself, and thus the application content, with
the application, and when it is stopped it removes the content from the
application. The application has thus rarely to be updated itself.
public class UdooActivator
Yes, in lib/arm these libraries are present. I'm using the Oracle ARM
JDK 1.8.0_33 fwiw. On the default ubuntu based image I can run JavaFX
with this Java setup, but without HW acceleration.
root@udooqdl:/# find / -name "*javafx_font*.so"
*** Loading primary font factory failed. ***
*** Fallbacking to com.sun.javafx.font.t2k.T2KFactory ***
What should be added to the platform for this to be fixed?
Since I haven't received any additional feedback, should I push this patch?
Op 27 aug. 2015 15:56 schreef i...@cuhka.com:
I've adapted the build.gradle to use java -fullversion instead of java
-version, parsing the result with a regexp.
diff -r 9b5fc7c1e5e6 build.gradle
Mail list logo