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.
Regards, SD
François Revol wrote:The feature is certainly very cool. I can even imaging a solution to the BBitmap shared memory problem. It's more a matter of what happens when you call DrawBitmap(). The BBitmap memory doesn't *have* to be shared with the app_server instance that draws it. On a local machine that is quicker of course, but it doesn't have to be that way, so apps would work unmodified.No the current implementation *always* uses shared areas for BBitmaps, so AFAIK it doesn't check for changes.I know. I meant to say it doesn't have to be that way, it can be implemented in a way that works, even if that means sending the bitmap each time on DrawBitmap(). Possible optimizations aside if apps indeed used APIs that made it clear the bitmap contents changed...Still calling DrawBitmap a lot on a bitmap that doesn't change would be awful if you force sending it each time, it would void the purpose.Sure it may be slow for these cases, especially for larger bitmaps, but it can be made to work.Best regards, -Stephan
