[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,

Other related posts: