On 2010-03-19 at 10:53:07 [+0100], Stefano Ceccherini <stefano.ceccherini@xxxxxxxxx> wrote: > 2010/3/19 Stephan Assmus <superstippi@xxxxxx>: > > > > On 2010-03-19 at 10:44:31 [+0100], Stefano Ceccherini > > <stefano.ceccherini@xxxxxxxxx> wrote: > >> 2010/3/18 Stephan Assmus <superstippi@xxxxxx>: > >> > >> > Yes, it should be only used in ServerPicture, since it's a local class > >> > in > >> > that file. But it's main purpose seems to be to iterate an existing > >> > BShape > >> > to copy all it's data, and then draw this shape with the appropriate > >> > view > >> > to screen transformation. So it seems to be an expensive way to > >> > memcpy() > >> > the shape data and apply the transformation on the point data. But > >> > since > >> > the transformation is no longer necessary, I believe it can be thrown > >> > out. > >> > > >> > >> Another thing it can be used for: > >> Iterate on a BShape to construct its containing rectangle, without > >> drawing > >> it. > >> At least, I can see uses of it. > > > > BShape has a Bounds() method that does exactly that. At the moment, > > ShapeIterator does really nothing more than a copy of the point data. I > > just > > looked at PicturePlayer and I think this results in two copies even, one > > when > > constructing the BShape, at least there is a TODO. The ShapeIterator way > > to > > copy the data is quite expensive, too. Do you know where PicturePlayer is > > used? I'll grep the source.... the most obvious solution to me is to use > > the > > point and op data directly, ommiting any copies, in the two function hooks > > that the PicturePlayer invokes. > > > > It's like this because a BPicture can also be "Played" client side > (i.e. not by app_server), by implementing a custom op table. > PicturePlayer is also used by ServerPicture to draw a picture. Thanks, I missed the client part. I guess it doesn't hurt to leave it as is then. Best regards, -Stephan