(no subject)

[Patrick Julien]

On December 22, 2003 05:30 pm, Boudewijn Rempt wrote:
> 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.

Hmm, I don't believe that KMacroCommand would be too slow, oh well, maybe.   I 
would like to investigate this a bit when I come back from vacation.

I would suggest that you reuse the same painter without a pointer in your 
brush tool. Simply call begin/end instead of new and delete.  You have a 
crash in waiting due to how mousePress doesn't reset m_painter to 0 after 
delete.

>
> 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.

You won't get any arguments from me here, the problem is actually about Krita 
actually does refreshes, it just too much work for the developer right now.  
I need to actually sit down and fix this before they are too many tools to 
break :).

>
> 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.

Done.  However. please note that I'm usually more thorough, but I had to do 
this more hastily this time so no finger pointing if it doesn't compile, but 
the strategy is the right one.

>
> 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).

I think you have committed by now.