[openbeos] Re: openbeos Digest V8 #104

Hi,

Sergei Dolgov wrote:
> 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.

I know where you are comming from, but to draw a single pixel even with a 
function call overhead totally spoils the performance. Actually using IPC 
to do the same thing will be orders of magnitudes slower, no matter how 
efficiently it is implemented. The larger the bitmaps to draw, the less the 
impact of the overhead, but since you brought up the example of drawing 
thousands of 1 by 1 pixel bitmaps, I just don't see how that would be 
doable with IPC even close to the performance of simply asigning the bytes. 
Even if the drawing was done client side (something to consider actually), 
even then it would totally suck compared to doing it "manually".
That being said, I believe the current way the communication works should 
still have some potential for optimization. It's certainly on my list of 
things I want to do at some point, but seing how nicely everything 
performs, it's just not a very priority right now, because there is still 
so much other stuff to look into. I am just saying I hear you, but at the 
same time I believe this optimization makes a lot of sense for Firefox no 
matter what.

Best regards,
-Stephan

Other related posts: