"Simon Taylor" <simontaylor1@xxxxxxxxxxxx> wrote: > > Stephan Aßmus <superstippi@xxxxxx> wrote: > > > > > The current API is also more or less fixed to B_CMAP8. > > > Not at all. At least not the one from BNodeInfo. > > That's actually what I meant: the BBitmap is created by the caller, > > and therefore, it's always B_CMAP8 - if you wanted to change just > > that, all applications would need to be updated to have the desired > > effect. > > If the bitmap was created inside the API implementation, all apps > > would directly benefit from that change. > I think you're overstating the "all apps" thing a bit much... I > personally can't think of many "abandoned" apps that draw icons. I I didn't just mean abandoned apps - I just really mean *all apps* that draw icons. > wrote some code to get icons for downloads in firefox, but that would > be very easily changed to grab a 32bit icon. NetPositive is in fact > the > only app I can think of that would be affected. There are lots of apps that draw icons in some places, but changing the color space would probably not pose a lot of problems for them - the icons would just look worse than usual, so it might be acceptable. > I'm personally a big fan of small icons anyway - I would almost > certainly keep my desktop icons at 32x32 and have tracker windows in > list view with the mini 16x16 icons. Certainly at these small sizes I > think hand-tuned bitmaps work much better than vector graphics. Definitely. > I don't see any reason why R1 couldn't also support BEOS:M:STD_ICON > and > BEOS:L:STD_ICON with higher colour depths reading through your mail. > Then if GetTrackerIcon is passed a CMAP8 bitmap it could do the > conversion. Alternatively I suppose 32bit versions could be stored in > different attributes and GetTrackerIcon could pick which one to load > based on the colorspace of the bitmap the caller passed in. I would rather have only one attribute for this - since it currently contains plain data (without any header), the size of the attribute would need to determine what kind of data the attribute contains - if it's 32*32 = 1024 bytes long, it would be a plain data 8 bit image; if it's any other size, it should have a header that describes the data first. Of course, this would break compatibility with all apps that read out the attribute directly, if any. > Tracker/Deskbar are obviously the big two as far as icon display is > concerned, but changing them to ask for 32bit icons should not be a > big > job, if the sizes of the icons available are still the same (icon > placement logic wouldn't be affected). True. > I'm still hopeful 32 bit icons could be an R1 thing. "A more modern > R5" > is how I tend to think of Haiku R1, and icons are a big part of that > for me. Since the worst thing that happens are not so nicely "downsampled" icons, I think we could actually consider it for R1. Bye, Axel.