No crashes here (so far). Maybe it has something to do with how often the slider emits a value-changed signal. If it happens too often darktable continues to reprocesses the image...
We had that behavior in the past with gradientsliders. That's the reason why I added timeouts (with g_add_timeout) there. Consequence is that gradientsliders are much more responsive (see parametric masks, or the fill light module). However, there is some drawback: the marker sometimes lags behind the last mouse position if you stop the movement. Ulrich Am 08.01.2015 um 21:40 schrieb johannes hanika: > maybe it has something to do with the gdk lock? not sure it still works > as we remember it from gtk2. if i move sliders a lot, i usually get the > attached crash (independent of slider). > > -jo > > On Fri, Jan 9, 2015 at 9:34 AM, Ulrich Pegelow > <ulrich.pege...@tongareva.de <mailto:ulrich.pege...@tongareva.de>> wrote: > > Hi, > > don't know if this has already been discussed. > > With current master all sliders have an extremely sluggish behavior. > Take a module with some demands in CPU cycles (like shadows & > highlights) and try to quickly move around one of the sliders. It's a > pain to use. In darktable-1.6.x and before sliders have been much more > responsive. > > Ulrich > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ darktable-devel mailing list darktable-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-devel
