[haiku-appserver] Re: BView::ClipToPicture

DarkWyrm wrote:
>>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.

        You would slow down the server. app_server should receive only valid 
data. :-) I know it would be 
more vulnerable... (would not be the case for R2, though)
        [ BTW, it receives valid data only from BWindow ]

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

        How about speed?

>>>     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 did not saw a difference.

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

        Perfect.

> Anyway, we shouldn't disable antialiasing - the quality difference is 
> noticeable, and not a good one, either.

        Hehe. I have talked with Stefano today and we think it's better if AA 
is disabled.
        Let me explain why.
        AA is used just for displaying fonts on screen for a better _visual_ 
quality. The clipping region 
is a structure which either includes a point or it doesn't. By clipping to a 
font in a BPicture we 
need to care only about the pixels that actual characters occupy. AA is for 
better visual effect, it 
has no use in building a clipping region.
        Think about it: if you are to use AA for a text, how can you make the 
resulted clipping region 
looking better if you only have 2 values: 1-it is included, 0-it is not 
included in region. You can't!
        As a proof, run the two executables Stefano gave us. you would see in 
the right pane the clipped 
text is not altialiased.

        [more to think: (8/15/16/32)bit bitmap: if AA is enabled all pixels 
that != white will be part of 
the clipping region. ;-) Think how this would look like... :-) funny characters 
isn't it? :-D ]

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

        Too expensive.

        IMHO, the best solution is to use a 1bit surface, and draw with a 
single color (changing the color 
would not be possible) and disable AA for text rendering.



Bye,
Adi.

Other related posts: