No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Committed rB29755e1df82e34061a0b0586234a5aaac5177d35, closing.

Sounds like a good plan.

In D7989#195226, @Brecht Van Lommel (brecht) wrote:

Why can't Blender dependencies use alternative build systems? meson is now widely available in Linux distributions and can even be installed as normal user via pip (pip install meson).

If it's an external library we'll use whatever build system it uses. But we try to keep building Blender itself simple for users and developers, with platform maintainers making the precompiled libraries and dealing with those problems. Meson might use a different compiler, use different compile flags, detect different external libraries, or cause build failures in some other way that CMake doesn't.

Anyway, I'd like @Campbell Barton (campbellbarton) and @Sergey Sharybin (sergey)'s opinion on the right direction here.

• Disable WITH_GHOST_WAYLAND_LIBDECOR by default

In D7989#243849, @Julian Eisel (Severin) wrote:

I have very mixed feelings about this. First of all, I find the GNOME idea to require client side decorations... questionable, to say it in the nicest possible way. Blender could be a strong voice opposing that decision, rather than just accepting it and ignoring that this throws smaller projects under a bus. Somehow GNOME already seems to support server side decorations for X11 applications btw, so it's not like it's not there at all (might very well be a hack of course).
If we have to do such build-system changes as done here (libdecoration & Meson & D-Bus & Cairo?), just to support Gnome+Wayland, I'd say don't do it and keep using X for until there's a better solution or no other choice.

Rebase & master and update

it appears to be giving the error if there's already a blender shortcut on the desktop, we should probably include the version in the shortcut anyhow given one could install 3.1 and 3.2 side by side.

• adds test for Limited dissolve operator

@Aaron Carlisle (Blendify) sorry it wasn't clear enough, am already working on this...

I will be looking into this and discuss a solution with Cambell and Arnd.

Hi. let me know if I've done this correctly. Will add more test further.

Thanks for logs. It's not entirely sure what is exact cause, but gives me idea how to reproduce.

Think this was indeed never integrated in the automated API doc generation process.... Will look into how to do that locally first, then we can work with @Arnd Marijnissen (Arnd) into integrating it to the buildbot system.

This , at first glance, does not seem to be a buildbot related thing. The files that are produced in the build-steps are being delivered properly.
The remark above was related to the failure of the 3.2-upload process to adapt the 'current' and 'latest' links in docs. That's been fixed.

The building machinery is now fully working then. Thanks for the reporting.

Guess what: the python manual suffers from the same deficiency.

2.93.9 and 2.83.20 are ok too

All my three Windows 10 PC's showed the same error message during installation.

I believe this was intentional, at least temporarily.

I wasn't able to reproduce.

Will raise prio here since this is not a nice thing to have.

I removed the other blender but still got the same error when I tried reinstalling it. However, I can open the program now.

Just thought I'd chime in, I'm having the same problem, I get Warning 1909 when installing Blender 3.2. Also, every time I try to open it, it opens up my K-Cycles instead. Going to uninstall everything and try again.

Even after uninstalling and testing several things with the generated Shortcut Blender.lnk, I can't repro the problem anymore.
Maybe it's related to previous Blender installations?
The problem seems to only happen the first time Blender is installed.

@Germano Cavalcante (mano-wii) i can't locally repro, could you get the log file created by

Thanks for the report, I can confirm.
I will forward it to the responsible team.

Windows 10
Wacom Intuos Tablet

@Ray molenkamp (LazyDodo) missed your poke unfortunately, so ffmpeg for 3.2 with remain unchanged with install_deps... not a big deal anyway I think. Zlib version is not really covert by the script, it just uses the available distro package.

@Jason Klee (sloppyjava) quick ping if you're still available to test the prior build; heads up that we normally close tasks that go without reply for a week.

Hi @Nicholas Rishel (nicholas_rishel) , The new build still has the same problem unfortunately, here's the debug https://developer.blender.org/P2965

@Gabriel Moro (gabrielmoro) I think what happened here is that higher frequency tablet input caused your device to more often leave the "drag threshold" in Blender 3.0; I'm betting the same would happen for you in Blender 2.93 when you set the Tablet API to Windows Ink since Ink supported high frequency input earlier.

@Lillya (Lillya) see above (I accidentally tagged the wrong person. :B )

Could you try this build, and if things are still broken then same instructions as before for getting the log.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

@Jason Klee (sloppyjava) Could you try this build, and if things are still broken then same instructions as before for getting the log.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Fix infinite loop.

possible fix in D14981 but i'm not super thrilled it only fixes things on win10 1903+

still a problem

Linux libs have been updated for master and 3.2, should be included in the next nightly build.

If someone could confirm that this still happens, please classify this as a bug. Otherwise, just closing it will be okay.

here is another without loading previous preferences just in case.

Hope it helps.

Texture paint does lag as you've demonstrated in your video, in Blender 3.2 alpha.
If you resize the UV editor, the Image editor is in Paint mode, and the Texture Paint mode is active: Painting a simple UV
slows down the entire Ui (not responsive). It also seems there's a lag in the way the ram is handled because
when different brushes (line, spacing, etc...) are used, only partial strokes are "painted".

Update: I've tried the latest Blender 3.3 alpha build today, and this issue is still persistent. Texture painting with a tablet is extremely laggy with blender 3.x versions, not usable. Will this be looked into? It is a bit weird that a major issue like this isn't fixed yet since blender 3.0.

I believe this can be marked as resolved. Thank you everyone for working on this.

As OIIO has been updated to 2.3.13.0 in rBL62897 for Blender 3.2, this no longer crashes.

Confirmed. Solved issue in 3.2! Thank you @Brecht Van Lommel (brecht) !
And still impressed on how you tracked it down @Ray molenkamp (LazyDodo) ! :)

In T97737#1357564, @Sybren A. Stüvel (sybren) wrote:

In T97737#1357356, @jean-martin (esox_13) wrote:

With blender-3.2.0-beta+v32.502e1a44b948 : can't even launch blender.

That commit is from the same day as the new libraries were committed. I'm not 100% convinced that the buildbots have picked up on the new libs

In T97737#1357356, @jean-martin (esox_13) wrote:

With blender-3.2.0-beta+v32.502e1a44b948 : can't even launch blender. Terminal output of ./blender --debug-gpu is :

./blender --debug-gpu
[...]
Internal error initializing Python!
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

That has nothing to do with this issue; this happens when Blender can't find Python. It could be due to a missing make install/ninja install step.

As also asked before: please be clear in which Blender you're using. A release name and a Git hash number is a good start, but in this case it doesn't mean much when we don't even know whether it's self-compiled or built by the buildbot.

Alright, 3.2 Beta 502e1a44b948 and 3.3 Alpha 8d9d5da13706, both working great with GPU subdivision enabled + HIP at latest 5.1.2 ROcm drivers

Windows libs have been updated for master and 3.2 , should be included in the next nightly build.