Performance problems on big images: first click when start drawing or drag a pasted image #239
Comments
|
From ergba...@gmail.com on August 17, 2013 19:46:28 I can confirm this. Zooming also causes issues, as Aseprite refuses to draw the screen when zooming in. (If it's possible with Allegro, maybe look into multithreading as well?) |
|
From davidcapello on November 10, 2013 10:56:30 The original problem is fixed with the following commit: 13946b3 @ergbam20: I don't know about the zooming issue, if you want to open a new issue with some details of how to reproduce it, that would be great. Thanks! Status: Fixed |
|
From davidcapello on November 10, 2013 11:27:50 Not really fixed for huge RGB images. One of the main issue is Image::clear(), that cannot memset() the whole buffer and must use iterators to go pixel by pixel setting the color. To really fix this issue the Image implementation must be replaced with tiles or something like that. |
|
From ergba...@gmail.com on November 11, 2013 16:27:48 This would be the about the time that you wish Allegro had a C# branch, isn't it? Actually, I wonder if there is a way to do image processing and memory management through a C# applet... |
|
From davidcapello on November 11, 2013 16:49:53 Actually I enjoy programming in C++ a lot more than in C# (and I program in both languages on a daily basis). So I don't know if that C# branch would help us. Also I'm using my own image processing routines (you can find the raster library here https://github.com/aseprite/aseprite/tree/dev/src/raster ). Aseprite uses Allegro only for keyboard/mouse input and screen output, not for internal representation of sprites/documents/images (you can find the sprite editor code to draw the active document in the screen here http://goo.gl/CJttya ). I've plans to use pixman in a near future ( https://github.com/aseprite/pixman ) which has blending modes, pixel formats, gradients, etc. Anyway you cannot solve this issue using pixman (or several other image processing libraries). To solve this issue we need a better internal representation of images, separated by tiles of 32x32 or something like that. Where a matrix of tiles conform the whole image (so you can process each tile separately). I'm making progress in this direction, but it's a long road, for example, this recent (huge) commit e5ba8e0 is a refactor to wrap the image access with lock/unlock semantic. So in the future the internal representation of the image doesn't need to be a continuous array of bytes, i.e., we'll be able to use tiles. |
Add an ImageBufferPtr parameter to RenderEngine::renderSprite() to avoid allocating memory for each render.
Here we avoid copying and clearing pixels that will not be used in the whole tool loop process. Changes: * Add several member functions in ToolLoop to validate/invalidate regions of source/destination images so we know what regions are safe to use by inks and can be shown in the editor * Add new DocumentObserver::onExposeSpritePixels() member to validate pixels that will be displayed in the editor * Add Ink::needs/createSpecialSourceArea() member functions to validate extra areas for inks like blur or jumble * Add undoers::ModifiedRegion to save the undo information about the modified region * Add ShowHideDrawingCursor class * Change "blur" tool policy from overlap to accumulate (This is a real fix for issue #239)
From davidcapello on June 06, 2013 21:39:43
What steps will reproduce the problem? 1. Create a 4000x4000 image
2. Start drawing
The first click has a delay (note for the developer: try to create a buffer that can be shared between temporary images used in the drawing process).
The same when you try to drag the pasted image on this big sprite.
Original issue: http://code.google.com/p/aseprite/issues/detail?id=239
The text was updated successfully, but these errors were encountered: