Performance improvement through smart memory usage

[GoogleCodeExporter]

At the moment, when you have an image "1" in memory, when you start
drawing, it makes a memory copy "2" (read 1, write 2), and you start
drawing on "2" (read 1 or 2 for feedback, write 2).
When you draw a second time, it makes a memory copy "3" (read 2, write 3),
and you start drawing on "3" (read 2 or 3 for feedback, write 3).

In theory, the program performs faster / with less efforts, if the same
memory areas are often used, as they will more likely stay in cache.

I think there's a way to reorder the allocation of pages, so instead of
inserting at first position, it would make the new page "second". In terms
of logic it would be no difference as the contents is immediately copied
from one to the other.

The scenario above would become:
You have an image "1" in memory, when you start drawing, it makes a memory
copy "2" (read 1, write 2), and you start drawing on "1" (read 2 or 1 for
feedback, write 1).
When you draw a second time, it makes a memory copy "3" (read 1, write 3),
and you start drawing on "1" (read 3 or 1 for feedback, write 1).

--> The "main screen" would stay for a very long time at the same memory
location, as long as you don't resize.

Original issue reported on code.google.com by yrizoud on 18 Jan 2010 at 11:55

[GoogleCodeExporter]

Hmm actually, due to the system of layers, several backup pages can reference 
the
same memory bitmap. This proposition would require updating *all* references to 
a
page, by browsing the entire history (max 99 pages * 16 layers)

Original comment by yrizoud on 21 Jan 2010 at 4:07

[GoogleCodeExporter]

Another solution is to use pointer indirection trough a PageMap.

- Each time we store a pointer to a page, we actually use an int (page number)
- The page map is a tableof byte* indexed by page number and pointing to actual 
data
- The page map is resized if you change the number of undo steps (16*steps size)

This way, you only have to update the page map.
There is a small overhead but I don't think it's that much. The page map is not 
a 
too big structure.

Original comment by pulkoma...@gmail.com on 21 Jan 2010 at 4:41

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 10 Feb 2010 at 12:20

• Added labels: Milestone-2.3

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 9 Aug 2010 at 9:37

• Added labels: Component-Pages
• Removed labels: Comp

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 1:34

• Added labels: Milestone-2.4

[GoogleCodeExporter]

Topic is abandoned, the rendering system has become so complex that 
optimizations at this level becomes fairly irrelevant.

Original comment by yrizoud on 8 Mar 2012 at 7:10

• Changed state: WontFix