Skip to content

Fix wire contention for gradient data

Lloyd Konneker requested to merge bootchk/gimp:gradientDataLocal into master

Fixes #10536 (closed) which was reported after this MR was created (for the issue discussed below, never formally reported.)

There are two separate commits, two separate fixes, both of which contribute to "Fractal Explorer fails using the gradient chooser."

Jehan:

Gimp still suffers the ill you identified in 66a05c88: interference between concurrent PDB calls between core and a plugin, usually for getting a gradient.

The test case is SF>Test>Sphere. When you choose a gradient, then close, you sometimes see the same symptoms, errors that a GValue is not a GBoolean.

In this MR, I fix it for gradient by caching the gradient data on the libgimp side, instead of continually (at every draw) crossing the wire to core.

!!! Note this restores the original concept, which I deleted in commit d59a7af3 . See the incorrect comments in gimp_gradient_select_preview_size_allocate(), in master before this MR. You could also look at the original, before d59a7af3.

This is draft, don't review for style.

If you approve, I might need to do the same thing for brush, etc. I haven't seen the need yet, but maybe just lucky.

Note there is another issue (I will report it soon) that might prevent testing this issue. A reffing problem in gimp_resource_chooser.

Re a more general fix to the wire protocol. Re locking, I see the nested dolls complication that you mentioned. I have another nebulous idea: two pairs of pipes (instead of one pair) one pair for core initiated transactions and another for plugin initiated transactions. In other words, two bidirectional comm channels. That seems costly, but at least it could be a general solution and we wouldn't need your prior fix and fixes like this one. Code spread throughout Gimp that requires a long explanation.

Edited by Lloyd Konneker

Merge request reports