Haiku Depot and Better Icon Handling | Haiku Project

HaikuDepot displays icons through a number of areas of its user interface. Early in the history of the Haiku packaging system, there were very few packages and very few icons. HaikuDepot started off by downloading each individually from HaikuDepotServer.


This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/apl/2020-11-16_haikudepot_better_icons/
12 Likes

Thanks for these technical details! You’ve done an amazing job adapting HaikuDepot to the mounting requirements! HaikuDepot had its issues at times, but your changes addressed those effectively apparently, as I’m very pleased with its current performance.

Any more known bottlenecks on your list or other potential issues on the horizon?

1 Like

Thanks for your hard work!

thank you very much for your work… that’s great!

Thanks Humdinger and others – I am glad to hear it’s running smoothly at your end! I think with the growth in data, that there could also be a different approach taken on the server end delivering the material to the clients, but there is no hurry on that.

So this is just the package manager, right? How is it possible that there are enough icons that it’s not worth just keeping them all in memory while the software is open?

I see from looking at the tarball that quite a few of the “icons” are in HVIF format and yet some are PNGs with sometimes a 16x16, 32x32, and even 64x64 files that are separate. Surely if the format and file sizes were to be standardized that would help a lot? I mean the file sizes range from a few hundred bytes to as much as 30 KB+.

So this is just the package manager, right?

HaikuDepot is a desktop application. You can find out more about this application here.

How is it possible that there are enough icons that it’s not worth just keeping them all in memory while the software is open?

The icons might consume X bytes on disk, but once they are in memory then they are represented in a very different way so the memory consumption is larger. The quantity of memory is not really huge, but the system should be as efficient as possible and perform suitably on low-end hardware. By taking this approach, the memory consumption is consistently low.

I see from looking at the tarball that quite a few of the “icons” are in HVIF format and yet some are PNGs with sometimes a 16x16, 32x32, and even 64x64 files that are separate. Surely if the format and file sizes were to be standardized that would help a lot? I mean the file sizes range from a few hundred bytes to as much as 30 KB+.

It would be good if the icons were all HVIF. If HVIF is present then it is used in preference to bitmap formats. Some older software however only has icons available in bitmap formats. In this case the icon may be drawn quite differently at the different sizes. To support this, HDS supports storage and delivery of the different formats and sizes.

It is also worth maybe of interest that despite being deployed into a linux environment, HDS is also rastering the HVIF using an on-host tool and is not using bitmap icons for packages where HVIF is available.

1 Like