[openbeos] Re: openbeos Digest V8 #104
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.
Seems like initially all platforms (or almost all) used OS APIs to implement method DrawTile(). Then lot of hacks and workarounds appeared in nsImage methods. But as fallback case those still use "direct" slow way.
Now, about single DrawBitmap call. We finished with using that - to draw filled offscreen bitmap to target bitmap. Which resulted in much better results, as you can see. But problem was that even on off-screen bbitmaps usage of DrawBitmap had too high price. So, lot of work was done for tricky manual bitblitting of those "tiles" - but that way is not always too convinient, if you meet need for: 
1)drawing when destination and target have different colorspaces
2)when scaling is needed.
Both problems were solved that or this way in Mozilla BeOS port, but it is actually shame, when and if we need lot of coding which is like yet another bicycle invention, when we have nice API method which should care about all of that. In theory. 

Regards, SD

Other related posts: