Plugins 3 It's working :)

[Patrick Julien]

Reposting to the list.

On February 16, 2004 06:18 pm, Cyrille Berger wrote:
> > > Hello,
> > > So it's working fine now, except that to avoid the problem of static
> > > object that are not accessible from the plugin, I made the following
> > > change to kistilemediator.h :
> >
> > Yes, we will change the singleton instance...  we won't use this
> > technique. Stay tuned....
>
> I don't know if it is related to the "High-level pixel access methods"

No it isn't, I was referring to the way you are getting to the singleton data.  
I've rewritten the creation of the singleton KisTileMediatorSingleton.

> thread, but as far as I have understood it, it's not fit for a filter.
> I think that a filter need to be very fast, and to achieve that goal, it
> needs to manipulate byte and not colors objects. I am thinking about a way

You are correct, the iterator would allow this.  I have no plans on making a 
color object.  The iterator would return (operator* and operator->) the raw 
QUANTUM's just like an ordinary raw buffer.

This can be done with no performance penalty here, not even an extra function 
call.

The only difference is moving the iterator (operator++, operator++(int), etc), 
will make sure you aren't going over a tile, etc and take appropriate action.  
This is something you would need to do anyway, but would be hidden from now 
on.

Finally, to make sure the iterator doesn't prevent someone from really going 
knee deep in pixels... I would like the iterator to expose a few extras like 
a line stride and a tile stride value, this way, you can still operate on a 
tile boundary basis.

I am also thinking of adding something called KisPixelRegion to get the 
iterators from.  This would disambiguate iterator usage.

I can only hope that this soothe your concerns about performance.

> to do filters that use the value of nearby pixels to compute the value of a
> pixel.

The iterator I am thinking about would conform to the random access 
requirements of ISO C++ hence making such usage quite possible.

>
> I think it maybe like this :
> - first we go through the middle of the tile where nearby pixels are in the
> tile
> - then we go through the border, this way it's more efficient, we get the
> nearby tiles only one time

Well, this isn't really more efficient... even if you revisit a tile, it 
doesn't really hurt, it only really hurts the first time since the tile is 
marked copy on write