[openbeos] Re: openbeos Digest V8 #104
- From: Stephan Assmus <superstippi@xxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 26 Jun 2008 16:27:18 +0200
Sergei Dolgov wrote:
> One of most serious obstacles when we tried to improve Mozilla speed was
> too high price of freqent calls to app_server (not any thread
> fine-graining issues:). E.g. even DrawBitmapAsync was too pricey, when we
> draw backgrounds (so called tiled-drawing). Imagine quite usual case when
> web-developes set background consisting of 1*1 pix images. or
> 1*1000000 pix. We found workaround, but straight way of using DrawBitmap
> could hang Mozilla for 20 minutes at each Invalidate() call on
> simply-looking sites.
>
> Another issues were also related to intensive communication to app_server
> - like getting char widths for text drawing with "justification" (most
> frequent case) or for text with positioning array (generic case). Btw, it
> is also nice to have DrawString() with additional positioning array
> parameter (like it exists in Win API), instead that one which gets single
> escapement_delta, but that's another story, not exactly on-topic.
Makes a lot of sense. Please do create enhencement tickets, so that these
remarks don't get lost. Even BTextView uses a "width cache buffer" to avoid
too many calls for getting the width of glyphs. Maybe this can be done on
the BFont level instead of on the individual view class level. As for
drawing thousands of 1x1 bitmaps, I would be surprised if the Firefox
implementation on other platforms indeed used API calls to draw those.
Doesn't Firefox draw into a bitmap anyways (ie client side drawing)? Only
stuff like font rendering would have to go through the app_server, unless
you use Freetype yourself, but even that is possible if it needs to be
done. All one would be left with is one DrawBitmap() call for the entire
resulting view bitmap that actually reaches app_server in the extreme case.
I am not saying this is necessarily how it should be done, but a good
ballance should be possible where Firefox uses partly it's own client side
drawing and partly app_server based drawing. I am guessing that Firefox or
any browser could depend implementing a drawing API that is more capable
and advanced than what app_server offers, so it needs to implement its own
drawing anyways.
Best regards,
-Stephan
Other related posts:
