[haiku-appserver] Re: BView::ClipToPicture
- From: "DarkWyrm" <bpmagic@xxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Mon, 08 Nov 2004 19:13:58 -0500 EST
> > 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 can, though. The foundation for managing this is already complete.
The only thing that is not done is the checking on the client side to
see if the message is too big for a port.
> 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.
I've had security/stability issues like this in mind for a while now.
Until we get what Adi described, there are numerous checks in place to
help prevent problems, such as checking the protocol codes and
validating the attached data. One thing that should happen eventually
is to check the size of the attached data buffer for each message. All
this should prevent the vast majority of problems.
> > 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).
I saw the message this morning but couldn't answer until tonight, so I
had all day to kick this one around. FreeType can do both 8-bit and 1-
bit color, and while there are glyph-copying routines in place only for
32-bit color, doing other color spaces shouldn't be much of a deal.
Anyway, we shouldn't disable antialiasing - the quality difference is
noticeable, and not a good one, either. As much as a temporary memory
hog as it could be, the only thing I can think of which would work well
is to use a 32-bit bitmap and memset it to 0, thus rendering the entire
thing effectively transparent. Draw the picture into the thing and
check the alpha byte for each pixel and we can figure out the clipping
region from there. Thoughts?
--DW
Other related posts:
