Finishing a paint action.

[Patrick Julien]

Hold on a minute there fella :)

On October 9, 2003 08:58 am, Boudewijn Rempt wrote:
> On Thursday 09 October 2003 01:12, Patrick Julien wrote:
> > 1) invalidate will not do anything here.
>
> But if it's not there, nothing shows up on screen -- even though it is
> present in the image data. If it's there, painting works as it should.

My memory fails me, I don't believe I had to do this, but I have not touch 
Krita since last xmas.

>
> I've added a temporary drawPolyline (to be replaced with something a little
> more intelligent that also supports undo/redo, colour strategies and raster
> operations) to KisPainter now:
>
> void KisPainter::drawPolyline(const QPointArray& polyline)
> {
>     QRect r = polyline.boundingRect();
>     r = r.normalize();
>
>     KisTileMgrSP tileMgr =  m_device -> data();
>
>     KisPixelDataSP pd = new KisPixelData;
>     QImage img;
>
>     pd -> mgr = 0;
>     pd -> tile = 0;
>     pd -> mode = TILEMODE_READ;
>     pd -> x1 = r.x();
>     pd -> x2 = r.x() + r.width() -1;
>     pd -> y1 = r.y();
>     pd -> y2 = r.y() + r.height() - 1;
>     pd -> width = pd -> x2 - pd -> x1 + 1;
>     pd -> height = pd -> y2 - pd -> y1 + 1;
>     pd -> depth = tileMgr -> depth();
>     pd -> stride = pd -> depth * pd -> width;
>     pd -> owner = false;
>     // XXX: this assumes RGBA.
>     pd -> data = new QUANTUM[pd->width * pd->height * 4];

Use KisTileMgr::pixelData to get back a correctly initialized, correctly 
depth, non RGB assuming pixel area :)

>
>     tileMgr -> readPixelData(pd);
>     img = QImage(pd -> data,
>                  pd -> width, pd -> height,
>                  pd -> depth * CHAR_BIT,
>                  0, 0,
>                  QImage::LittleEndian);

I see you looked at the color space code :)

>
>
>     QPixmap buffer = QPixmap( img );
>
>     QPainter p;
>     p.begin(&buffer);
>     p.translate( -r.x(),  -r.y() );
>     p.drawPolyline( polyline );
>     p.end();
>
>     img = buffer.convertToImage();
>     pd-> data = img.bits();

pd-> data = img.bits();

This is not necessary since the image is actually writting to the pixel data 
QUANTUM array already.

>
>     tileMgr->writePixelData( pd );



> }
>
> And that works... After a fashion, and is not too slow. I'll add more

yeah, well try it on a large enough image, it should slow down pretty well :)  
In any case, good work.

> operations on this line, after all, once the tools work again, it's easy
> to replace this code with intelligent code operation for operation.
>
> One idea would be to replace
>
>     pd-> data = img.bits();
>     tileMgr->writePixelData( pd );
>
> With code that does to a QImage what the image-magick based builder does;
> create the necessary KisPaintDevice and blit that to the image; that would

That would be even slower.  If you want speed, you need to use the tiles 
directly.  You can actually support undo/redo with what you have here too...  
you just need to set the COW flags of the tiles before using them.

> support undo/redo and raster ops one go, even if it would be horribly
> inefficient. But as long as I haven't finished reading Newman & Sproul,
> Hearn & Baker and Foley & van Dam, I don't feel up to coding tile-aware
> graphics primitives myself.

Yeah, if only they we're 48 hours in a day :)