On Fri, 8 Jul 2022 15:59:57 GMT, Alexey Ivanov <[email protected]> wrote:
> This sounds reasonable… until you take into account the fact the `Icon` or > `ImageIcon` has no reference to a component. When the icon is requested, the > scale at which will be rendered is unknown. Correct. > When an icon is rendered and the required variant does not exist in the MRI, > there's no way to fetch it asynchronously: the icon can't make the component > repaint because there's no reference to the component. The drawImage method takes the observer, which can be used to trigger repaint when the new image is reloaded, this is how the animated gifs are rendered in our components. > The only optimisation that I see is to request only the size which correspond > to the current monitor scales. If a different size is needed, a synchronous > call to COM thread is required; and for this the icon must keep the path to > the file. You missed the point that the goal of that fix was to provide the icons for the file(eventually be a kind of wrapper for "Extract"), the possibility to render them in HiDPI is a side effect. So we should be able to do both: * If the user request the list of variants we should provide the list of icons we are able to load from the file, but the API is flaky to get the actual list of * If the Icon is rendered to the image we may load the icon of the different DPI. ------------- PR: https://git.openjdk.org/jdk/pull/7805
