
|
[haiku-appserver]
||
[Date Prev]
[11-2004 Date Index]
[Date Next]
||
[Thread Prev]
[11-2004 Thread Index]
[Thread Next]
[haiku-appserver] Re: BView::ClipToPicture
- From: Stefano Ceccherini <burton666@xxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: 8 Nov 2004 07:47:51 -0000
>
> 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
> 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.)
> For this reason I think it's better to enssemble this >region server
>side. What do you do with it client side? Nothing.
As I said, the code works in R5, should work in haiku too.
> On a side note, before someone jumps out screaming we should optimize it
> using ASM.... :))))
> :-)) Christian would take care of that later...
Eheh.
> 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.
Yeah, true.
> 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.
> 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.
>'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.
Try to comment everything out except the bbitmap creation, you'll be surprised.
> Thank you very much Stefano.
It's a pleasure :)
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/
---------------------------------------------------------------
|

|