Since 5.5.5 window image:preview is too translucency

[unera]

Steps to reproduce

Debian/11
5.5.5 (static)

Expected behaviour

See above

Actual behaviour

For example I see an image in chat:

If I click, I see something soap:

Operating system

Debian/11

Version of Telegram Desktop

5.5.5

Installation source

Static binary from official website

Crash ID

No response

Logs

No response

[unera]

Example 2 (chat):

Preview:

[unera]

Addtitonal, 5.5.4 work fine :)

Chat:

Preview:

[unera]

So at my system

• 5.5.4 - works fine
• 5.5.5 - image preview is too translucency (unusable)
• 5.5.6 beta - image preview doesn't work, see Telegram desktop doesn't work imageclick #28462

So, I disabled autoupgrade system in my 5.5.4 version

[ilya-fedin]

Can't reproduce any of three. Media viewer works just fine.

[unera]

Can't reproduce any of three. Media viewer works just fine.

see screenshots

[ilya-fedin]

see screenshots

And? I can't confirm it happens. Without a way to reproduce the issue couldn't be worked on.

[unera]

see screenshots

And? I can't confirm it happens. Without a way to reproduce the issue couldn't be worked on.

1. I have Debian/11 & Telegram
2. I have some problems that are appeared since latest upgrades (5.5.5, 5.5.6 beta)
3. Downgrade solves the problems
4. All problems touche image:preview

So I think that You could look through code changes, that touche image:preview?

Also If You say, I could try any experiments, note library versions, logs, etc.

[ilya-fedin]

So I think that You could look through code changes, that touche image:preview?

There were no code changes that touch it
v5.5.4...v5.5.5

[unera]

So I think that You could look through code changes, that touche image:preview?

There were no code changes that touch it v5.5.4...v5.5.5

I can't understand C++, so it would be nice if You help me

Situation:

• 5.5.4 works
• 5.5.5 has problems
• 5.5.6 has more problems than 5.5.5

What (as user) I could do?

[ilya-fedin]

I recommend reproducing on a VM. You will likely find which steps to reproduce are lacking while doing that.

[ilya-fedin]

I will also honestly say no one tests tdesktop with Debian. Personally I use NixOS with Plasma 6 Wayland and have a VM with KDE neon user edition, @john-preston uses WSL. Previously he tested with Ubuntu 22.04 in a VM but not sure he does that now.

So it might be just that your distro/DE is incompatible with what tdesktop is tested for and it might be a good idea to switch to another one for stable work with tdesktop.

There are no resources to test more distros/DEs, sorry.

[kolayne]

Good evening.

@ilya-fedin, I am having a similar issue (except not yet in version 5.5.5) on my Arch Linux, with i3 version 4.23, picom version 11.2 (vgit-89c2c).

I've tried bisecting. The last good commit is 7abc921, then two commits follow for which the build is failing, and then 3f6d184 is the first bad commit.

Looking at the changes manually, I presume, the actual reason is the commit 4a84f9f, which updates the lib_ui submodule

[ilya-fedin]

The initial reporter claims this problem is since 5.5.5 while this commit is way later than 5.5.5?

[ilya-fedin]

It feels to me that the problem in your compositors or drivers as I can't reproduce anything like that with any version on my Plasma system

[kolayne]

The initial reporter claims this problem is since 5.5.5 while this commit is way later than 5.5.5?

That's surprising for me as well. Like I said, version 5.5.5 works fine for me.

the problem in your compositors or drivers

Huh! In my laptop I have an nvidia video card with the 560.35.03 nvidia driver installed and NVidia Optimus enabled (that is, by default applications do not access the discrete video card).

I have first tried to uninstall the drivers (and reboot) and the issue persisted, then I tried to install the drivers again and run prime-run ./Telegram which would make it use the discrete video card and the issue was gone!

(examining prime-run on my system and running with different options, I found that the environment variable __GLX_VENDOR_LIBRARY_NAME=nvidia is the necessary and sufficient one)

I'm surprised. Does that tell you anything?

[ilya-fedin]

It means the issue in the driver and nothing could be done about it...

[kolayne]

Two more observations:

• The problem is introduced in desktop-app/lib_ui@1dec2a1. Telegram Desktop compiled with a version of lib_ui before that commit doesn't have this problem
• Disabling the "Enable OpenGL rendering for media" in the "Advanced" settings fixes the regular Telegram Desktop version (@unera, I would recommend you to try the same)

[ilya-fedin]

Had the window transparent background before? That window is supposed to have transparent background and the commit you refer fixes applying the transparency hint in OpenGL case (previously it had random success of being applied). If your driver can't handle transparency properly, nothing could be done about that.

[kolayne]

No, the media viewer background was not transparent.

If your driver can't handle transparency properly, nothing could be done about that.

Well, generally, both my driver and compositor support transparency, as I have other applications with transparent windows rendered correctly. But I am not sure whether they are using OpenGL

[ilya-fedin]

Even if they use opengl, they likely use other toolkit and that's likely specific to how the driver and the toolkit interact