You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With 16 layers of 2048 * 2048 px, Klecks/Kleki is capable of reaching the 480MB canvas limit that iPadOS has. That breaks the application, as no new canvas objects can be created, or more specifically their contexts are null.
Scenario 1 - embed - iPad
create new image: 2048*2048
add new layers until there are 16 layers
draw for a while, ~20 lines
-> now the application will be broken
Scenario 2 - embed - iPad
open an image that is 2048*2048 and has 16 layers
-> the application is broken right away
Scenario 3 - standalone - iPad
create new image: 2048*2048
add new layers until there are 16 layers
store to browser storage
reload the page
-> now the application is and will remain broken until the cache (indexedDB) is cleared
Also reloading the page will break everything much quicker because it appears that Safari keeps the page from before the reload in memory. It will fail to create even a single canvas.
Cause
When the application breaks, it has 32 2048*2048px canvases, or 32 * 2048 * 2048 * 4 / 1024 / 1024 = 512MB . 16 canvases which represent the current state of the image, and 16 canvases that represent the image in its earliest Undo state. Architectural changes are needed to fix this issue.
The text was updated successfully, but these errors were encountered:
With 16 layers of 2048 * 2048 px, Klecks/Kleki is capable of reaching the 480MB canvas limit that iPadOS has. That breaks the application, as no new canvas objects can be created, or more specifically their contexts are null.
Scenario 1 - embed - iPad
-> now the application will be broken
Scenario 2 - embed - iPad
-> the application is broken right away
Scenario 3 - standalone - iPad
-> now the application is and will remain broken until the cache (indexedDB) is cleared
Also reloading the page will break everything much quicker because it appears that Safari keeps the page from before the reload in memory. It will fail to create even a single canvas.
Cause
When the application breaks, it has 32 2048*2048px canvases, or
32 * 2048 * 2048 * 4 / 1024 / 1024 = 512MB
. 16 canvases which represent the current state of the image, and 16 canvases that represent the image in its earliest Undo state. Architectural changes are needed to fix this issue.The text was updated successfully, but these errors were encountered: