Performance is bug like any other, so feel free to report them as bugs. Is your surface 32bit or 16bit? If it is 16bit, then I should definitely have noticed the SRC mode and made that fast (i.e. memcpy).
On Sun, Feb 8, 2009 at 6:27 PM, Tom Gibara <[email protected]> wrote: > 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 <[email protected]> >> >> 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 <[email protected]> wrote: >> > >> > Romain, Thanks for the explanation. >> > >> > >> > On Feb 5, 10:26 pm, Romain Guy <[email protected]> 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 <[email protected]> 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 >> >> [email protected] >> >> >> >> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
