On October 8, 2003 02:51 pm, Boudewijn Rempt wrote:
> Passing lightly over the issue of debug commands -- one thing at a time --
> is this right way of painting? I mean, is it necessary to first 'anchor',
> then 'invalidate', then 'updateCanvas' to have the change show up on
> screen?

nope.

>
>    KisImageSP img = m_view -> currentImg();
>     if (img) {
>         KisPaintDeviceSP device = img -> activeDevice();
>         if (device) {
>             KisPainter *p = new KisPainter();
>             p->begin(device);
>             p->fillRect( x,  y,  10,  10,  KoColor(QColor( "red" )) );
>             p->end();
>             device->anchor();
>          }
>     }
>     img -> invalidate(QRect( x,  y,  10,  10 ));
>     m_view -> updateCanvas(x,  y,  10,  10);

ok, there are several issues with this code, 

1) invalidate will not do anything here.
2) updateCanvas is indeed needed to force the image update
3) You have absolutely no reason to put KisPainter on the heap...

just 
	KisPainter gc(device);

	gc.fillRect(x,  y,  10,  10,  KoColor::red);

and you are done.  End() is called by the destructor.

You get the right behavior and you don't leak that memory either.  Look at the 
documentation for boost::shared_ptr, boost::scoped_ptr and KSharedPtr.  I 
work on a massive application, bigger than all of koffice, for my day job and 
we use smart pointers everywhere, guess what?  We don't use delete, yet tools 
like purify can't find leaks in our code proper and the performance 
difference is benign.

Actually, there is more than that, you need to be able to support undo/redo 
too, right?  So you need to start and end a transaction to get back a 
KCommand that you can enqueue.

>
> (By the way, in the funny bugs department, and just for the record: if I
> run krita remotely, on my AMD box, export the display to my Powerbook, then
> the image will show up as black, and I get xshm errors on the output. I
> hope to compile Krita on the powerbook some time soon to check for
> endianness, but I don't think this is an endiannes problem.)

This is actually a remote KImageIO issue isn't it?  If you run krita on a 
remote display even on a X86, you need an up too date KImageIO otherwise the 
display is broken.


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