diff --git a/Performance-Tips.md b/Performance-Tips.md
index c96ed69..b3ac69b 100644
--- a/Performance-Tips.md
+++ b/Performance-Tips.md
@@ -1,13 +1,33 @@
-# Draw commands
+# Make similar draw function calls successive
 
 The less draw commands, the better the performance is.
 
 One drawing function like `DrawImage` or `Fill` is treated as one (internal) draw command, but there is an exception. The two or more successive commands are treated as one draw command when
 
 * All functions are `DrawImage`
-* All the render targets are same
-* All the render sources are same
+* All the render targets are same (`A` in `A.DrawImage(B, op)`)
+* All the render sources are same (`B` in `A.DrawImage(B, op)`)
 * All the color matrices are same
 * All the composite modes are same
 
 examples/sprites is a good example to draw > 10000 sprites with one draw commands.
+
+# Avoid changing render sources too often
+
+Ebiten records almost all draw functions in order to restore when context lost happens. When a render source's pixel is changed after it is used as a render source, Ebiten tries a complicated calculation for restoring.
+
+```
+A.DrawImage(B, op) // B is a render source
+B.DrawImage(C, op) // tries to change B's pixels. Don't do that if possible.
+```
+
+As well, cyclic drawing should also be avoided.
+
+```
+A.DrawImage(B, op)
+B.DrawImage(A, op)
+```
+
+# Avoid using the screen as a render source
+
+The screen is a special image because the image is cleared every frame. As explained above, Ebiten records a drawing function calls but using the screen  as a render source makes the calculation complicated.