diff options
| author | Ben Harris <bjh21@bjh21.me.uk> | 2023-07-30 11:30:19 +0100 |
|---|---|---|
| committer | Ben Harris <bjh21@bjh21.me.uk> | 2023-07-30 11:52:05 +0100 |
| commit | 58511aa009c672cc2ade783d537a5830806fd02c (patch) | |
| tree | ed6baaed3f6d9f92d339ea7b1bf588fc32246b1f /loopgen.h | |
| parent | 76da6ec140cbbdac6136469ce50aab40e218f398 (diff) | |
| download | puzzles-58511aa009c672cc2ade783d537a5830806fd02c.zip puzzles-58511aa009c672cc2ade783d537a5830806fd02c.tar.gz puzzles-58511aa009c672cc2ade783d537a5830806fd02c.tar.bz2 puzzles-58511aa009c672cc2ade783d537a5830806fd02c.tar.xz | |
Same Game: more efficient tile_redraw
I've rewritten tile_redraw to reduce the number of calls to
draw_rect(). Before, it would generally make five calls to
draw_rect() when drawing a tile. Now it makes at most three, and
usually two. That's one draw_rect() for each colour that appears in
the tile, which is as good as it can get. This reduces the time to
draw a large puzzle by about 35% on Firefox 102.
This is of significance to me because CanvasRenderingContext2D on my
test KaiOS device seems to have a limit on the number of fill() and
fillRect() calls that it will tolerate in a short time. This means
that if you issue more than 1024 fillRect() calls in rapid succession,
the later ones are simply ignored.
Same Game's largest preset called draw_rect() so much that it hit this
limit. That meant that the right-hand side of the grid didn't get
properly drawn when starting a new game. Now that it is less
profligate with draw_rect() it fits comfortably within the limit and I
get to see the entire grid.
Diffstat (limited to 'loopgen.h')
0 files changed, 0 insertions, 0 deletions