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.
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?
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.
These are some pretty cool advances! Thanks a lot for keeping HaikuDepot and HDS evolving!
It indeed makes HaikuDepot more reactive on low-end hardware, thank you for that.
There are, from times to times, people without developer skills asking how they could involve themselves in the project. We are often mentioning creation of icons for packages that don’t have one (at all) but we could also talk about creation of HVIF icons for packages that only have bitmaps.
If you authenticate into the HDS (web) application and navigate to menu … Reports … Package icon report, the resultant CSV data will tell you which packages need icons and what sort of icons are present for each package.
Somebody with sufficient authorization would then be able to authenticate and upload updated icons for the packages where there are updated icons available.
There is also a bulk-upload function that can upload icons from a tar-file, but that is a superuser-only operation.