That wouldn’t explain the change over time.
I am noticing it now in my other apps as well. The coloring discrepancy is more subtle but you can clearly see the larger images have a darker shade of orange than the lower resolution ones.
Do you use source control? If Xojo is constantly changing the icon, you’d see the .xojo_resources file being changed.
Unfortunately I only have platform licenses so I am strictly binary.
What if you reimport just one of the large icons? It would be nice to see the difference, if there is one, and also curious to see if the new icon gets degraded.
How long did it take for this set to show the degradation?
Another project where this is happening. I created this icon March 12, so this color degradation has been over the last 10 days.
Feedback case 75921: https://tracker.xojo.com/xojoinc/xojo/-/issues/75921
@Christian_Wheel I have several projects that have icons and I’m not seeing any color degradation over here. But in your issue report you mentioned…
All these icons are from the identical source image
…and this is quite a bit different than my own setup/workflow which could explain things. If I’m understanding correctly, you have a single image file that you’re plopping into each image size and letting Xojo do the sizing, correct? This might explain the situation as it smells like a Xojo bug within the resizing of the image.
On my side, and this might be a workaround for you if my hunch is correct, I have distinct files for each file size (PNG) so that Xojo doesn’t do any of the resizing. It’s a bit more of a hassle of course, but I personally do this because for some of my icons I actually reduce image complexity at the lower sizes to make them easier to see.
Alternatively, for my macOS target, I have a copies files build step that copies my App.icns to the Resources folder. You might be wondering why I have such a build step if my app images are working correctly. The reason is because under macOS, the current OS look and feel via Apple’s design guidelines has quite a bit of padding (aka negative space) around the icon. If used under Windows, the icon ends up looking “small” in comparison to other apps. So I’m using Xojo’s GUI App Icon settings for my Windows icons (e.g. full edge-to-edge images) and then simply replacing the App.icns in my macOS bundle to make things look correct over there. If you’re just targeting Apple devices, this might be a quick and easy work around for you and you could forgo using any part of the Xojo GUI App Icon dialog.
This have the adventage to lower (or not enlarge) the project file, speeding up the Open and Save processes…
Why don’t you try that on one Icon to see if there is a difference ?
PS: I already suggested that 26 days ago.
Thanks guys,
I build for both Mac and Windows, so while copying an icns file might solve it for Mac, I need the Xojo icon editor to work for Windows. There are ways to replace the resource for Windows too but that’s a lot to have to deal with for every build.
I have since switched to dedicated 1024, 512, 256 and 128 images and will report back if the color degradation continues.
1 Like
so, you cannot add OS specific code to add .icns for MacOS and .ico for Windows at their due location ?
Even for a try out ?
I’d put my money on the color profile as was discussed above. Have you tried using GenericRGB instead?
1 Like
Color profile should cause ONE distortion, not a progressive distortion over time. Progressive distortion means that Xojo is reencoding/reprocessing and saving “the new result” and reusing it on the next project load multiple times, and that is a bug. A resource should be imported and frozen as it is until changed by the user.
1 Like
Windows doesn’t have a due location, it is embedded in the binary as a resource. Since I build for Mac and Windows at the same time, I replace the icon within the Xojo IDE every build to avoid degrading the color for the Windows build anyway.
I can confirm that the icns file that Xojo puts into the MacOS build is improperly colored and manually replacing it corrects the app icon, but then it needs to be re-signed and re-notarized.
I also have been unable to replicate the issue using the Windows version of Xojo. I built a WinAutomation script that:
Adds an extra line of comments to a test file, runs a debug build, terminates the build, saves the xojo project as to a different path, closes the project, re-opens it, and loops this behavior.
After 1000 iterations on Windows, the icon color remained correct in the project files.
I do most of my development on Mac, however.
I have never used Automator on Mac but I will try to set up a similar experiment when I get the chance.
The most recent icon (the purple one above), is a generic RGB profile and the degradation still occurred.
Have you contacted Xojo about this bug?
It is pretty serious, and I’ve gotten the distinct impression that Xojo don’t participate in their own forum anymore.
If there’s no way to replace the Windows icon after build with a post-build processor like App Wrapper, then you may be SOL until Xojo can/do fix this issue. I seem to recall many years ago that InnoSetup could be used to install a Windows ICO file, but that was over 20 years ago now.
1 Like
An Issue is open, the problem is that OP can’t reproduce the problem in a sample project and can’t share the app that has the problem. As this is not a general problem (no one else has seen it) it may be hard to replicate/fix. I hope an engineer can have an idea.
It’s easy to know the cause just reading the involved code. If you by any chance reencode/redecode the imported image after the initial import, save it, and reencode/redecode over again, you found the offending code. The original bits can be changing over time.
Christian should provide the original PNG for tests.
To verify the defect, the engineer can fast-forward the process making a 1000x loop simulating what Xojo does loading, presenting, saving the project and loading again… 1000x, and observe or not the degradation comparing original loaded bits and final resulting loaded bits.
