After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760628 - Need a way for meta operations to know the bounding box of the input
Need a way for meta operations to know the bounding box of the input
Status: RESOLVED FIXED
Product: GEGL
Classification: Other
Component: core
git master
Other All
: Normal enhancement
: ---
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on:
Blocks:
 
 
Reported: 2016-01-14 16:05 UTC by Debarshi Ray
Modified: 2016-01-23 13:36 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
operations/common/load: Remove unused prepare implementation (1.64 KB, patch)
2016-01-14 16:06 UTC, Debarshi Ray 		committed Details | Review
process: Call prepare for meta-ops (1.25 KB, patch)
2016-01-14 16:07 UTC, Debarshi Ray 		none Details | Review
process: Call prepare for meta-ops (1.32 KB, patch)
2016-01-23 13:16 UTC, Debarshi Ray 		committed Details | Review

Description Debarshi Ray 2016-01-14 16:05:06 UTC 
I have a meta-operation that composites a custom shadow/gradient over an input image. The meta-operation needs to know the bounding box of the input so that it can place the shadow/gradient over it and crop it around the edges. I expect to do this by setting the relevant co-ordinates on the shadow/gradient operation by looking at the input bounding box.

Unfortunately, the prepare vfunc is not called for meta-operations. Therefore there is no good place to set the properties of the child operation.

One workaround would be to copy/paste the compositor logic (ie. gegl:over, etc.) into the shadow/gradient operation and use relative co-ordinates instead. This is what gegl:vignette does.

However, this is limiting because I can no longer mix and match different shadow/gradient operations with compositors easily.
Comment 1 Debarshi Ray 2016-01-14 16:06:36 UTC 
Created attachment 319014 [details] [review]
operations/common/load: Remove unused prepare implementation
Comment 2 Debarshi Ray 2016-01-14 16:07:17 UTC 
Created attachment 319015 [details] [review]
process: Call prepare for meta-ops
Comment 3 Debarshi Ray 2016-01-14 16:23:09 UTC 
(In reply to Debarshi Ray from comment #2)
> Created attachment 319015 [details] [review] [review]
> process: Call prepare for meta-ops

One sticking point with this approach is the locking.

It is not clear to me what the GeglNode mutex is supposed to guard. As far as I can tell it guards the cache and its extents. If we lock the parent, then we will get into a deadlock if the parent's prepare function changes the properties of the child operations because that will cause the whole graph to be re-prepared and we will try to lock the mutex again.

Maybe the answer is to use a recursive mutex? I don't know.
Comment 4 Debarshi Ray 2016-01-19 09:04:20 UTC 
Comment on attachment 319014 [details] [review]
operations/common/load: Remove unused prepare implementation

I pushed this one because it's just dead code removal. It doesn't really change anything.
Comment 5 Debarshi Ray 2016-01-23 13:16:06 UTC 
Created attachment 319588 [details] [review]
process: Call prepare for meta-ops

Bubble the prepare call upwards if there are nested meta-ops.