Painting on a temporary layer
Bart Coppens
kde at bartcoppens.be
Sun Sep 26 16:59:29 CEST 2004
Quoting Boudewijn Rempt <boud at valdyas.org>:
> Have you tried special casing it in renderToProjection in KisImage? Make the
> temp layer a property of KisImage, and check whether it exists, if it does,
> paint it after the right layer.
I thought about it, but I think there are too many objections to this
approach: it doesn't really belong in KisImage, I'd probably have to remove it
again later if I can use the undo as source, etc. Also, we'd be working around
the problem instead of fixing it, because I think the current behaviour is
wrong.
> Bummer, is, I believe, the technical term. Now there's reason enough to make
> the undo and pre-undo information available in a nice API, because we're
> going to have to do that for a Karbon-like history docker tab but with
> previews....
That's indeed a good idea, but after looking at kis_tile_command, I think this
could get more difficult than I thought. The undo information is efficiently
stored in an std::map object, so getting it back to use as a source for
painting or making previews might be a challenge...
As you might have seen, I committed an updated version of kis_tool_freehand.cc
This version implements the 'fix' I mentioned in my last mail. To test out
this code, you only have to uncomment the
setUseTempLayer( true );
lines in kis_tool_filter.cc and in kis_tool_duplicate.cc The only thing that
doesn't quite work the way I expected is the duplicate tool: it appears a bit
'jumpy', but I have no idea why.
Bart Coppens
More information about the kimageshop
mailing list