- package
com.Aina.Android; -
- import
android.content.Context; - import
android.graphics.Bitmap; - import
android.graphics.Bitmap.Config; - import
android.graphics.Canvas; - import
android.graphics.Paint; - import
android.graphics.drawable.BitmapDrawable; - import
android.view.View; -
-
- public
class GameView extends View { -
-
private Bitmap mBitmap = null; -
private Bitmap mBitmap2 = null; -
private Canvas mCanvas = null; -
private Paint mPaint = null; -
-
public GameView(Context context) { -
super(context); -
mBitmap = ((BitmapDrawable) this.getResources().getDrawable( -
R.drawable.img)).getBitmap(); -
mBitmap2 = Bitmap.createBitmap(320, 480, Config.ARGB_8888);//创建屏幕大小的缓冲区 -
mCanvas = new Canvas(); -
mCanvas.setBitmap(mBitmap2);//设置将内容绘制在mBitmap2上面 -
mPaint = new Paint(); -
mCanvas.drawBitmap(mBitmap, 0, 0, mPaint);//将图片绘制到缓冲屏幕上面 -
} -
-
@Override -
protected void onDraw(Canvas canvas) { -
super.onDraw(canvas); -
canvas.drawBitmap(mBitmap2, 0, 0, mPaint); -
} -
- }
- package
com.Aina.Android; -
- import
android.app.Activity; - import
android.os.Bundle; -
- public
class Test_Canvas extends Activity { -
-
private GameView gv = null; -
@Override -
public void onCreate(Bundle savedInstanceState) { -
super.onCreate(savedInstanceState); -
gv = new GameView(this); -
setContentView(gv); -
} - }
- 注:这里对sufaceview的双缓冲可能理解有误,surfaceview双缓冲应该是有两幅缓存图片,因为如果只有一张缓存图片的话,那么在将缓存图片往屏幕上绘制的时候是不能够往缓存图片上绘制东西的,而如果使用双图片缓存,则可以在往屏幕上绘制缓存图片的同时,往另一张缓存图片中添加东西。
- 下面的闪屏问题就是因为双缓冲所致:
- Hello Toothy Bunny,
On Jan 13, 9:27 am, Toothy Bunny <hongkun...@gmail.com> wrote:
> Hi All,Here is some information on how the Android graphics system works:
> I've been using SurfaceView and Surface for one of my graphics
> project.
> The problem keep bothering me is that the content in Surface's two
> graphic buffers does not synchronized so that when the "lockCanvas-
> drawCanvas-unlockCanvas" cycle is running, it shows different content
> and generate screen flicker.
In Android, every window is implemented with an underlaying Surface
object. A Surface is an object that gets composited onto the
framebuffer by SurfaceFlinger, the sytem-wide screen composer.
Each Surface is double-buffered, it has a back buffer which is where
drawing takes place and a front buffer which is used for composition.
When "unlockCanvas()" is called, the back buffer is "posted", which
means it's being displayed andbecomes available again.
However, the *implementation* of this mechanism is done by swapping
the front and back buffers. The back buffer becomes the front buffer
and vice-versa.
This mechanism ensures that there is a minimal amount of buffer
copying (a post operation doesn't move any pixels around) and that
there is always a buffer for SurfaceFlinger to use for composition.
This last feature is very important because it ensures that the screen
never flickers and never shows any artifacts *and* that
SurfaceFlinger never has to wait for a Surface to be ready (its front
buffer is always ready by definition), this means that a badly written
application cannot slowdown or interfere with other application's
windows.
As a side note, it is worth noting that the main screen itself (the
frame buffer) is double-buffered as well and uses the same posting
mechanism than any regular surface.
It should appear now that because of this posting mechanism,
incremental updates are not supported; and this is /the/ key point.
Back to your question now:
> After doing a bit research, I got my conclusion (not sure if it isYou are correct in your analysis. Something that the documentation
> correct though) here:
> 1. There are two separate buffers of each Surface object. According to
> SDK, they were called "front buffer" and "back buffer".
> 2. Android's Surface does not behaves like regular "double-buffer"
> system, which means: draw everything in back buffer and then flip the
> back buffer into the front buffer.
> What Android Surface does seems to be: draw in buffer A and flip it on
> the screen, then in next cycle, draw buffer B and flip it on the
> screen. As the result, the content visible on the screen comes from
> buffer A, B, A, B, A, .... I'm using buffer "A" and "B" here instead
> of "front" and "back" because I think they have equal role in
> rendering cycle.
> 3. The Surface buffer's alternate work style causes problem when I'm
> doing partial update (repaint only a portion of the Surface) for the
> performance purpose. Because one "lockCanvas-drawCanvas-unlockCanvas"
> cycle only update one buffer, the other one remains untouched, then
> when next "lockCanvas-drawCanvas-unlockCanvas" comes, it shows you an
> old content on the screen so that the flicker happens.
doesn't emphasis clearly is that with such a mechanism, your *must*
draw every single pixel of the Surface's back buffer each-time. In
essence, the back buffer is not preserved in post. This is a common
behaviorof hardware-accelerated graphics systems.
There is fact an API on the underlaying Surface object that allows to
update only a portion of the back buffer (but even then, every pixel
of that portion need to be redrawn). It is implemented by copying back
the former back buffer (now in the front) to the new back buffer
(formerly in the front). Unfortunately, this API is not exposed to
SurfaceView at the moment. I'm hoping to have this feature added
eventually.
> 4. My work around (works but with tremendous performance penalty)The best solution available right now to solve this problem, is to do
> When I'm doing partial Surface update, I do the following thing in
> each rendering cycle:
all of your rendering into your own bitmap and simply copy it into the
back buffer:
- create a bitmap
- attach a canvas to it
- do the rendering into that canvas
- lockCanvas
- draw your bitmap into the backbuffer
- unlockAndPost
Note that this method involves an extra copy of the whole buffer size,
but it is in fact not slower than what it would have been if the
posting mechanism worked as you expected/suggested.
> 5. In order to improve my solution a bit, I try to useI will investigate the error you are reporting. However, this solution
> "s.unlockCanvas(b);" instead of "s.unlockCanvasAndPost(b);" because I
> really do not need to make the second buffer flipping, I just need to
> synchronize its content. However, unlockCanvas() generates a "Illegal
> argument" exception. I can not figure out the reason.
would not have worked because unlockCanvas() is essentially a no-op,
it doesn't post the back buffer, which means it won't make it visible.
It is only intended to be used in very special situations.
> I have noticed someone has met the similar SurfaceView problem, seeThere is no way to do that at the moment, but we might add this
> the following topic: http://groups.google.com/group/android-developers/browse_thread/threa...
> I'm not sure if someone has any better solution than mine?
> Is there a way to notify Surface that I would like to use a fixed
> buffer as front buffer?
functionality eventually. Note that in that case, your Surface will
suffer from tearing, so it won't be suited for Surfaces that do a lot
of animations.
I hope this helps.
--
Mathias
Android Graphics