We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3559

Summary: SDL_SetWindowIcon producing messed up icon
Product: SDL Reporter: Daniel D'Agostino <dandago>
Component: *don't know*Assignee: Ryan C. Gordon <icculus>
Status: RESOLVED INVALID QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2    
Version: 2.0.5   
Hardware: x86_64   
OS: Windows 10   
Attachments: This is the window icon as rendered.
Rendered icon after fixing Uint16 -> Uint32

Description Daniel D'Agostino 2017-01-15 21:34:31 UTC
Created attachment 2678 [details]
This is the window icon as rendered.

Quoting from: https://forums.libsdl.org/viewtopic.php?t=12277

"I've come across a weird issue with SDL_SetWindowIcon(). I am creating a surface from pixel data that I already have available, using SDL_CreateRGBSurfaceWithFormatFrom(). I know that the pixel data is correct because I'm rendering it in my game, and I know the surface I'm creating from it for the icon is valid because I tried saving it to a BMP and the image was created perfectly. 

"But when I pass the same surface to SDL_SetWindowIcon(), I get a garbled mess."

When loading from a BMP, it works fine.

Repro project is here: https://bitbucket.org/dandago/experimental/src/35ab7d960e5461cfaf9fdee3bf37d9179f8de4cd/Sdl2WindowIcon/Sdl2WindowIcon/main.cpp?at=master&fileviewer=file-view-default

Attached is the icon I'm seeing as a result of this code.

I adapted the code from the sample at: https://wiki.libsdl.org/SDL_SetWindowIcon

The sample itself works - it's using just 4 bits per channel - whereas I'm using a byte per channel.
Comment 1 Daniel D'Agostino 2017-01-15 21:42:59 UTC
Created attachment 2679 [details]
Rendered icon after fixing Uint16 -> Uint32
Comment 2 Daniel D'Agostino 2017-01-15 21:44:22 UTC
(In reply to Daniel D'Agostino from comment #0)
> Created attachment 2678 [details]
> This is the window icon as rendered.
> 
> Quoting from: https://forums.libsdl.org/viewtopic.php?t=12277
> 
> "I've come across a weird issue with SDL_SetWindowIcon(). I am creating a
> surface from pixel data that I already have available, using
> SDL_CreateRGBSurfaceWithFormatFrom(). I know that the pixel data is correct
> because I'm rendering it in my game, and I know the surface I'm creating
> from it for the icon is valid because I tried saving it to a BMP and the
> image was created perfectly. 
> 
> "But when I pass the same surface to SDL_SetWindowIcon(), I get a garbled
> mess."
> 
> When loading from a BMP, it works fine.
> 
> Repro project is here:
> https://bitbucket.org/dandago/experimental/src/
> 35ab7d960e5461cfaf9fdee3bf37d9179f8de4cd/Sdl2WindowIcon/Sdl2WindowIcon/main.
> cpp?at=master&fileviewer=file-view-default
> 
> Attached is the icon I'm seeing as a result of this code.
> 
> I adapted the code from the sample at:
> https://wiki.libsdl.org/SDL_SetWindowIcon
> 
> The sample itself works - it's using just 4 bits per channel - whereas I'm
> using a byte per channel.

Had a small mistake in the code with Uint16 that should have been Uint32.

See updated repro code here:

https://bitbucket.org/dandago/experimental/src/792b14862ea211d3dda46e0a3bb3bb335ba3a12a/Sdl2WindowIcon/Sdl2WindowIcon/main.cpp?at=master&fileviewer=file-view-default

Also attached updated icon screenshot.
Comment 3 Sam Lantinga 2017-01-16 21:55:38 UTC
You're specifying a pixel format with alpha and passing an entirely transparent image. I've verified that if you specify a format without alpha e.g. SDL_PIXELFORMAT_RGB888 or set the alpha channel to 0xFF that the icon shows up as expected.

I've also checked and the pixels that you're providing are making it untouched to the Win32 API functions. I'm not sure why those API functions are mis-handling the pixel data if there isn't alpha channel data, but it may be legacy handling in the APIs. If you set even one pixel with an alpha value, the icon shows up as expected.