Menu
▾
▴
Re: [openvrml-develop] ANN: OpenVRML 0.18.5
|
From: Braden M. <br...@en...> - 2010-03-15 09:03:51
|
On Sun, 2010-03-14 at 21:39 -0700, Greg Roelofs wrote:
> Lots o' issues, a few successes...
>
> Docs:
>
> - README needs to call out libtool/libltdl as a required dependency.
Yes, it should.
> - D-Bus does _not_ automatically start openvrml-xembed on my box. No clue
> how that's supposed to work. The workaround mentioned on the list works,
> but the README is slightly misleading.
You do have to install it for this to work. It works (when it does)
because OpenVRML installs a descriptor to a place that D-Bus knows
about. On Fedora, that's:
/usr/share/dbus-1/services/org.openvrml.BrowserControl.service
If D-Bus is looking somewhere different on Debian, that would be a
problem.
> Build:
>
> - AFAICT, it is flat out impossible to do a full openvrml build on reasonably
> modern Debian/Ubuntu. Both xulrunner 1.9.1 (required due to some unique
> header file, according to configure) and 1.8.1 (the source of libmozjs)
> are required, and they cannot be installed simultaneously due to some
> unspecified conflict. Ergo, no JS.
That sounds like something you should complain to Debian's xulrunner
package maintainers about.
> - The dependency list is...stunning. I had to install close to a gigabyte
> of additional stuff, and I already had a fairly decent development box.
> Extra/upgraded Ubuntu packages:
>
> sudo apt-get install libboost1.37-dev libboost1.37-doc
> - [51MB of archives, 183MB of disk space]
> - [gccxml libboost-date-time1.37-dev libboost-date-time1.37.0
> libboost-filesystem1.37-dev libboost-filesystem1.37.0
> libboost-graph1.37-dev libboost-graph1.37.0 libboost-iostreams1.37-dev
> libboost-iostreams1.37.0 libboost-program-options1.37-dev
> libboost-program-options1.37.0 libboost-python1.37-dev
> libboost-python1.37.0 libboost-regex1.37-dev libboost-regex1.37.0
> libboost-serialization1.37-dev libboost-serialization1.37.0
> libboost-signals1.37-dev libboost-signals1.37.0 libboost-system1.37-dev
> libboost-system1.37.0 libboost-test1.37-dev libboost-test1.37.0
> libboost-thread1.37-dev libboost-thread1.37.0 libboost-wave1.37-dev
> libboost-wave1.37.0 libboost1.37-dev libboost1.37-doc]
This could probably be narrowed a bit. But Boost upstream is
distributed en masse; Debian has divided it up.
> sudo apt-get install libpng-dev libjpeg-dev xulrunner-1.9-dev default-jdk libgl1-mesa-dev libglw1-mesa-dev libosmesa6-dev libgtkglext1 libgtkglext1-dev libcurl4-gnutls-dev libdbus-1-dev libdbus-glib-1-dev libsdl1.2debian-pulseaudio doxygen doxygen-doc
> - [25.5MB of archives, 110MB of disk space]
> - [comerr-dev default-jdk doxygen doxygen-doc libcurl4-gnutls-dev
> libdbus-1-dev libdbus-glib-1-dev libgcrypt11-dev libglw1-mesa
> libglw1-mesa-dev libgnutls-dev libgpg-error-dev libgtkglext1
> libgtkglext1-dev libidn11-dev libkadm55 libkrb5-dev libldap2-dev
> libnspr4-dev libnss3-dev libosmesa6 libosmesa6-dev
> libsdl1.2debian-pulseaudio libtasn1-3-dev libxmu-dev libxmu-headers
> openjdk-6-jdk xulrunner-1.9-dev]
> - [REMOVE libsdl1.2debian-alsa]
> sudo apt-get install gcj libgcj-dev libgcj-doc java-gcj-compat java-gcj-compat-dev ant
> - [96.7MB of archives, 604MB of disk space]
> - [ant-gcj ant-optional ant-optional-gcj antlr ecj ecj-gcj fastjar gcj-4.3
> gcj-4.3-base gappletviewer-4.3 gij gij-4.3 gjdoc java-gcj-compat-headless
> libantlr-java libantlr-java-gcj libbcel-java libecj-java libecj-java-gcj
> libgcj-bc libgcj-common libgcj9-0 libgcj9-0-awt libgcj9-dev libgcj9-jar
> libgcj9-src libjaxp1.3-java libjaxp1.3-java-gcj liblog4j1.2-java
> liblog4j1.2-java-gcj libmx4j-java libregexp-java libxerces2-java
> libxerces2-java-gcj]
Dude, I just need jni.h and javac. Blame this on the JDK and/or gcj
folks.
> sudo apt-get install libtool libtool-doc
> - [libltdl7-dev libtool libtool-doc]
> sudo apt-get install libxml2-dev libxml2-doc
> - [libxml2-dev libxml2-doc]
> sudo apt-get install libmozjs-dev
> - [libmozjs-dev]
> sudo apt-get install libgnomeui-dev libgnomeui-doc
> - [4102kB of archives, 21.7MB of disk space]
> - [libart-2.0-dev libavahi-client-dev libavahi-common-dev libavahi-glib-dev
> libbonobo2-dev libbonoboui2-dev libgail-dev libgconf2-dev
> libgnome-keyring-dev libgnome2-dev libgnomecanvas2-dev libgnomeui-dev
> libgnomeui-doc libgnomevfs2-dev libidl-dev liborbit2-dev libpopt-dev
> libselinux1-dev libsepol1-dev orbit2]
Well, that goes to show how much good being a good citizen and not
depending on deprecated GNOME libraries does me. (I'm talking to you,
gnomevfs2.)
> sudo apt-get install xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support
> - [13.5MB of archives, 25.3MB of disk space]
> - [xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support]
> - [REMOVE libmozjs-dev xulrunner-1.9-dev]
I don't think you can blame me or mozilla.org for this. And ordinarily
I really enjoy blaming mozilla.org for stuff.
> The (single-threaded) first, non-JS build took 102 minutes on one of two
> 1.6 GHz Atom 330's; build directory was 820 MB afterward. Still chugging
> away on the second build to work around:
Atoms are, of course, targeted at power efficiency rather than
performance. I have an Atom 330 myself. It's a neat little machine.
But I don't use it to build software.
FWIW, though, OpenVRML's build parallelizes well. You should see some
performance benefit from "make -jN" since the 330 has two cores with
hyperthreading. Of course, you may find yourself memory-limited. But
if you've installed 4 GB in the machine, I think you should be able to
use -j4 safely.
By comparison, an i7 920 using -j8 can build all of OpenVRML in about
five minutes.
> - I'm kind of amazed that, a month after release, nobody has yet noticed
> that JPEG is broken:
>
> if test X$enable_jpeg_textures = Xno; then
> JPEG_LIBS=""
> JPEG_LIBS="-ljpeg"
>
> cat >>confdefs.h <<\_ACEOF
> #define OPENVRML_ENABLE_JPEG_TEXTURES 1
> _ACEOF
>
> fi
>
> Yeah, not so much.
Argh. Missing comma in configure.ac.
> Install:
>
> - Where's sdl-viewer? Oh, buried down in an example directory. Given
> the issues with openvrml-player (below), it would probably be good to
> install sdl-viewer by default (maybe as openvrml-sdl-viewer, for
> consistency and general non-generic-ness).
I'd rather fix openvrml-player. But aside from issues with automatic
activation of openvrml-xembed, it's not clear to me that you're having
problems that aren't shared by sdl-viewer.
> Run:
>
> - openvrml-player doesn't work at all. The best it manages is a single
> frame before crashing, and that only on extremely simple worlds. On at
> least a couple of occasions it chokes with signs of memory corruption:
>
> openvrml-player pngboxes.wrl
> ** (openvrml-xembed:26721): DEBUG: inserted reference to :1.197
> get fences failed: -1
> param: 6, val: 0
> *** glibc detected *** /usr/local/libexec/openvrml-xembed: corrupted double-linked list: 0xb29b35e0 ***
> ======= Backtrace: =========
[snip]
Ouch.
The DEBUG message from openvrml-xembed is normal. Everything south of
that is not.
I can reproduce this; I'll find out what's going on here.
> and simultaneously this stuff showed up for any X event in the player window:
>
> ** (openvrml-player:26724): CRITICAL **: void<unnamed>::reset_fds(<unnamed>::CURLSource&): assertion `Invalid multi handle' failed
> [x many]
That just means that openvrml-xembed has died unexpectedly and the
openvrml-player process doesn't know what to do. :-/
Are the other problem worlds publicly available?
> - sdl-viewer, as someone else (Braden?) noted a few months back, does work
> (mostly), and it conveniently doesn't kill xembed even when the viewer
> aborts.
sdl-viewer doesn't use openvrml-xembed. The idea behind openvrml-xembed
is to have a single viewer backend that is usable as either a
stand-alone viewer or a browser plug-in.
> - Speaking of things that haven't changed since 2000, I see the Background
> node still doesn't transform with Viewpoint...I know I reported that bug
> many, many years ago.
OpenVRML's renderer really needs a near-complete rewrite at this
point. :-/
> - The normalized-vector warning is kind of annoying. I don't know how much
> more normalized it expects me to get, but if 6+ nines won't cut it, there's
> something wrong with the code:
>
> orientation -0.10618 0.98856 0.10712 1.5911
>
> sqrt(0.10618*0.10618 + 0.98856*0.98856 + 0.10712*0.10712)
> .99999988019999282397
>
> Not a big deal, obviously, but it's also 100% trivial to check whether
> the vector's within, say, 0.001 of 1.0, which should be "good enough."
Yes; OpenVRML's float comparison is probably being too picky.
> System particulars:
>
> - dual Intel Atom 330 1.6 GHz, 2 GB RAM, Intel 945G graphics
Ah, 2 GB. Well, since you're using i686 instead of x86_64, "make -j4"
is probably still doable.
> - Ubuntu 2009.04 32-bit (64-bit box shipped that way, argh...)
Fixable. :-) But if you plan on using this to build software, I'd
recommending 4 GB of RAM if you want to use x86_64 Linux. gcc can
consume a lot of memory; and IME, x86_64 can really nearly double its
memory consumption.
Thanks for taking the time to hammer on OpenVRML.
--
Braden McDaniel <br...@en...>
|
