Thanks for the details.
I did think that the disparity might be the result of a unoptimized code
paths, but my understanding of how the Shader integrates into the rendering
implementation as a whole was too sketchy to know whether this would be an
optimization that one might reasonably expect to be feasible.
In my case, the optimization isn't vital since the existing code works
pretty much as well as I need it to - I guess the tiles are large enough
that the overhead of rendering them separately isn't too great.
As a general point, I've run into a few surprises regarding the performance
characteristics of certain graphical operations. One I ran into yesterday
was that drawing an RGB_565 image (without matrix) onto a Canvas obtained
from a SurfaceView became significantly slower after specifying SRC mode on
the Paint object. Given that there is no alpha channel on the src, I would
have expected the SRC mode to have been a noop at worst, and at best trigger
an optimization.
I hesitate to report these as issues because knowing what the expected
performance should be (or can be expected to be) seems very difficult.
Tom.
2009/2/6 Mike Reed <r...@google.com>
>
> Doh! You've stumbled across a known missing optimization. No promises,
> but this has been identified as an future optimization.
>
> The dirty details are that the current code has special optimizations
> for a straight drawBitmap when there is no matrix (other than
> translate). In addition, there is another optimization for SRC mode
> with 32bit bitmaps, where the blitter can literally call memcpy, since
> there is no need to inspect the src pixels for blending. Neither of
> these optimizations exist (yet) for the bitmapshader code.
>
> On Thu, Feb 5, 2009 at 5:41 PM, tomgibara <m...@tomgibara.com> wrote:
> >
> > Romain, Thanks for the explanation.
> >
> >
> > On Feb 5, 10:26 pm, Romain Guy <romain...@google.com> wrote:
> >> Tom,
> >>
> >> A shader is a per-pixel operation, which lets you apply it to any
> >> shape, respecting alpha blending as well. As such it is not surprising
> >> that your first method is faster.
> >>
> >>
> >>
> >> On Thu, Feb 5, 2009 at 2:08 PM, tomgibara <m...@tomgibara.com> wrote:
> >>
> >> > I'm experimenting with tiling a fullscreen image (480x320px ARGB
> >> > bitmap) with a square image (160x160px ARGB bitmap). My initial
> >> > implementation was naive:
> >>
> >> > public void render(Canvas canvas) {
> >> > final int size = tile.getWidth();
> >> > final int w = canvas.getWidth();
> >> > final int h = canvas.getHeight();
> >> > for (int y = 0; y < h; y += size) {
> >> > for (int x = 0; x < w; x += size) {
> >> > canvas.drawBitmap(tile, x, y, null);
> >> > }
> >> > }
> >> > }
> >>
> >> > Then I remembered that Paint supports a Shader, so I swapped this
> >> > implementation for something much more satisfying:
> >>
> >> > public void render(Canvas canvas) {
> >> > canvas.drawPaint(paint);
> >> > }
> >>
> >> > Where paint is initialized outside this method with:
> >>
> >> > paint = new Paint();
> >> > paint.setShader(new BitmapShader(tile, Shader.TileMode.REPEAT,
> >> > Shader.TileMode.REPEAT));
> >>
> >> > I expected that using a BitmapShader would be competitive with the
> >> > first implementation and probably slightly faster. But initial
> >> > benchmarking indicates that the first method is more than twice as
> >> > fast (almost 3x as fast if PorterDuff.Mode.SRC is used for both). I
> >> > found that surprising.
> >>
> >> > Is there a good reason that the BitmapShader is necessarily much
> >> > slower, or does it point to a deficiency in its implementation?
> >>
> >> --
> >> Romain Guy
> >> Android framework engineer
> >> romain...@android.com
> >>
> >> Note: please don't send private questions to me, as I don't have time
> >> to provide private support. All such questions should be posted on
> >> public forums, where I and others can see and answer them
> > >
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
