Mesh Gradients Bugs

This page is to track bugs and feature requests for mesh gradients.

Bugs

Crash: Fill and Stroke dialog: Fixed

Status: Fixed in trunk and 0.92.x.

<houz>	 did anyone manage to reproduce my crash with mesh?
<CRogers>	 I can't, but I don't think I'm using the latest trunk.
* buovjaga has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
<CRogers>	 houz, are you running that pre 0.92 package off the post, or something else?
* Ede_123 has quit (Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/)
* Ede_123 (~Miranda@pacha.physik.uni-konstanz.de) has joined #inkscape-devel
<houz>	 i only use trunk
<su_v>	 houz: IIRC vlada had reported it earlier (for trunk, release builds without debug symbols, might be using Debian, too). Did not reproduce for me on Ubuntu 14.04 (local trunk build as well as the one from PPA) in VM.
<houz>	 thanks. and good to see you back :)
<su_v>	 houz: you did test with default (new) prefs, right? mv ~/.config/inkscape/preferences.xml{,.bkp}; inkscape
<su_v>	 and it's only via button in fill&stroke? adding a mesh gradient with the mesh tool does not crash?
<houz>	 bbl
<houz>	 i tried with the inkscape folder removed, yes
* houz will try to find a mesh tool later, need to make lunch first
<su_v>	 it's in the toolbox on the left ...
<su_v>	 right below the gradient tool icon there
<su_v>	 http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/src/widgets/toolbox.cpp#L1345
<su_v>	 (WITH_MESH is enabled by default in trunk, via WITH_SVG2 cmake option (ON by default))

<houz>	 su_v: using the mesh tool it crashes in the same place
<su_v>	 houz: was Fill&Stroke opened in the current session?
<su_v>	 or rather - is there any relation to having that dialog opened in the current session? (just trying to narrow down possible triggers)
<su_v>	 to test: launch with new prefs, draw rect, switch to mesh tool and click on rect to add mesh (without even opening fill&stroke)
<houz>	 it's opened, yes
<houz>	 let me try
<su_v>	 s/click/double-click/ (to replace solid fill with new mesh)
<houz>	 with clean prefs it doesn't crash when having f&s closed. trying with it open next
<houz>	 crash
<su_v>	 so you can work with the mesh tool in the current session as long as fill&stroke was not opened in the current session?
<houz>	 yes, seems so. even when bringing back my old settings
<su_v>	 what if you create a mesh with mesh tool, save the file, quit, relaunch, open fill&stroke and then reopen the just saved file?
<su_v>	 does selecting an existing object with a mesh gradient also trigger the crash (in a new session, with F&S open)
<houz>	 opening works, but it crashes once i select the object
<houz>	 let me do a clean compile, just to be extra sure
<su_v>	 I wonder whether this could be related to latest gtk3? (presumably you use bleeding edge versions of dependencies)
<su_v>	 ok
<houz>	 no, gtk3 is 3.22.3
<houz>	 (it's the current stable release)
<houz>	 still the same with clean new build
<houz>	 the bt doesn't look like a gtk issue. but that might be me not understanding the problem
<su_v>	 compiler? glib version? newer versions of C++ bindings on distros with latest stable deps? ... I have no idea atm
<su_v>	 but it seems to relate to updating what is displayed in the Fill&Stroke GUI based on the current selection
<houz>	 everything stock debian/sid: gcc 6.2.0, libc is 2.24
<su_v>	 houz: this is the backtrace posted by vlada on 2016-11-08: http://pastebin.com/aafdeQmf
<su_v>	 15:36          vlada_ : Tavmjong, I get crash on creating mesh, either from F&S dialog or from toolbar
<su_v>	 looks pretty much the same to me as the one you posted earlier
<houz>	 yes, it's the same
<houz>	 or at least close
<su_v>	 Ubuntu 14.04 LTS is not really a distro to compare stability of trunk (GTK3 is simply too old there) ... locally, I can test 092x with GTK3/X11 3.18.9 (does not crash) and with GTK3/Quartz 3.20.5 (compiling now). No updated deps (GTK3 3.22) available atm, nor could I compare with local trunk builds.
<su_v>	 you never tested a build based on the stable 0.92.x branch, I guess?
<su_v>	 (it can be compiled with GTK3 like trunk, just requires the cmake define ...)
<Tavmjong>	 su_v: Do you have a debug build?
<su_v>	 Tavmjong: sorry, no recent debug builds here (and no local trunk builds which would reproduce the crash experienced by vlada and houz, either)
<su_v>	 I can check 0.92.x with GTK3 3.20.5, that's about the latest I can get to (as mentioned, I do not trust Ubuntu 14.04 LTS as reliable test environment for latest inkscape trunk due to old versions of all involved dependencies)
<houz>	 no, i never built 0.92.x
<su_v>	 houz: no real need to do so, I guess (expect that it might either produce the same results as with trunk, or further narrow down any possible trigger (changes in trunk))
<Tavmjong>	 Am I correct, that the key thing is that the Fill&Stroke dialog is open?
<houz>	 s/is open/has been open in session/
<houz>	 if i close it and then use mesh in the same session it still crashes
<Tavmjong>	 And only on non-debug builds?

<su_v>	 no crash with autotools-based build of lp:inkscape/0.92.x using GTK3/Quartz 3.20.5 (on OS X 10.7.5) with mesh applied via fill&stroke
<houz>	 i also never made a debug build :)
<buovjaga>	 would be good, if some buildbox supplied daily debug builds
<Mc>	 the ubuntu nightly builds are in Release ?
<su_v>	 AFAIU that's the default with cmake builds (I could be wrong)
<su_v>	  cmake .. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var -DWITH_DBUS=ON -DGMOCK_DIR=/usr/src/gmock
<su_v>	 ^^ from a recent buildlog of trunk PPA
* Ede_123 has quit (Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/)
<su_v>	 hmm (unrelated):  WITH_YAML:               OFF
<su_v>	 so recent features aren't enabled in nightlies, either
<su_v>	 (xverbs)
* Ede_123 (~Miranda@pacha.physik.uni-konstanz.de) has joined #inkscape-devel
* prokoudine (~alex@ppp83-237-247-26.pppoe.mtu-net.ru) has joined #inkscape-devel
<su_v>	 houz: vlada could only reproduce the crash with cmake Release builds, but not with Debug builds

<su_v>	 2016-11-09.log:10:42          vlada_ : Tavmjong, Of course! Debug duild doesn't expose crash. :(
<su_v>	 (inkscape trunk)
<houz>	 let me try a debug build next then
<houz>	 Tavmjong: i think i know what is happening: SPMeshGradient is derived from SPGradient, so the check in src/widgets/paint-selector.cpp:1551 matches the mesh gradient
<houz>	 SP_GRADIENT(server)->	getVector() returns NULL though
<houz>	 i hereby declare that i have no idea why it fails. a short test snippet calling a const member of NULL works fine. why doesn't it here?
<Mc>	 a static const, or just a const ?
<houz>	 http://pastebin.com/bWtVQYCg
<houz>	 ^ that works fine for me
<houz>	 and it's basically what inkscape does. afaict
<houz>	 it migth of course be that there is a compiler bug or some compiler flag that changes it
<houz>	 gcc does warn though: foo.cc:11:5: warning: nonnull argument ‘this’ compared to NULL [-Wnonnull-compare]
<houz>	 even splitting everything into different files and compiling separately to keep the compiler from optimizing things away doesn't crash
<houz>	 ha! when compiling with -O3 it crashes :)
<Mc>	 I think inkscape release compiles with O2
<houz>	 i don't
<houz>	 given that gcc warns about checking for this == NULL i assume that it's undefined behaviour and crashing is fine
<houz>	 and that future gcc releases might be free to crash with O2
<su_v>	 http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/view/head:/CMakeScripts/ConfigCompileFlags.cmake
<su_v>	 O2 for any type of build (unless cmake overrides that?)?
<houz>	 i pass in O3 myself. i did that for years
<houz>	 so it might be that new gcc handles something differently than before
* Ede_123 has quit (Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/)
<houz>	 or i never noticed as none of the features i use trigger that code path?
* Ede_123 (~Miranda@pacha.physik.uni-konstanz.de) has joined #inkscape-devel
<su_v>	 anyone know whether vlada prefers custom CXX flag re optimization, too?
<houz>	 dunno
<su_v>	 houz: so the gist of it would be compiler flags, and possibly changed (default) behavior in recent GCC versions?
<houz>	 interestingly i don't even see a warning about that when compiling inkscape. do you enable warnings at all?
<Mc>	 there are a few warnings when compiling inkscape, mostly deprecated gtk warnings
<su_v>	 for me, cmake builds are very silent wrt warnings, compared to autotools-based builds (but then I'm using legacy clang version, not relevant to anything current)
<houz>	 should i dare adding -Wall? i assume it'll show a shitton of warnings ;)
<Mc>	 I can't test before a few days, but i'd assume that too
<houz>	 su_v: i can't see that ConfigCompileFlags.cmake is used at all
<houz>	 actually, cmake defaults to O3 for me when not being told otherwise :O
* Ede_123 has quit (Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/)
* Ede_123 (~Miranda@pacha.physik.uni-konstanz.de) has joined #inkscape-devel
<su_v>	 hm, appears that in Macports, the default compiler optimization flags enforced in cmake are stripped (among them 03 for releases)
<su_v>	 no idea whether certain distros modify cmake modules, or whether this depends on which cmake version is used
<houz>	 cmake uses different defaults depending on the used compiler
<houz>	 and it certainly differs between cmake versions, too
<houz>	 for me cmake defaults to build type "Release" and uses O3 for that. i am currently building as RelWithDebInfo which should default to O2
<houz>	 build/CMakeCache.txt contains that info
<su_v>	 RELWITHDEBINFO is with -O2, RELEASE with -O3, MINSIZEREL with -Os
<su_v>	 OTOH local 0.92.x cmake build (GTK2) based on tar ball does not crash (with legacy clang) (I did not keep cmake build files for that build, sorry)
<houz>	 i guess someone would have to look at the diff between the two versions. i wouldn't even know how to get that from bzr
<houz>	 and don't intend to learn. i spent too much time with this already
<su_v>	 launching VM to check CMakeCache file in Ubuntu 14.04 for trunk ...
<su_v>	 CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG
<su_v>	 $ gcc --version
<su_v>	 gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
<houz>	 dang, -O2 crashes, too.
<su_v>	 $ cmake --version
<su_v>	 cmake version 2.8.12.2
<houz>	 which makes sense as my test code crashes with anything >	= -O1
<houz>	 i guess the right fix would be to get rid of that strange this == NULL check
<houz>	 and clean up the cmake scripts a bit :-)
* [AD]Turbo has quit ()
<su_v>	 houz: sorry for my ignorance: to test your small example, is it sufficient to compile like this?
<su_v>	  g++ -O3  compiler-opt-1.cpp
<su_v>	 (doesn't crash on Ubuntu 14.04 with './a.out')
<houz>	 yes, should be enough
<houz>	 whai if you add -Wall
<houz>	 ?
<houz>	 does that show a warning?
<su_v>	 no
<su_v>	 su-v@foo:~/local/src/test$ g++ -O3  compiler-opt-1.cpp
<su_v>	 su-v@foo:~/local/src/test$ ./a.out
<su_v>	 0 1
<su_v>	 oh, wait a sec
<houz>	 gcc 4.6 on debian doesn't crash with O3 either
<su_v>	 no
<su_v>	 su-v@foo:~/local/src/test$ g++ -O3 -Wall compiler-opt-1.cpp
<su_v>	 su-v@foo:~/local/src/test$
<houz>	 confirmed, no warning and no crash with old gcc
<houz>	 4.8 works, too
<houz>	 as does 4.9
<houz>	 5.4.1 also works
<houz>	 it's just gcc6 that fails
<houz>	 brb, need to make a tea
* Ede_123 has quit (Quit: Miranda NG! Smaller, Faster, Easier. http://miranda-ng.org/)
* Ede_123 (~Miranda@pacha.physik.uni-konstanz.de) has joined #inkscape-devel
<houz>	 re
<su_v>	 houz: seems you have sufficient "data" as well as available compiler versions to narrow down the issue?
<su_v>	 (which would be great by itself, without a patch at this point :) )
<houz>	 yes, knid of. i think we know pretty good by now what happens: inkscape uses some construct that is not alloed in c++ (according to gcc) and recent gcc decides to warn about it and feels free to break it when using optimizations
<houz>	 educated guess: this may never be null, thus comparing it to null can be optimized away
<houz>	 i would need to look at the assembly code to verify that, but as that's in gcc and we can't change that it doesn't make sense to go that far
* prokoudine___ (~alex@ppp83-237-118-187.pppoe.mtu-net.ru) has joined #inkscape-devel
<su_v>	 Tavmjong: which version of GCC do you use for trunk?
<houz>	 https://stackoverflow.com/questions/1844005/checking-if-this-is-null
<houz>	 time to compile with -Wall :)
* prokoudine has quit (Ping timeout: 260 seconds)
<Tavmjong>	 su_v: GCC 5.3.1
<su_v>	 houz: that matches your findings, right?
<Tavmjong>	 I've haven't had much time today to work on Inkscape. I'll read through all the comments tomorrow and tackle mesh bugs.
<su_v>	 (no crash with GCC < 6)
<houz>	 it does
<Tavmjong>	 I also have GCC 6.2.1 on a new machine... so I can test both.
<Tavmjong>	 (But probably not tonight.)
<houz>	 no worries
<houz>	 we didn't have meshes in inkscape for billions of years, we can wait a few more days :)
<su_v>	 houz: thanks a lot for spending time on investigating this!
<houz>	 you are welcome :)
<houz>	 i can't leave all the bug hunting to you

Crash: Tweak Tool: Fixed

Status: Fixed in trunk and 0.92.x.

<vlada_>	 Tavmjong, I have a crash using gradients
<vlada_>	 meshes, that is
<Tavmjong>	 Backtrace?
<vlada_>	 If I make mesh gradient on an object and switch to tweak tool, color editing operations crash inkscape.
<vlada_>	 Accessing gr->	hrefcount leads to crash
<vlada_>	 Wait... I'll paste somewhere
<vlada_>	 http://pastebin.com/p8HjpjU3
<vlada_>	 Ignore the line 310 of that backtrace. I just tested in gr->	hrefcount is accessible
<vlada_>	 In preferences it is set to fork gradients
<vlada_>	 Tavmjong, You should be seeing this:
<vlada_>	 (gdb) bt
<vlada_>	 #0  0x00007ffff6eb38b8 in sp_gradient_fork_vector_if_necessary(SPGradient*) (gr=0x0)
<vlada_>	     at /home/vlada/CODING/inkscape/src/gradient-chemistry.cpp:311
<Tavmjong>	 vlada_: The tweak_colors_in_gradient will probably need special code to handle meshes. I'll have a look tomorrow.
<vlada_>	 Tavmjong, Thanks. This tool is probably the best candidate for mesh painting. Would be great to have that working...
<vlada_>	 And we need to stop this madness with editing gradient in every possible tool. There is a dedicated one just for that purpose. Unnecessary code complication, nightmare for documenting and much more opportunity to crash app. :)

