That time of the day again...

[Boudewijn Rempt]

On Saturday 11 October 2003 02:18, Patrick Julien wrote:

> Actually, again, the pointer is already set to the same address, i.e. the
> image we're initialize with pd -> data, don't forget you newup pd -> data,
> KisPixelData dtor will delete it correctly, but this makes your intent
> harder to understand.  It doesn't put them back after all, it's exactly the
> same buffer you passed in to QImage in the constructor call...

I was wondering about that, because when I remove a similar line from code I 
posted earlier, nothing seems to happen -- the QImage that 
QPixmap.convertToImage() returns is a different thing than the QImage I 
started out with, it seems.

Anyway, what I wanted was to have a KisPaintDevice subclass (and I choose 
KisLayer after an abortive attempt at a KisDab) that I can use to give to the 
KisPainter bitBlt methods, for instance:

void bitBlt(Q_INT32 dx, Q_INT32 dy, 
            CompositeOp op, KisPaintDeviceSP src,
            QUANTUM opacity, 
            Q_INT32 sx = 0, Q_INT32 sy = 0, 
            Q_INT32 sw = -1, Q_INT32 sh = -1);

That way the existing bitblt functions can handle the various kinds of 
compositing and opacities, and also the undo/redo. That's necessary because 
every kind of brush or penwork should be possible with every kind of 
compositing. Having the compositing/tile walking code in one place seemed 
like a good idea to me.

So somewhere I need to create that layer. Perhaps the order should be:

determine the rect that is painted upon
create a transparent pixmap
do the brushwork
get the image from the pixmap
create the layer with that image
bitBlt the layer onto the KisPaintDevice we where painting on.

My first take was to grab the rect from the KisPaintDevice with all the 
existing pixels in, convert that to a QPixmap, draw on it, and push it back. 
I've got that working nicely now, except that if I create a transparent layer 
and draw on that, things go horribly wrong. I have a nagging suspicion that 
QPixmap is a bad choice for a transparent paint device.

Maybe I should drop the idea of hijacking QPainter, and investigate some other 
lib that offers graphics primitives, or even (shudder!) try to code them 
myself. I was hoping, though, that getting most of the back to working would 
entice other, better, hackers to Krita and get them to do that code :-).

I'll have one last attempt this morning at getting the temporary layer idea 
working; if that fails I'll just implement temporary code following the old 
scheme for all tools and get those tools working again.

-- 
Boudewijn Rempt | http://www.valdyas.org/index2.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: signature
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20031011/d80bebfc/attachment-0001.bin