[haiku-appserver] Re: BView::ClipToPicture
- From: Adi Oanca <adioanca@xxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 09 Nov 2004 18:21:15 +0200
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:
