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