No, the 8k x 8k bitmap would require (8192 x 8192 x 4) x 3 = 805,306,368 bytes, or about 768 MB of memory, split over 3 contiguous allocations of 256 MB each. Sometimes it's hard to find holes that big in the virtual addressable range of a 32-bit process. You may have "2 GB free RAM" but that's not the way things actually are. Memory management, especially on 32-bit systems right now, is not as simple as, "I have X bytes free, so I should be able to use X bytes."
This is one of the major things I'm addressing for Paint.NET 4.0 though.
Hi again,
Ummm, seems a strange way to do it. In the paint software I wrote, with undo buffers, there was no problem allocating this amount of memory. I'm not sure why you're looking for 256MB chunks. That's not the way to do it. In all of the memory management routines I use there's absolutely no problem so yes, it is as simple as getMem of 900MB, or whatever size you need. And this is on a 32-bit WindowsXP system. The first thing I'd look at is why you actually need (8192 x 8192 x 4). If the native bitmap you're loading is only 24-bit then the alpha channel is a waste. Secondly it's extremely inefficient to allocate 3 times the space you actually need. Way to much waste of memory and therefore you're limiting your end users as to what they can work with.
I'm not trying to have a go here but there are hundreds of paint programs out there that have no problem with this type of thing, including stuff we write in house.
Good luck with the project. It's definitely a worthwhile cause. I'm all for supporting people or teams pushing ahead with free software purely for the gratification of actually making something people will love to use.
