fix: preserve PNG transparency in chat wallpapers

[pratikpatel8982]

Respect the user's chosen image as-is without forcing opacity, which naturally enables transparent chat background support.

fixes #29773

[CLAassistant]

All committers have signed the CLA.

[ilya-fedin]

Did you actually test it? The server accepts only jpegs so it will lose the transparency anyway, all you likely did is that the transparency will turn black instead of white.

[pratikpatel8982]

Did you actually test it? The server accepts only jpegs so it will lose the transparency anyway, all you likely did is that the transparency will turn black instead of white.

yes i tested it, the chat backround wallpaper is chosen through the chat settings,
and by setting forceOpaque=false the pipeline preserve transparency of the chat background.

1. The option Choose from File has its own file-chooser method inside settings_chat.cpp and this option was tested by me.
2. However Choose from Gallery option further expands to gallery and another Choose from file option which is taken from background_box.cpp. This was added later and is untested. However it should work the same cause they both call the same method and later go through the same pipeline.

Here is the image, a fully transparent png which was used for testing.

Here is the result: half screenshot of chat window.

here is the compiled app (linux)+ the transparent png used: https://gofile.io/d/30Ludp
It also supports semi-transparent images.

[pratikpatel8982]

any feedback??

[ilya-fedin]

any feedback??

I couldn't speak for sure (I believed it's not possible due to jpegs after all) but my knowledge of platform differences make me think it's not intended to work. Generally, tdesktop's window is opaque and only on Linux, due to no system APIs allowing to use system shadows with custom titlebar, the window is transparent. And if such API ever appear or even an API to set opaque region (allowing only client-side shadows being actually transparent), making use of it will make the window opaque, just like on other platforms.

[pratikpatel8982]

I couldn't speak for sure (I believed it's not possible due to jpegs after all) but my knowledge of platform differences make me think it's not intended to work. Generally, tdesktop's window is opaque and only on Linux, due to no system APIs allowing to use system shadows with custom titlebar, the window is transparent. And if such API ever appear or even an API to set opaque region (allowing only client-side shadows being actually transparent), making use of it will make the window opaque, just like on other platforms.

That makes total sense, and I completely agree regarding the future of Linux window APIs. If an opaque region API ever gets adopted and tdesktop switches to it, this will naturally break and revert to behaving exactly like Windows/macOS.

However, since this PR just flips forceOpaque to false and doesn't add any new rendering logic or UI toggles to maintain, it essentially acts as a zero-cost Easter Egg for current Linux/Wayland users with transparent PNGs. Standard JPEGs still render perfectly as opaque backgrounds.

Also can test on windows, if someone is willing to share compiled application. And the application preserves image transparency at every step, just forces opaque at last probably due to server restrictions.

Happy to leave it up to you if you think it's worth merging for the time being, or if you'd prefer to keep the forced opacity!

[ilya-fedin]

If an opaque region API ever gets adopted and tdesktop switches to it, this will naturally break and revert to behaving exactly like Windows/macOS.

AFAIK opaque region API just tells the compositor that it doesn't have to repaint on transparent regions, so we essentially will get into a situation that people will start complaining about buggy rendering if this is merged.

[pratikpatel8982]

That makes perfect sense. If tdesktop adopts an opaque region API in the future, the compositor won't know to repaint the desktop behind the transparent PNG pixels. That would definitely result in un-cleared buffer artifacts and smearing.

Since relying on the current lack of that API creates technical debt and a risk for future bug reports, I completely agree we shouldn't merge this upstream as default behavior. Thanks for taking the time to explain the compositor interaction!

If we still want to try supporting this, I can wrap this forceOpaque logic behind an experimental toggle in the settings. That way, it remains strictly opt-in with a warning, and standard users are completely unaffected.

Let me know if you'd be open to an experimental toggle. Otherwise, feel free to close this PR to save yourself the upstream maintenance headaches! I'll just keep it as a local patch for my own setup and propose it to forks like AyuGram instead.

[ilya-fedin]

Let me know if you'd be open to an experimental toggle.

I can't decide that, you have to ask preston

[user123456000]

Should we ping him here?