(no subject)

[Boudewijn Rempt]

On Saturday 13 December 2003 21:51, Patrick Julien wrote:
>
> Well, yes, that is expected behavior.  I believe what you want to it keep
> your painter on the member list of your class... you begin() the painter on
> mousePress (or key, whatever) and end() on release.

I don't see how this can work... 

There is no way a single KisTileCommand can be reused from more than one call 
to bitBlt. If there is no transaction defined, then end() return 
endTransaction(), which, if there's no transaction, returns 0; if there is a 
transaction defined, every call to bitBlt creates a new KisTileCommand which 
is added to the transaction.

A transaction is a KMacroCommand or nothing; but a KMacroCommand isn't useful, 
because it is so slow in replaying/rewinding.

But a KisTileCommand is valid only for a specific rectangle, and notifies the 
image on that initially set rectangle only, but doesn't check whether all its 
tiles are inside that rectangle. If the rectangle could grow while adding 
tiles, it could hold changes all over the place, without adding memory 
constraints.

If you want to code a freehand paint function, it is impossible to move 
everything to KisPainter -- the tool will have to repeat issue fresh calls 
for every mouse movement/pen move, and those calls will have to be 
consolidated into a transaction.

So I think that it's necessary to have a transaction type in KisPainter that 
is purely tile based; that is, between beginTransaction() and 
endTransaction(), tiles are added to KisTileCommand, instead of 
KisTileCommands to a KMacroCommand. And then the KisTileCommand must update 
its rect based upon the normalized rectangle of all the tiles it contains. 

I've hacked KisPainter to support the kind of tile-consolidating transaction
I mean, instead of macro-like transactions, and undo/redo is now instant, of
course, and everything else still seems to work. I did have a problem, though: 
I couldn't figure out how to keep KisTileCommand local to the namespace of 
kis_painter.cc, and still declare m_transaction in kis_painter.h to be of 
type KisTileCommand, so I had to place the declaration of KisTileCommand in t 
kis_painter.h. No doubt someone with more knowledge of C++ knows how to do 
this correctly, but the only other option I could find was to dynamic cast
KCommand to KisTileCommand whenever I needed the addTile method.

Anyway, because of this, and because I have a precognition that I might have
missed something important, I've just attached the diff instead of blithely 
committing. (I've also removed the QPainter based methods I did in September 
or so, when I was learning Krita -- those were obsolete).

-- 
Boudewijn Rempt | http://www.valdyas.org/index2.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: krita_undo_redo.diff
Type: text/x-diff
Size: 17416 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20031222/a2251340/krita_undo_redo-0001.bin