My understanding is that the main problem for developing raster masking with a brush for Darktable is the lack of GPU acceleration in GTK 3?
My question is, why is that not a problem in Gimp (is it just for very big canvases?) and what about GTK 4?
I’ve seen a few demos of GTK 4 where they showcase the performance gain with GTK being GPU accelerated like this demo:
My understanding is that GTK4 now uses Cairo just as a fallback and that all drawing and compositing inside an app is done by talking to the GPU directly via Vulkan?
Does this mean (an I hope it does ) that there will soon be possible to develop a GPU accelerated raster brush masking for Darktable?
What I miss in DT, more that raster masking with brush (drawn mask is more than Ok for me) is the possibility to progressively build opacity in the mask with multiple strokes, what in Capture One is called “flow”.
For example, setting opacity to 50% and flow to 5%, the mask would reach the 50% opacity with 10 ovelapping strokes. That would help a lot the fine local adjustments.
I don’t know if this is possible to implement with the current masking system.
Raster mask with flow control and automatic masking (edge detection) is pretty much the only thing I miss in Darktable… it’d make certain edits so much faster. I wonder what I could do to help make it happen…
Not really. They only exist as raster masks within the pipeline - you can’t save a raster mask within the database/xmp file or generate it with a non-vector-based brush.
Personally, I don’t see a major difference btw a vector and a raster brush. Both are ok to me. Edge detection, maybe, although the mask feathering is already very good and resembles closely the Nik control points.
Flow control is something I really miss as there is no practical replacement.
Maybe it would be possible to implement that with the current vector masks by counting how many shapes cover each pixel of the image, I have no clue
Am I speaking Klingon?
Would GTK 4 enable the development of raster masking brush for DT or not? At least in theory?
Would it be possible and would it work good enough?
I know vkdt is better, but nobody is waiting 10 years for vkdt to replace dt. Like, if that’s the plan, we might as well go use Lightroom or c1 for 10 more years and then reevaluate. And even then, vkdt won’t work for systems w/o GPU so let’s reevaluate in another 10 years.
It’s a huge feature, and thankfully the last one missing (imho). Everything else planned are improvements (and those are great, I thank everyone from the bottom of my heart) but this one is a hole in DT, a black hole, a big blocker for pro users because there is just no way of working around it.
People are trying to answer your question - perhaps it is everyone else who is speaking Klingon. You’ve started off with the assumption that GTK 3 is the problem so GTK 4 must be the solution. But afaik the problems are deeper than that and are about the way in which darktable does its image processing - how the pipeline works and how the modules interact. It’s beyond my skills to suggest whether those problems are surmountable or not but they are not small and mostly unrelated to the GTK version.
Also consider the fact that though darktable does support GPU acceleration it should probably not rely on it and completely hamstring a feature when a supported GPU is absent.
@elstoc Oh, I missed this answer earlier. So basically that’s it?
Idk why but I seem to remember someone telling me that the GTK was the problem and that it would be a non issue (or a lot easier) with Qt. Is that true?
Also what does Gimp do in this case?
That’s what I’m saying, vkdt may be great in 10 years but it doesn’t work without dGPU.
I said once that darktable uses different threads for image processing and for GUI painting. Gtk lives in a separate thread than the pixel filters. For a proper raster painting, you need to cut out the middle man, and do everything on the same thread, on the same CPU/GPU.
Threads are parallel lines of computation. If you need to share data between threads, you need to use locks, which are waiting points. Once all threads have reached that point, data can be transferred between threads, but the slowest one will slow down the fastest, so these thread synchronization really hurt performance.
For a raster painting, the kind of data we need to share is the position, radius and pressure of the brush in the current window. That comes from Xinput or whatever through Gtk.
Having Gtk and dt work both on GPU doesn’t solve the problem that they don’t communicate directly to each other.
I’m still wondering tho… What’s the “plan”? VKDT is an experimental project that won’t be usable for at least 5-10 years and won’t run without dGPU. It can’t be the plan to wait for it to mature and then what? Deppricate Darktable? I’m just asking, what are your thoughts on that?
Is VKDT a sandbox or kind of experimental project for darktable? Will the changes be introduced to dt or vkdt is developed in parallel apart from it’s predecessor?
VTDK is a new project from the creator of darktable, but all the computation is done via vulkan on the GPU. Its pretty barebones right now, but I’m sure once its ready for modules, a few people.will port over quickly.
) that there will soon be possible to develop a GPU accelerated raster brush masking for Darktable? 
