On Linux, GLEW requires (at least, in EGL land) that an OpenGL context be
active before glew_Init is called -- otherwise, GLEW doesn't know what
extension symbols to look up. If glew_Init fails, then some symbols
elsewhere will not exist, and the app will shortly crash. We work around
this by detecting if we're actually ready for postinit, and if not,
resetting the flag so that wxEVT_IDLE will cause us to try again later, when
the window hopefully has gone into the foreground and is ready to be used.
When determining whether or not we need to update the object list, we check
all of the objects that are being deleted to see if they're a wipe tower.
Unfortunately, by the time we check, the objects have already been deleted,
and the memory has been freed! Avoid this by writing down for deleted
objects whether they are wipe towers, and if they were, we can indeed skip
updating the object list.
In generate_contact_points, the rotated_dims don't actually generate a
Point, but generate an abstract expression that holds a reference to
bounding_box_size. Unfortunately, this goes wrong because bounding_box_size
ages out instantly; GCC's Address Sanitizer complains that this is a
"stack-use-after-scope" issue.
Interestingly, the Eigen documentation says that this is a known problem
with using C++11 "auto" to generate matrices (which a Point is)! It is
buried here: https://eigen.tuxfamily.org/dox/TopicPitfalls.html
This is probably an extremely theoretical correctness improvement, and also
an extremely theoretical performance improvement. But it is an improvement
nonetheless, and, more importantly, it enables me to continue to run the
slicer with Address Sanitizer turned on to find other potential issues.
ImGuiWrapper::load_svg previously could load an image that was not of the
aspect ratio specified by the target_width and target_height, and as a
result, could create an output vector that was smaller (or differently
shaped!) than the target_width and target_height. GCC's Address Sanitizer
flagged this because init_font was reading over the end of the allocated
buffer, but this also meant that images with incorrect aspect ratios might
get rendered to the font canvas incorrectly.
To solve this, we pass the generated width and height out from load_svg, and
use it when copying images later.
wxWidgets on Linux uses GStreamer as its back-end for wxMediaCtrl, which
doesn't have a bambu: URI handler. On Windows, this is handled by a Windows
Media subsystem plugin, and on Mac, this is handled with a BambuPlayer
class. Luckily, the libBambuSource.so binary that is distributed with the
network plugin package already contains support for receiving h.264 data
from the network, and the API is the same as is used by the tiny
bambusource.exe binary on Windows; we glue this into a GStreamer source
plugin that registers a URI handler for bambu:.
To make this work, we make a few additional changes elsewhere. GStreamer
seems to have trouble rendering an Xv overlay onto a 32bpp X visual, but
Bambu Slicer seems to request a 32bpp visual for some background
transparency in the Notebook; it doesn't seem to use it in an interesting
way on Linux, though, so we remove that request for transparency to allow
Bambu Studio to render to a 24bpp visual. The media controller
infrastructure also makes a few assumptions about when sizing information
can be queried from a wxMediaCtrl backend that do not hold true on Linux; we
either fix those assumptions, or fake them out, as needed. We also make a
few changes needed to successfully compile C.
This has only been tested with the GStreamer backend for wxWidgets --
notably, not the GStreamer-play backend (these are, astonishingly, two
different things!). If you find that this seems not to work, consider
*un*installing the libgstreamer-plugins-bad1.0-dev package and then
rebuilding wxWidgets.
Each time the dependency build was run, previously, the build system
attempted to patch wxWidgets after checking it out from Git. The problem,
of course, is that if this happened once, it would not succeed a second
time, so the only workaround was to blow away the wxWidgets source tree.
The real solution to this is to create a BBL fork of wxWidgets (or to
upstream the changes...). But for now, we add a file to determine whether
the patch has taken place already, and if it's there, we don't apply the
patch again. This will mean that all kinds of exciting things happen if you
change Git revisions of wxWidgets or the patch changes (in those cases,
you'll have to blow away the build), but at least this makes it possible to
build twice in the same repository in the best case.
To update an existing checkout, run:
$ touch deps/build/dep_wxWidgets-prefix/src/dep_wxWidgets/WXWIDGETS_PATCHED
On Linux, wxGTK by default attempts to use EGL if it is available on the
system, rather than GLX. Unfortunately, the ancient version of GLEW that we
packaged in did not support EGL, and even if it did, the configuration was
not set up to enable EGL. To solve this, we:
* upgrade GLEW to version 2.2.0, from upstream GitHub
* modify the Bambu build process to enforce that we use GLEW from the
built dependency
* remove the "extra" even older GLEW that was packaged
* modify GLEW's CMake configuration to enable EGL support when it is
available on the system (using the same test as wxWidgets uses to decide
whether to enable EGL support); if EGL isn't available at compile time,
both GLEW and wxWidgets will fall back on GLX
Note that you probably will have to blow away your CMakeCache for this to
work correctly -- otherwise, you may end up with the system GLEW, if you
have one installed (which is probably not what you want -- on Ubuntu, the
system GLEW is GLX, not EGL).
Joshua Wise