[haiku-appserver] Re: BView::ClipToPicture

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 08 Nov 2004 11:12:27 +0200

Hi,

Stefano Ceccherini wrote:
>>                      
>>      I wanted to ask you if you could use "spans" intead of >adding 1x1 
>>rects... guess you took care of that. :-)
> 
> Not yet, though I added a comment in the source code :P

        :-))
        OK, please do this as we'd lose performance that we could otherwise 
gain so easily...

>>      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!).
> 
> Yeah, that's true.
> Though that code works charmlessly in beos r5, so I guess you'll need to 
> support
> transfer of big amounts of data (as someone could generate a very big region 
> himself,
 > and then call ConstrainClippingRegion(), and so the big region would be 
 > transfered to the server.)

        By watching BView method names, yes, it gives you the impression it is 
done client side. Still, I'm 
pretty sure it's done server side; this region is not used at all by BView or 
BWindow. There is 
another reason for not doing this client side: BBitmap requires 2 threads. ;-)
        Oh, there is the third reason also, already mentioned: transferring the 
region on server.

        All these led me to think it's better if we do ensemble this region in 
a ServerWindow thread on server.

        Now... about ConstrainClippingRegion(). No doubt should we be able to 
transfer big amounts of data 
between BWindow and ServerWindow threads. That's not possible ATM and, that's 
not my problem! Let 
Phatz solve this, I don't care!! I have told you guys, we should not have 
changed from BSession. 
I've spoked with Axel, in R2 you will be able to specify what threads can 
write/read to a specified 
port so BSession would've done just fine.

>>      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.
> 
> Usually BRegion takes care of that automagically. But yeah, maybe I should
 > check if it's done when calling the private _AddRect() function,
 > and if not, call the function myself.

        Stefano, you did not answered my question, but I guess there is such a 
method judging from above.
        If yes, then I hope you call that method after the last _AddRect(); 
because I'm under impression it 
involves some processing.

>>      First we need to use a 1bit bitmap. Then you could use 
> 
> No, a 1 bit bitmap won't do.
> I already tried and text isn't drawn if the bitmap is B_GRAY1.

        Hm... what if you disable anti aliasing? DW, what can you tell us about 
our font rendering engine?
        OK, then use 8bit bitmap and you'll still be able to process 4 (if not 
8 by using long long int) at 
a time.

>>'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.
> 
> As I said, the problem is not reading the pixels, but creating the bitmap and 
> drawing on it.

        Not entirely true. It's not the same processing 1 pixel at a time 
instead of 4 or possibly 8.

> Try to comment everything out except the bbitmap creation, you'll be 
> surprised.

        BBitmap == BWindow. That's why. If it is done on server this will 
return FLASE. :-))))))




Bye,
Adi.

Other related posts: