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 760372 - Multitreaded compositing errors
Multitreaded compositing errors
Status: RESOLVED FIXED
Product: GEGL
Classification: Other
Component: operations
git master
Other Linux
: Normal normal
: ---
Assigned To: Default Gegl Component Owner
Default Gegl Component Owner
Depends on:
Blocks:
 
 
Reported: 2016-01-09 18:58 UTC by Jonathan Tait
Modified: 2016-02-24 08:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
quick hack (2.05 KB, patch)
2016-01-09 19:33 UTC, Massimo
none Details | Review

Description Jonathan Tait 2016-01-09 18:58:40 UTC
Steps: 
- start GIMP with --gegl-threads=4
- open-as-layers 2 or more opaque images (or create an image with 2+ opaque layers)
- use the Move Tool to move the layers around and/or downscale the layers using Layer > Scale Layer

Result:
 the canvas area outside the uppermost layer is not composited correctly, mostly black. 

Further:
- the black areas in the mis-composition are often aligned with GEGL tiles;
- this problem does not happen using the transform tools;
- if you add alpha channel to *all* the layers the image is then composited correctly;
- this is not just a display-shell problem - duplicating the image or creating a new view of the same image shows much the same mis-composition, and the same thing happens when the image is created/manipulated programmatically from Python or Script-Fu console (without being displayed).

This seems to be a general problem with the way GIMP+GEGL deal with non-aligned, non-alpha layers. (The transform tools automatically add alpha channel and so do not elicit the problem.)

Note: just noticed this also happens on a build of Otto's gimp-edge from commit 9cc634e which was dated 2015-11-21, so this is not due to a change made in the last few weeks.
Comment 1 Massimo 2016-01-09 19:33:09 UTC
Created attachment 318599 [details] [review]
quick hack

Yes it was a problem that I reported on IRC.

IIRC in the attempt to force each thread to convert
from the buffer babl_format to the layer-mode babl_format
(that is maximize the work done by each thread)
the main thread reads the buffer data in its format, 
unfortunately this means that, for opaque layers, pixels
outside layer boundaries are opaque black instead of
transparent.

The attached patch forces the conversion in the main
thread, defeating the advantage of multi-threading

You can benchmark projection times with

File->Debug->Benchmark projection
Comment 2 Øyvind Kolås (pippin) 2016-02-24 08:09:16 UTC
commit 32949ae63ed2f1361782d8088a277f854603865c
Author: Massimo Valentini <mvalentini@src.gnome.org>
Date:   Sat Jan 9 20:07:32 2016 +0100

    point-coposer3: skip some multi-threading for opaque buffers
    
    Patch from:
      https://bugzilla.gnome.org/show_bug.cgi?id=760372