Crash: Double clicking mesh with Gradient tool: Fixed

Fixed in trunk and 0.92.x.

Sebastian: If you select the gradient tool and double-click a path to devide a row or column, the program crashes.

Crash fixed. Dividing row/column not enabled in Gradient Tool.

Crash: Refit mesh in bounding box: Fixed

Fixed in trunk and 0.92.x.

<su_v>	 Tavmjong: with 0.92.x, two issues with 'Scale mesh to fit bbox':
<su_v>	 A - 2 rows, 1 column: fitting to bbox decreases scale of mesh each time
<su_v>	 steps to reproduce:
<su_v>	 1) launch 0.92.x (default prefs, default new doc)
<su_v>	 2) draw a square
<su_v>	 3) apply mesh with 2 rows, 1 column to square (fill)
<su_v>	 4) click on 'Scale mesh to fit inside bounding box' repeatedly
<su_v>	 -->	 mesh shrinks
<su_v>	 .
<su_v>	 B - >	= 3 rows, fewer columns than rows: fitting to bbox crashes
<su_v>	 steps to reproduce:
<su_v>	 1) launch 0.92.x (default prefs, default new doc)
<su_v>	 2) draw a square
<su_v>	 3) apply mesh with 3 rows, 1 column to square (fill)
<su_v>	 4) click on 'Scale mesh to fit inside bounding box'
<su_v>	 -->	 crash
<su_v>	 backtrace (no debug build, sorry): https://gist.github.com/su-v/9f4b35c4b9cbbe8707a4439a591d9b37
<su_v>	 both issues occur independent of whether there's a real use case to re-fit the mesh (because the geometry was edited) or not.
<su_v>	 on Ubuntu 14.04 LTS, a local trunk build r15250 crashes with both 'steps to reproduce' ...
<su_v>	 (i.e. with 2 rows, 1 column as well as with 3 rows, 1 column)

