On Tue Feb 4 16:30:45 2025 +0000, Paul Gofman wrote:
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.
I. e., I think ```
if (fmt->alphaMask) return FALSE; if (fmt->alphaMask && visual->visualid == default_visual.visualid) return FALSE; return TRUE; ``` is very unobvious as best. If there should be an exception for handling default_visual which I missed in my patch that should probably be done in load_xrender_formats()?