Bug fix: Handling of alpha pixels when committing selection #840
Conversation
|
Spurious build failure for |
Pinta.Core/Classes/Document.cs
Outdated
| @@ -211,8 +211,7 @@ public void FinishSelection () | |||
| Layer layer = Layers.SelectionLayer; | |||
|
|
|||
| var g = new Cairo.Context (Layers.CurrentUserLayer.Surface); | |||
| selection.Clip (g); | |||
| layer.Draw (g); | |||
| layer.DrawWithoutOpacityProcessing (g, selection); | |||
There was a problem hiding this comment.
I think it might also work to use DrawWithOperator() with the Cairo.Operator.Source operator, but please test!
That would avoid having multiple draw passes since it just replaces whatever pixels are within the clip area.
There was a problem hiding this comment.
Okay, yeah, I'm not at all familiar with Cairo and didn't know how to find exactly that operation. I'll give it a go :-)
There was a problem hiding this comment.
Hmm, when I use DrawWithOperator it completely replaces the target layer, erasing everything that isn't in the selection area. I tried calling AppendPath(SelectionPath) but it still does that. I don't see anything else on Context dealing with paths, not sure what else to try.
There was a problem hiding this comment.
I'd also try restoring the original selection.Clip() call beforehand as well, if you weren't already
There was a problem hiding this comment.
I'll give that a go :-) Thanks
logiclrd
force-pushed
the
JDG_FinishSelectionAlphaHandling
branch
2 times, most recently
from
33717ed
to
523bf25
Compare
…ce the use of Operator.Source when committing the selection layer. Added overload of DrawWithOperator that supplies ImageSurface implicitly.
logiclrd
force-pushed
the
JDG_FinishSelectionAlphaHandling
branch
from
523bf25
to
19f57b6
Compare
|
Rebased. |
|
Looks good, thank you! |
When you finish a selection with pixels that aren't fully-opaque (whether due to layer opacity or the pixels' alpha channel), those pixels are blended with the target layer according to the opacity, but this is not the proper semantic for a selection. If you create a selection and then use Move Selection tool to relocate it, within that layer, the pixels' opacity should simply be translated along with the colour. This PR fixes selection moves so that when the selection is "dropped" onto the underlying layer, it simply replaces all of the pixels involved. It implements this by still blending the pixels the way it did before, but by clearing the underlying pixels so that there's nothing there for them to blend with. The new blend method ignores the layer opacity as well.
There is a separate bug in how the selection layer is previewed. Prior to finishing the selection, it will appear incorrectly blended with the underlying pixels. That is outside of the scope of this PR.
Before moving selection:
After moving selection, before finish selection:
After finishing selection:
This PR partially fixes #819.