koffice/krita/ui/tests

[Boudewijn Rempt]

On Tuesday 22 June 2010, Marc wrote:
> > > > > I don't know how to fix it as it seems to depend on Qt's QUndoStack
> > > > > much. So i just wrote the test for the problem. What do you think
> > > > > about it?
> > > > 
> > > > I don't know how to fix it either. Maybe we can find a way to make
> > > > the transform tool be able to coalesce many changes without messing
> > > > with the undo
> > > > stack, that was always very unstable.
> > > 
> > > Yeah, that would be the best solution. Speaking truly, i'd like
> > > transform tool to work in overlay(?). Like "Line" and "Rectangle"
> > > tools. And commit to undo stack then.
> > 
> > Well, I want to have direct preview of the actual transformed pixels, but
> > I am fine with copying the selected pixels to a QImage and transforming
> > and showing that on top of the layer stack. A bit like the hack pippin
> > discussed for gegl on irc.
> 
> I thought about something like this. That would be quite convenient
> because we wouldn't have to blit rectangles into others during the use
> of the tool : we could apply the transformations directly to the temp
> paintDevice.

Actually, I'd say: don't use a paint device. Use a QImage projection of the 
active, selected pixels at the current zoom level. Paint that in the tool 
decoration painting phase (KoTool::paint(), perhaps using transparency to make 
clear that it's a temporary.

> 
> > > Btw, do incremental transformations lower the quality?
> > 
> > No: all transforms are collected in one transformation and that is done
> > on the original image after the user is done with the tool.
> 
> It's supposed to be how boud says eventually, but for now it works
> differently. Incremental transformations do not lower the quality,
> because at the activation of the tool, we make a copy of the original
> state, and we always apply the transformation from this state. Actually,
> all the transformations you do are reduced to a composition of 1
> translation, 1 scale, 1 rotation, 1 shearing, even if you get the
> impression that we compose transformations one after another :) (only 1
> call to the transform worker).
> The problem with this is that we have to restore the original state (the
> pixels paintdevice and the selection paintdevice) each time ! That's
> what's making it slow. A possible solution is the hack proposed by boud
> just below.
> 
> Btw, while it will still be possible to reduce the transformations to 1
> transformation with shearing, perspective, and rotation around a
> changing center (for now you can see that the center is always the
> same), it won't be the case with warping.
> That means we can't afford to go back the original state for each
> transformation, because it'll take too much time applying ALL the
> transformations from the beginning.

Good points. I think allowing the temporary to degrade while operations are 
being added is ok; then we can coalesce all operations into the minimum 
possible, act on the original layer, remove the temporary and update the image
for real.

> 
> > > Maybe we can do something using the tool activation/deactivation (or a
> > > timer
> > > 
> > > > with a pause) that commits the complete transform in one action.
> > > 
> > > Timer :(. I'm afraid we will end up with the same undo stack signals. I
> > > think we need a button (big and red! :) ) that will end transformation,
> > > commit it into the stack and remove "hands" from the canvas. After
> > > pressing this button, editing of the previous transformation will not
> > > be possible.
> > 
> > No, I wouldn't go for the big button. Other apps manage to work without a
> > big button, we must be able to find a way to do this right as well.
> 
> I don't know about that either, but that's the way photoshop's transform
> tool works : it creates a temporary copy of the selection, then the user
> can work directly on this copy, which is degraded for each
> transformation. When the user pushes a validation button, all the
> transformations are reduced and applied to the original selection (to
> have as little degradation as possible°

Ok, then I'm fine with a commit button as well, same as with crop (commit, 
enter, double click: commits, esc, cancels)

-- 
Boudewijn Rempt | http://www.valdyas.org