From be0f1de71f3074bc1b9a31e5252a20d7181c9fb6 Mon Sep 17 00:00:00 2001 From: Hajime Hoshi Date: Thu, 22 Aug 2019 23:22:49 +0900 Subject: [PATCH] Destroyed Performance Tips (markdown) --- Performance-Tips.md | 45 --------------------------------------------- 1 file changed, 45 deletions(-) delete mode 100644 Performance-Tips.md diff --git a/Performance-Tips.md b/Performance-Tips.md deleted file mode 100644 index 7ef1fa9..0000000 --- a/Performance-Tips.md +++ /dev/null @@ -1,45 +0,0 @@ -# Make similar draw function calls successive - -The less draw commands, the better the performance is. - -One drawing function like `DrawImage` or `Fill` is usually treated as one (internal) draw command, but there is an exception. Successive drawing commands are treated as one draw command when all the below conditions are satisfied: - -* All the functions are `DrawImage` or `DrawTriangles` -* All the render targets are same (`A` in `A.DrawImage(B, op)`) -* Either all ColorM element values are same or all the ColorM have only diagonal ('scale') elements - * If only `(*ColorM).Scale` is applied to a ColorM, the ColorM has only diagonal elements. The other ColorM functions might modify the other elements. -* All the composite modes are same -* All the filter values are same -* All the address values are same (only for `DrawTriangles`) - -Even when all the above conditions are satisfied, multiple draw commands can be used in really rare cases. Ebiten images usually share an internal automatic texture atlas, but when you consume the atlas, or you create a huge image, those images cannot be on the same texture atlas. In this case, draw commands are separated. The texture atlas size is 4096x4096 so far. Another case is when you use an offscreen as a render source. An offscreen doesn't share the texture atlas with high probability. - -examples/sprites is a good example to draw > 10000 sprites with one (or a few) draw command(s). - -# Avoid changing render sources' pixels - -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. Avoid this if possible. -``` - -As well, cyclic drawing should also be avoided. - -``` -A.DrawImage(B, op) -B.DrawImage(A, op) // cyclic drawing! Avoid this if possible. -``` - -# Avoid using the screen as a render source - -The screen is a special image because the image is cleared at every frame. As explained above, Ebiten records a drawing function calls but using the screen as a render source makes the calculation complicated. - -# Don't call (*Image).ReplacePixels too much - -ReplacePixels is a relatively heavy function that calls `glTexSubImage2D` internally. - -# Don't call (*Image).At too much - -At is also heavy that tries to solve all the queued draw commands.