On Mar 27, 2009, at 3:39 AM, Vitaliy Margolen wrote:
Aleksey Bragin wrote:
Fix bitmap size calculation in IMAGELIST_InternalExpandBitmaps and
remove unneded parameter. Memory requirements are greatly reduced
after
this fix.
The bug was an ambiguous meaning of a cx parameter, which was
supposed
to be a width of an individual image inside the list, but width of a
whole bitmap was passed in thus making memory requirements huge
(number
of images * width of whole bitmap = required bitmap size).
Furthermore, cx parameter is redundant because all checks are already
there (that the image list can't be reduced), and besides of that
there
is no use for it anymore. Thus it's been removed.
That bug was introduced while attempting to change the size of the
bitmaps
for the toolbar. Looking at the code it's rely iffy if image list
really
should be able to do that at all. Or that toolbar should handle the
resize
itself (most likely).
The commit I'm talking about is:
commit 19cef6ca1059140d00ac8b445ab3f9eb0491f239
Author: Gerard Patel <g.pa...@wanadoo.fr>
Date: Sat Jul 8 12:48:37 2000 +0000
Allow the size of bitmaps to be changed after toolbar buttons have
been added.
With your patch you "disable" this ability (which I don't think is
working
anyway). So some tests are in order. At least a test program
demonstrating
what's the correct behavior.
Vitaliy
Yes exactly, however I didn't provide any testcase, because I just
removed non-used parameter and fixed existing code. If someone wants
to implement image list having variable width of each image - he's
free to proof that Windows does this (which I very much doubt).
Anyway, e.g. Sib Icon Edit required ~ 30 Mb (something like 27 images
* 13440 width * 24 height * sizeof(each pixel)) of memory for every
instance to run (due to this bug). Now it requires only about 300kb :-).
