[haiku-commits] Re: r35905 - in haiku/trunk: headers/os/interface headers/private/interface src/kits/interface src/servers/app src/servers/app/drawing ...
- From: Stefano Ceccherini <stefano.ceccherini@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 19 Mar 2010 10:53:07 +0100
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.
Other related posts:
