On Fri, 10 Jun 2022 12:22:45 GMT, Alexey Ivanov <aiva...@openjdk.org> wrote:
> How would you implement this? > I mean the user requests the icon in user's space (right?). On a High DPI > system which may change in runtime, a larger icon version is required for > rendering. To get a larger icon from native, we have to keep the file name or > PIDL and call shell interfaces on COM thread to fetch the icon. > Overall, I like the idea… We may have discussed it. Keeping only sizes that > are needed will reduce the memory usage. All in all, it's definitely out of > scope for this fix. That was the whole purpose of the initial 8182043 issue, to provide a HiDPI(or various DPI) icons for the user. If the user asks for the 16x16 we will provide them the MRI where the base image is 16x16, but that MRI could also provide large images by request. If that 16x16 image renders on scale=1.25 then the MRI should generate the image which looks good on that screen. This current proposal generates it on the fly using java code, but I think it should request that information from the native system, this was the purpose of the new getSystemIcon(file,w,w) method. We do not need to always request the icon via COM thread, we can initially load the low dpi image, or the image for the main screen scale, then if the scale changed we can request to load the HiDPI image, and use it when ready. The wondering why it looks bad on some DPI is actually proves that the previous fix has some limitations. ------------- PR: https://git.openjdk.org/jdk/pull/7805
