Tree support didn't fill the first layer when the tree is too short
udesk: 0284
Change-Id: I2702b26733e7360445e19847abb48f75f173da4e
(cherry picked from commit e317f9e19fbbfe21efb495e23a8ff78661bfee79)
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.
(cherry picked from commit ebbf494723042ea71bfced626b3ddbd3c365cd3f)
Change-Id: I3c27a1de3172103f90f02f6be92010d3432b5d5c
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
(cherry picked from commit 7df4d22e378275c28afb52ccb79b9f0f7dc0f5fa)
Change-Id: I645de1f76c3814735b573d81f3a0505359234a41
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).
Change-Id: I06de009a3fac9e5cf6a3ef16dde33df1516102e9
remove "\n" from _L macro
Change-Id: If1beda4a77f1c2b42945657b7386e155b8bc7a20
Signed-off-by: Stone Li <stone.li@bambulab.com>
(cherry picked from commit e7ea7705005379a7cc563254a8eaf7f48603e4a8)
1. display factor of extrusion calibration
2. add progress to calibration extrusion
3. support ext spool
Change-Id: Ic124a0097f16e6287c09f5f133eea84eeefb4000
Signed-off-by: Stone Li <stone.li@bambulab.com>
Change-Id: Idb86daf195df856e24c32363e763e38d77f39744
Signed-off-by: Stone Li <stone.li@bambulab.com>
(cherry picked from commit 986c3b162c7f5934c9f88ba281b6e47787b0f9fb)
Start gcode of P1P is wrong.
This is for github issue #1044
Signed-off-by: salt.wei <salt.wei@bambulab.com>
Change-Id: Id078b7c9020ef773373c3486f74dc51385b9dcc0
Change-Id: Ib0ceae161280258d9a9fbf6fb46d34810f24c57a
Signed-off-by: Stone Li <stone.li@bambulab.com>
(cherry picked from commit 1f5b67da2973ffa1d5a1de8d7677079883928cd6)
1. add gcode command for void printing detection
2. fix the issue that the toolhead is not at excess chute position when
smooth timelapse ends, by adding 2s pause after M991 command.
Jira: STUDIO-1996
Change-Id: I40cf16116e742744cea9bd90969e556a9ea2b2f1
Clipper2 doesn't solve wrong line issue for some
specific model and sometimes has performance issue.
Return to clipper1.
Signed-off-by: salt.wei <salt.wei@bambulab.com>
Change-Id: I906f8b81083ac8c03ecc9fe3e8d2ade20be95c04
This is useless now. Remove.
Signed-off-by: salt.wei <salt.wei@bambulab.com>
Change-Id: Id9a5e7822b19a74bf35670d5913214467b5a90ac
(cherry picked from commit 52580e16098ffb5386501d58d607c188861c96f2)
