[openbeos] Re: openbeos Digest V8 #104
- From: Stephan Assmus <superstippi@xxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 26 Jun 2008 19:50:19 +0200
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:
