Still got time to build it and repeat the delete layer test case and I confirm it works now, thanks.
As for the warning, it still shows now and then
(photoflow:15587): Gdk-WARNING **: 08:18:09.017: gdk_window_set_icon_list: icons too large
Later on I’ll do more edits.
EDIT: I completed an edit of the dreamy creek play raw without a crash. It’s very fast. The only thing noticeable happened when I inserted a film emulation layer in the middle of the pipe and chose a film: it took some time to process, at a very high cpu rate. Different from all other layers I manipulated.
This is exactly the kind of thing that the code in the improved-pipeline branch will solve once merged, that is to provide a correct and meaningful default input to all layers (including mask layers).
Good to know. Although the fixes I introduced for the crash upon layer deletion should have no impact on the other crashes that occur when moving sliders very fast. If that happen again, please let me know and provide logs if possible…
Glad to know the processing is getting faster with the new code!
The first time a film emulation preset is used, GMIC has to load and decompress the CLUT from disk, and this step takes a bit of time. However this is only executed once, and the processing should be much faster afterwards. Is that the case?
Now I’m trying to edit this play raw but the computer is swapping again and completely freezing, so I don’t have a way to send you anything.
I tried using valgrind the way you mentioned above, but it takes forever to do the initial rendering.
The steps I took before freezing:
Opened the raw
Added a scale layer to fix the angle
Back to the raw dev layer, I set highlights recovery to blend,
then I switched to the advanced tab, and pushed the white level to around 55,000.
Back to the input tab, I started tweaking with the exposure slider and, at that point, ram was filling up and swapping began, forcing me to reboot.
Look at the green indicator, at the top, which is ram usage (screenshot after completing step 4 above)
Confirmed. Moving the exposure slider without any additional layer already increases the memory. There is a big memory leak somewhere, I will look at this later today.
There was an important memory leak in the demosaicing phase, which got amplified by the recent changes in the processing pipeline. It should be completely fixed now.
I could reproduce the odd behavior and I started to look into it, but I do not have a fix yet. Hopefully tomorrow…
@afre indeed the win64 builds are failing, apparently due to some changes in the MSYS2 pugixml package. I am looking into this right now, more news ASAP…
I was just tweaking white level and exposure/blend.
EDIT: Maybe something is different, because after the rampant ram and swap usage (and some good seconds of freezing), the program gets responsive again, but in a more slow pace. Before your fix, once the computer froze, only a hard reset to eliminate it.
Does the RAM/swap increase happen before or after you start tweaking the sliders? How much ram do you have? The software should use a bit more than 1GB of memory, constant over time…
So PhF is taking 8 GB? That’s really too much… could you send me the specific raw developer settings that eat so much memory?
Are you using Amaze or something else? Anything activated in the corrections tab?
I just opened the image, set a white spot for wb, then started tweaking with white level (forth and back a couple of times), then increased exposure, then get back to while level and do some forth and back slidings, that’s all. I didn’t tweak anything else.
As for the available ram, now that phf is closed, I have this:
So, except for swap, that would be more or less the available ram I had at the time I started phf.
It has been bothering for a long time. Thanks 
