[haiku-appserver] Re: BView::ClipToPicture

  • From: Stefano Ceccherini <burton666@xxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: 8 Nov 2004 10:40:40 -0000

                        
Hi,

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

Sure, don't worry :)
>       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 

I'm pretty sure too it's done server side (cough! cough! *** asm dump *** 
cough! cough!), and I already said also on the list :)
And actually it makes more sense.
Though as I didn't want to touch app server internals, I wrote a client side 
implementation which works, so at least we have a reference implementation. I 
never thought that this implementation has to be the final for R1 :)



>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.

Sure it is, and I agree too. But see above :)

>       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. 

Can't comment on this.

>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.

Well, sure even if we put some permission checks in BSession, one could use 
write_port() directly if he wants to do some harm to the server. With what you 
said above we exterminate that issue.

>       Stefano, you did not answered my question, but I guess >there is such a 
> method judging from above.

Sorry, I'll try to:
Yes, there is, it's called BRegion::Support::CleanupRegion() (it's in 
RegionSupport.h).

>       If yes, then I hope you call that method after the >last _AddRect(); 
> because I'm under impression it 
>involves some processing.

Yeah, it does. What I meant is that I'm not sure it's required, as _AddRect() 
already merges some rectangles in particular cases. I'll check.

>>>     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.

I'm not even sure 8 bit is enough, btw. If you test my version and compare the 
resulting images, the text on the one on the right is a bit worse than the 
original (btw, it happens on be's version too, just a bit less noticeable).

>>'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.

I know. Though, optimizing that stuff is completely useless if we don't get any 
speed advantage.
First we have to test what we get, for every optimization we do. Optimizing 
blindly is the wrong way to go.
And, currently, the bottleneck is elsewhere.

(That said, I really want to make all the possible changes to have the fastest 
code, just I'm not worried about it right now).


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

Yeah, I know :)



Stefano Ceccherini aka Jack Burton
---------------------------------------------------------------
Scegli il tuo dominio preferito e attiva la tua email! Da oggi
l'eMail di superEva e' ancora piu' veloce e ricca di funzioni!
http://webmail.supereva.it/new/
---------------------------------------------------------------


Other related posts: