WINDOWS_NATIVE_COMPILE_ENVIRONMENT is wrong with 32-bit cygwin
I am trying to build JavaFX with native media enabled. For background,
read *The initial problem* below. I run gradle in a mintty window.
So I am stuck in build.gradle ( line 2392 for me) in def buildGlib{
I have progressed somewhat since the initial problem and understand
the problem but not the root cause. I have put a few (Java) debugging
lines using the code below and summarised the result here.
Findings:
This is just a path problem.
I have 32-bit cygwin installed and the DOS path is correct .
/Initial DOS path==
C:\cygwin\usr\local\bin; C:\cygwin\bin;
C:\ProgramData\Oracle\Java\javapath; C:\Tcl\bin;/ etc
*WINDOWS_NATIVE_COMPILE_ENVIRONMENT is wrong:*
/WINDOWS_NATIVE_COMPILE_ENVIRONMENT===[ , PATH:; .
...;C:/Program
Files/TortoiseHg/;C:/MinGW/msys/1.0/bin;C:/MinGW/bin;
e:/robins_root/Gradle/gradle-1.8-all/gradle-1.8/bin;C:/cygwin64/bin;
,INCLUDE .../
As a result make $(shell cygpath ... can't work!
To help me understand the problem, my code below creates a /newEnv
/which /make /uses to buildGlib without error ( although
buildWinGStreamer still fails since I only fixed the local environment
for buildGlib not the global WINDOWS_NATIVE_COMPILE_ENVIRONMENT.
I have tried to find which code is turning /C:\cygwin\bin /into
/C:/cygwin64/bin/ but so far I have not seen where this is done. I have
looked in build.gradle & buildSrc\win.gradle and did not see anything there.
I also tried installing cygwin-64. But then I got errors where mintty
was looking for bash in c:\cygwin when it was in c:cygwin64!
Then I tried loading Red Hat cygwin-32 using installer 2.844. It copied
all the files into c:\rhcygwin , the installer then created a desktop
shortcut pointing to c:\rhcygwin\mintty. As soon as I clicked it I got
an error saying Can't find c:\cygwin\bash.exe! So I renamed the folder
to cygwin!
A can of 32-bit & 64-bit worms.
Who is taking c:\cygwin and turning into c:\cygwin64? There is no such
folder.
Thanks
robinH
P.S.
It would be helpful if the page Building OpenJFX
was
more specific about the versions of /Cygwin /& /make /which should be
used as it is quite specific for most of the other tools. /Cygwin/make/
has been making changes in how they deal with DOS paths so perhaps they
broke something. Perhaps something on tools 64 vs 32 too.
code
---
in def buildGlib{ , thus
def buildGlib = task("build${t.capital}Glib", dependsOn:
[buildResources]) {
enabled = IS_COMPILE_MEDIA
//RBH
System.out.println( "\n\nInitial DOS path===" +
System.getenv().get("PATH") )
System.out.println(
"\n\nWINDOWS_NATIVE_COMPILE_ENVIRONMENT="
+ WINDOWS_NATIVE_COMPILE_ENVIRONMENT )
Map newEnv = new HashMap(WINDOWS_NATIVE_COMPILE_ENVIRONMENT)
thePath = newEnv["PATH"]
thePath = thePath.replace("cygwin64","cygwin")
newEnv["PATH"] = thePath
System.out.println( "\n\nnewEnv=" + newEnv )
doLast {
exec {
//environment(WINDOWS_NATIVE_COMPILE_ENVIRONMENT)
environment(newEnv)
commandLine ("make", "${makeJobsFlag}",
"-C", "${nativeSrcDir}/gstreamer/projects/${projectDir}/glib-lite")
args("OUTPUT_DIR=${nativeOutputDir}",
"BUILD_TYPE=${buildType}", "BASE_NAME=glib-lite",
IS_64 ? "ARCH=x64" : "ARCH=x32",
"RESOURCE=${nativeOutputDir}/${buildType}/${WIN.media.glibRcFile}")
}
}
}
--
- The initial problem
-
I find JFX media HLS is not working well for me. It dies after about 30s
whereas VLC can pick up the 'dead' m3u8 and continue playing fine, so I
decided to build from source to try to see what is going on. I have
followed Michael Berry's efforts extending media codecs too. Also, I
found this
)
comment interesting in response to the question "Is there any support on
gstreamer 0.10 for Adaptive Streaming – Smooth Streaming, Dash etc. ?" .
'Slomo' replied /"There is some initial support for HLS but don’t use
0.10 for anything really. It’s no longer maintained since more than 2
years and a lot has happened since then"/. The rest of his blog ('*HTTP
Adaptive Streaming with GStreamer*') seem
Re: Make TableView height match content
On Wed, Jan 7, 2015 at 11:49 AM, Werner Lehmann wrote: > Hi Dan, > > typically it is not a good idea to do this. TableView has a reason to manage > scrolling on its own: if the tableview has 10 items you don't want to > have all these nodes in the scenegraph when it is sufficent to show the > visible ones. On that note, it would be interesting to explore the idea of managing TableView's (ListView's, TreeView's) scroll by its parent (e.g. a parent ScrollPane) while still keeping the content virtualized. It's not unreasonable to ask for, and not impossible either. It's just not how things are right now. Tomas
Re: Building Openjfx on Centos 6.6
Does any of this output give any indication as to what's going on? Ive tried various combinations of the params for dispman.display and dispman.layer but still don't see any sign of activity on the TFT screen. On Sat, Jan 3, 2015 at 2:36 PM, Nick Pratt wrote: > This is the output from my Pi with the modified JDK: > > pi@raspberrypi ~ $ sudo /opt/java/jre/bin/java -Djavafx.platform=monocle > -Dmonocle.screen.fb="/dev/fb1" -Ddispman.display=0 -Ddispman.layer=1 > -Dprism.verbose=true -Djavafx.verbose=true -jar JavaFXApp.jar > > Prism pipeline init order: es2 sw > > Using native-based Pisces rasterizer > > Using dirty region optimizations > > Using system sized mask for primitives > > Not forcing power of 2 sizes for textures > > Using hardware CLAMP_TO_ZERO mode > > Opting in for HiDPI pixel scaling > > Prism pipeline name = com.sun.prism.es2.ES2Pipeline > > Loading ES2 native library ... prism_es2_monocle > > Loaded /opt/jdk1.8.0_06/jre/lib/ext/../arm/libprism_es2_monocle.so from > relative path > > succeeded. > > GLFactory using com.sun.prism.es2.MonocleGLFactory > > Loaded /opt/jdk1.8.0_06/jre/lib/ext/../arm/libglass_monocle.so from > relative path > > (X) Got class = class com.sun.prism.es2.ES2Pipeline > > Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline > > JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit > > Maximum supported texture size: 2048 > > Non power of two texture support = true > > Maximum number of vertex attributes = 8 > > Maximum number of uniform vertex components = 544 > > Maximum number of uniform fragment components = 544 > > Maximum number of varying components = 32 > > Maximum number of texture units usable in a vertex shader = 8 > > Maximum number of texture units usable in a fragment shader = 8 > > Graphics Vendor: Broadcom > >Renderer: VideoCore IV HW > > Version: OpenGL ES 2.0 > > vsync: true vpipe: true > > Calling main(String[]) method > > Loaded /opt/jdk1.8.0_06/jre/lib/ext/../arm/libjavafx_font.so from relative > path > > Loaded /opt/jdk1.8.0_06/jre/lib/ext/../arm/libjavafx_font_freetype.so from > relative path > > ES2ResourceFactory: Prism - createStockShader: Solid_TextureRGB.frag > > > > > On Fri, Jan 2, 2015 at 10:10 AM, David Hill wrote: > >> On 12/31/14, 9:45 PM, Nick Pratt wrote: >> >> Thanks for the help. So now I can invoke Java without the link errors, >> but my JavaFX app isnt appearing on the attached TFT screen ( Note: I can >> get 'x' to appear on the the Pi TFT screen by setting the FRAMEBUFFER >> variable prior to invoking startx so I know my TFT screen is setup and the >> right Kernel mods are enabled and applied) >> >> Notwithstanding the error messages below, am I invoking Java correctly >> here : (based on the comments in >> https://javafx-jira.kenai.com/browse/RT-36960 ) >> >> >> I don't have access to your configuration (I only have a Pi with HDMI), >> so this is going to be hard for me to help with. You do need the sudo >> because of the permissions issues with the input devices. >> >> When Daniel added the code to mentioned in RT-36960, he did not have that >> configuration either, so we will need help understanding what is happening. >> >> You might try adding -Dprism.verbose=true -Djavafx.verbose=true >> and we might get lucky. >> >> >> pi@raspberrypi ~ $ java -Djavafx.platform=monocle >> -Dmonocle.screen.fb="/dev/fb1" -Ddispman.display=0 -Ddispman.layer=1 -jar >> JavaFXApp.jar >> >> Udev: Failed to write to /sys/class/input/mice/uevent >> >> Check that you have permission to access input devices >> >> Udev: Failed to write to /sys/class/input/event0/uevent >> >> Check that you have permission to access input devices >> >> Udev: Failed to write to /sys/class/input/input0/uevent >> >> Check that you have permission to access input devices >> >> Udev: Failed to write to /sys/class/input/mouse0/uevent >> >> Check that you have permission to access input devices >> >> >> If I run the above command as sudo root, then I dont see the errors >> printed, but still nothing on the TFT screen. >> >> Regards >> >> >> Nick >> >> >> >> On Wed, Dec 31, 2014 at 4:19 PM, David Hill >> wrote: >> >>> >>> Nick found a good one, took me a while to find the obvious :-p >>> >>> The UnsatisfiedLinkError was caused by old ARM JFX jars that were not >>> overriden when he copied the new bits into the JDK. >>> >>> On ARM we have a split set of jars for FX that we ship, but when we >>> build, we only build the single jfxrt.jar like the desktop. The split is >>> post build packaging. So Nick was mixing old and new jars, which is what >>> the Wiki told him to do. Doh. >>> >>> I updated the wiki for OpenJFX building and cross building with some >>> clarifications, notes and such, so hopefully the next solider will not find >>> so many mines. >>> >>> Dave >>> >>> On 12/29/14, 9:46 PM, Nick Pratt wrote: >>> So I made some progress here: I had installed Ubuntu 14.x 64-bit version. Once I installed the
Re: Make TableView height match content
On 07 Jan 2015, at 11:49, Werner Lehmann wrote: > Hi Dan, > > typically it is not a good idea to do this. TableView has a reason to manage > scrolling on its own: if the tableview has 10 items you don't want to > have all these nodes in the scenegraph when it is sufficent to show the > visible ones. > > Your approach may have some value if the number of items is quite low. In > that case I'd suggest to skip tableview and put your items in that same vbox. > Of course you'd have to handle columns yourself then. GridPane would make column handling will be a bit easier. Eric > > Werner > > On 06.01.2015 21:26, Dan Smith wrote: >> Putting this another way: TableViews automatically wrap their content >> in a (implicit?) scroll pane. I'd like to turn that off. Is there >> any way to do so?
Re: Make TableView height match content
Hi Dan, typically it is not a good idea to do this. TableView has a reason to manage scrolling on its own: if the tableview has 10 items you don't want to have all these nodes in the scenegraph when it is sufficent to show the visible ones. Your approach may have some value if the number of items is quite low. In that case I'd suggest to skip tableview and put your items in that same vbox. Of course you'd have to handle columns yourself then. Werner On 06.01.2015 21:26, Dan Smith wrote: Putting this another way: TableViews automatically wrap their content in a (implicit?) scroll pane. I'd like to turn that off. Is there any way to do so?
