diff options
author | xgoff <antipotroast@gmail.com> | 2012-08-04 02:17:29 -0500 |
---|---|---|
committer | xgoff <antipotroast@gmail.com> | 2012-08-04 02:17:29 -0500 |
commit | 0913693cde5fb74db76b2d283787ffb6a4d794ec (patch) | |
tree | 6f180d8d6967702bcb3993527b25f129738acfae /README.md | |
parent | 6de633350db152d47b53ae8ede75d0199bc22b7b (diff) | |
download | love2d-fakecanvas-0913693cde5fb74db76b2d283787ffb6a4d794ec.tar.gz love2d-fakecanvas-0913693cde5fb74db76b2d283787ffb6a4d794ec.tar.bz2 love2d-fakecanvas-0913693cde5fb74db76b2d283787ffb6a4d794ec.tar.xz love2d-fakecanvas-0913693cde5fb74db76b2d283787ffb6a4d794ec.zip |
zero-argument version of canvas:clear() is much faster now
Diffstat (limited to 'README.md')
-rw-r--r-- | README.md | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -7,7 +7,7 @@ it is more or less a drop-in library, in that all you need to do is call `requir it uses (a few) screenshots in order to isolate drawing operations, which means there are some amusing drawbacks: * `setCanvas()` is fairly expensive -* clearing a canvas is really expensive +* non zero-argument versions of canvas:clear() are really expensive * each `setCanvas()` call will allocate several megs of ram, this isn't a huge deal if you draw to canvases only occasionally. draw to one every frame, though... * possible drawing issues if you call `love.graphics.present()` yourself, specifically between `setCanvas()` calls * canvas width/height cannot exceed the window's width/height, and if your hardware lacks PO2 support, canvases will be further limited to that as well. ie: for an 800x600 display the max canvas size is 512x512. 1024x768 will limit you to 1024x512, and so on. |