[haiku-appserver] Re: BView::ClipToPicture
- From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Sun, 07 Nov 2004 16:40:43 +0200
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.
Other related posts:
