Re: [lmi] using standard icon sizes and wxArtProvider

[Vaclav Slavik]

On Fri, 2008-10-03 at 14:46 +0000, Greg Chicares wrote:
> Should wxArtProvider::DoGetSizeHint() be part of the documented
> interface? It seemed to me that GetRealSize() here:
>   http://cvs.savannah.gnu.org/viewvc/lmi/lmi/icon_monger.cpp?annotate=1.1
> is like a virtual override. Grepping the wx-2.8.7 sources, this virtual
> function doesn't seem to be used internally by wx, so is it intended
> for wx users to override?

To be honest, I have no idea what was the thinking behind
DoGetSizeHint() addition, it doesn't make sense to me. It is used by wx
in GetSizeHint() static method, but only if you explicitly request it
(i.e. when you could just as well call your code directly, e.g.
GetRealSize() above), not by default.

And GetSizeHint() itself is useful for determining platform's standard
sizes in custom art providers -- again, using it to get the values from
DoGetSizeHint() doesn't make sense, because you already know the
customized values in this case (again, see LMI code)...

> (BTW, grepping for /GetSizeHint/ throughout the sources finds
>   msw/mdi.cpp:    // but allow GetSizeHints() to set the min size
> but no function GetSizeHints() seems to exist anywhere.)
> 
> If you'd like to add a fancier algorithm for icon downsizing to wx,

I don't think we can do much (or any) better than what we already have.
It may be good to have Lanczos3 filter in wxImage, but it's not going to
help with icons this small. Your example shows this nicely, I think --
it produces icons that are even less sharp than those created with a box
filter.

In some cases, it would be beneficial to first crop the image to remove
any empty borders and then downscale, but it's not good for the generic
case either: you may have icons that intentionally occupy less space
than what is allocated for them.

In short, I think that any energy spent on creating some smart
downscaling algorithm would be better spent on manually creating
aesthetically pleasant sharp 16x16 icons.

> I'd welcome that; we could discuss it privately. Here's a side-by-side
> comparison of the present box-averaging result to a Lanczos resizing:
> 
>   
> http://cvs.savannah.gnu.org/viewvc/lmi/lmi/gwc/resize.png?hideattic=0&revision=1.1&view=markup
> 
> This isn't really important for lmi today, but someday it could be
> helpful. It's always better to design customized small icons than to
> rely on any algorithm when converting, say, 24x24 --> 16x16. However,
> I conjecture that this might be a beneficial enhancement for converting
> 16x16 --> 16x15, which apparently would happen in the following

Usually, it's best to remove one line at top or bottom of the icon in
this case -- very often, there's at least one empty line of pixels
there.

If that's not an option, then the simplest method of downsampling is
used, the better -- the ideal filter would *blur* all the sharp lines in
the icon (the change in size is only by a tiny amount and the lines get
moved in between two pixels in the new image and contributes to the
color of multiple pixels in the output).

Whether such downscaling will work depends on image's properties (sharp
edges vs. low contrast) much more than on the particular filter used (at
this size and 1px difference, they're very similar).

> (BTW, I wonder why any platform would choose 16x15 over 16x16: why
> not perfectly square? 

No idea, maybe Vadim will know more... I always accepted it as a MSW
weirdness.

Regards,
Vaclav