On Tue Jul 9 11:52:47 2024 +0000, Alexandros Frantzis wrote:
Always using ARGB8888 is not very efficient, both due to the overhead of manual alpha handling (i.e., the copy_pixel_region changes) but also because it disables some potential optimizations on the compositor side. We could help the compositor regain some of these optimizations by using wl_surface opaque region hints. In the experimental branch I had implemented a dynamic switch between XRGB and ARGB depending on window shape and translucency needs, which allowed more efficient copy pixel handling, so this is also a possible avenue to explore if we find the extra complexity to be worth it. In any case, I don't mind this change as long as we are aware that there are performance concerns we can improve on in the future.
Does it affect performance of GL/VK surfaces too or just the performance of basic window surfaces?