FreeLists / haiku-appserver / [haiku-appserver] Re: BView::ClipToPicture

[Adi Oanca <adioanca@xxxxxxxxxxxxx>]

Hi guys,

Stefano Ceccherini wrote:
>>Excellent work. :D Unless Adi has any objections, why don't you >check it in?

        I wanted to ask you if you could use "spans" intead of adding 1x1 
rects... guess you took care of that. :-)

> Ok, though you'll have to wait till monday at least.
 > Unless you decide to check it in yourself  (and I would be ok with 
that) :))

        Not sure it's a good idea. First we have to decide where to add this 
code.
        If we draw client side, we need to transfer this region server side. 
Remember this is quite a big region and BPortLink can't transfer big 
amounts of data (Thanks Phatz!).
        For this reason I think it's better to enssemble this region server 
side. What do you do with it client side? Nothing.

> On a side note, before someone jumps out screaming we should optimize it 
> using ASM.... :))))

        :-)) Christian would take care of that later...

> The test takes ~5000 usecs on my system.
> The main bottleneck seems to be the creation of the BBitmap
 > (~2300 usecs here) and the drawing of the BPicture on the bitmap itself.
> 
> I tried to add spans instead of 1x1 pixels,
 > and beside a small issue that I'll fix as soon as possible,
 > I got a nice 30/40% speed improvement,

        Uh, nice!
        You know, it's good to have speed improvements here, but it's much 
better when searching points inside this BRegion - fewer rectangles.
        BTW, is there a method for minimizing the number of rectangles in a 
region? If there is, maybe we should call it after adding all rectangles.

 > though, to be able to reach the speed of the beos version
 > (less than 50 usecs here), we'll need to change the way its' done now
 > (for example, calculating the region server side, after we
 > will have drawn the BPicure on a "special" bitmap/canvas,

        First we need to use a 1bit bitmap. Then you could use 'long long int' 
and with compiler optimizations you could process as much as 64 pixels 
at a time if you are lucky. if *((long long int)pt) != 0 you start using 
divide et impera: split into 2 32bits segments and check of the first. 
You lucky? hurray: split in 2 16bits words and again compare the first. 
You lucky? yeey: split into 2 8bit segments - process the first segment. 
Finally if those 8bits != 0 you need to start searching bit by bit the 
remaining bytes until the 32th - because you need to stay byte alligned.


> Anyway, for the moment I think we can keep it as is. At least it works :))

        Thank you very much Stefano.



Regards,
Adi.