Plugins for Krita

[Patrick Julien]

On February 9, 2004 05:30 pm, Cyrille Berger wrote:
> Hello,

2 new people getting involved in Krita, well 3 if you count Boudewijn, I just 
can't believe it :)

There are actually a number of problems with this plug-in, let me enumerate 
them here before I answer your questions

1) Use of value 255.  Use QUANTUM_MAX.  Krita is not restricted to 8 bit color 
channels.
2) Assumption of 3 primary color channels.  Again, Krita is not limited to 
RGB, pretty much any color model can be adopted with a corresponding color 
strategy, see core/color_strategy.
3) Not checking for events.  Until we have a pipeline where you a simply 
queuing concrete commands to a worker thread.  The application will look 
frozen when this is going on.  Not much of a problem on small image, but on a 
moderate size one, Krita will just hang there while this executes.  Even with 
a worker thread, this would need to access the data on a tile boundary so 
that you can lock the tiles you are working on right now.

Avoid the use of malloc/free in a C++ program.  Here, the array is not 
necessary, but if it we're, you could have easily done...

std::vector<QUANTUM> buffer;

buffer.resize(w * h * d * sizeof(QUANTUM));

Another way would be using boost::shared_array.

Then, you use buffer exactly that same way your using right now.

>
> I have been playing with krita for sometime. And I have wrotten a simple
> plugin which may be use as an example, it invert the color of an image. It
> is very basic, so it may be used as an example.
> I think I will do some more image filters, but first I would like to have
> your opinion concerning the speed of my plugin. Maybe there is a faster
> way, because when I do a "readPixelData" and then a "writePixelData", I
> copy the image twice, which is totaly useless. Maybe there is a way to

Yeah, these definitely need to be private, and I have do so, they induce 
people in error.

> access directly to the image data ?

See KisPainter::fillRect() for a simple example.   You have to access the data 
on a tile boundary.

> And I was wondering, how does the undo interface work ?

You mean KisUndoAdapter or the actual undo mechanism?

KisUndoAdapter is inherited privately from KisDocument (see Extension 
Interface design pattern).  The implemention queues the concrete KCommands to 
KCommandList that is setup by KoDocument.

The undo mechanism is to mark tiles copy-on-write.  KisTileCommand is a 
concrete KCommand that pretty much takes all the work you have to do for 
undo.  The only remainding responsibility on the part of the coder is too add 
tiles to the command.


> In an ideal world, it would be best, if I could point the current data into
> the undo stack, and then draw on the image. Is there a way to do this ?

Yes, this is what the drawing operations do in KisPainter.

>
> I don't know how to do a diff, so I send the complete file, anyway, there
> is nothing left from the old code of the plugin example.
> You just have to delete the content of plugins/example, autoconf and then
> configure, make and make install. And it should work, if it doesn't, let me
> know.

Again, I'm taken aback by the enthusiasm lately in Krita by you and other 
people.  I look forward to seeing your code in Krita.