Memory Leak: Partially Fixed

Status: Partially fixed in trunk and 0.92.x. Not blocker.

<su_v>	 Tavmjong: with meshes using bicubic smoothing, is there possibly a memleak in inkscape? memory usage of 0.92.x build rapidly grows when editing nodes of such meshes (dragging them around). does not happen with Coons smoothing.
<su_v>	 steps:
<su_v>	 1) launch inkscape (default prefs, default new doc)
<su_v>	 2) draw a square
<su_v>	 3) add a mesh e.g. 4 rows x 4 columns
<su_v>	 4) set smoothing to 'Bicubic'
<su_v>	 5) drag a couple of mesh nodes and monitor mem usage of inkscape process

Study

Clearing a mesh array did not delete all SPMeshNodes. This has been fixed.

However, it appears that all gradients leak a small amount of memory. Moving a mesh handle does not appear to leak but moving a mesh corner does as does moving an end handle of a linear gradient.

Incorrect status bar: Fixed

Status: Fixed in trunk and 0.92.x.

prkos (prkos) has assigned this bug to you for Inkscape:

After moving a mesh node to a new position, while still hovering over
it, and sometimes even after moving the pointer away, strange text
(syntax error?) is shown in statusbar:

.+.                     selected out of 12 mesh handles on 1 selected
object

Mesh on the screenshot was created with 6 rows and 6 columns, but is
reproducible in the new document with 1 row/1 column mesh.

Tested on Ubuntu 14.04LTS,  Inkscape 0.92+devel 15229

** Affects: inkscape
     Importance: Undecided
     Assignee: Tavmjong Bah (tavmjong-free)
         Status: New


** Tags: gradient-mesh
-- 
Mesh gradient node/handles statusbar text bug 
https://bugs.launchpad.net/bugs/1641445
You received this bug notification because you are a bug assignee.

Handles not updated: Fixed

Status: Fixed in trunk and 0.92.x.

<su_v>	 minor issue when moving selected mesh nodes with keyboard (arrow keys): one of the nodes (last in selection, or first?) leaves handles in original position. display of handlees gets out-of-sync until mesh is deselected and reselected again.

Inserting row/column with double click: Fixed

Status: Fixed in trunk and 0.92.x.

<su_v>	 Tavmjong: also: Ctrl+Double-click still works ok with latest (without selecting any nodes prior to double-click)
<su_v>	 not sure if that's just a coincidence or a (re-)defined mouse handler
<su_v>	 Ctrl+double-click adds new row/column 100% for me (at the point the mesh line was double-clicked).
...
<Tavmjong>	 su_v: Hmm, it is also suppose to work without the Ctrl... but I guess as long as Ctrl works I'm not going to worry about it.

Sebastian: To devide a row or column through a double-click requires at least one corner node to be selected. This is an unnecessary restriction and should be lifted.

Study

Bug introduced in previous commit fixed. Mouse handling logic switched around to also handle corner node selection as with node tool.

Alt-B doesn't work

Status: Not a blocker. Under study.

Sebastian: The shortcut Alt+B to toggle the selected sides doesn't seem to work.

Alt-B does work if adjacent corner nodes are selected. If nodes are not selected,then if falls back to creating a bitmap image. Probably would best be fixed by making sure nodes are still selected after an Alt-B.

Snapping/Preserving Angle: Fixed

Status: Fixed. Removed from trunk and 0.92.x.

Sebastian: The status message says that Ctrl allows to snap the angle and Ctrl+Alt to preserve the angle while editing the mesh (like within other tools), though they don't work.

Study

These are unimplemented features. Not clear what they should actually do.

Scaling with Ctrl-Shift: Fixed

Status: Fixed: Disabled in trunk and 0.92.x.

  The status message says that Ctrl+Shift allows to scale around a center, though this doesn't apply to mesh gradients, or does it?

Study

This is an unimplemented feature.

Feature Requests