On Tue Feb 4 12:08:42 2025 +0000, Rémi Bernon wrote:
One thing that I'm not sure about is how we handle alpha in the visual. I don't think systray window visual necessarily has alpha channel, but I believe we need to use the exact visual of the embedder window for our systray windows. Maybe we should check more precisely whether systray visual has alpha or not, and select the xrender format accordingly? Specifically, this line https://gitlab.winehq.org/wine/wine/-/merge_requests/7255/diffs?commit_id=38... is different from your version.
I am not sure if the change will work, why do you think it is better (and probably it won't work at least for a generic case)? Not sure why is_wxrformat_compatible_with_visual has to be so unobvious and depend on given visual id matching default for some reason, can't we just match argb visual with argb and non-argb with non-argb?
In the case when it is failing systray visual has alpha. But my idea of going this way was not making any assumptions on systray in xrender part and just not break on argb visuals.
On a separate note, the argb visual goes away now (and triggers blit to X window) for multiple reasons, at least: - any resize (get_default_visual will get dummy visual in this case and alpha_mask will be lost); - driver's CreateWindowSurface is called with only create new layered (meaning ULW) surface but previous surface status is not relayed; - win32u and winex11.drv do not agree a bit whether window should have surface or not. winex11.drv assumes that ULW window should have a surface regardless of child window presence (which I think is correct; on Windows 3d drawing doesn't go anywhere onscreen with ULW window and it should have a surface regardless of pixel format or 3d rendering present). But win32u disagrees and thinks if a window has pixel format it never should have / use a surface (and sometimes it thinks the same for Vulkan surface presence but those cases do not exactly align).
I tried making a patch of straightening this up but it pulls more things around and probably explicit tracking of style change and ULW / SLWP layered windows explicit distinction, I didn't finish that. But if we agree that having blits to argb visual is beneficial anyway (while solves the present regression), I guess it should not make assuptions in that part about how do we get the argb visual, would it be default argb visual or the one for systray.