On October 11, 2003 04:55 am, Boudewijn Rempt wrote:
> 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.

Yes, in that case, thise is a new image and you're leaking all that memory.  
So, you actually have to use memcpy to copy the bytes from the new image to 
the KisPixelData.

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

_______________________________________________
kimageshop mailing list
kimageshop@mail.kde.org
http://mail.kde.org/mailman/listinfo/kimageshop