On Fri, 17 Sep 2021 09:29:36 -0300 Thiago Maciel <mac...@gmail.com> said:
> > > > they do things differently. e reduces the pixmap to be EXACTLY the client > > window area. this means that if the driver is optimized it can skip a copy > > from > > back to front buffer and convert it to a swap/exchange of buffers because > > pixmap == exactly the opengl backbuffer size. my guess is because e tries > > to do > > this to get the optimum result we hit an optimization path (that is > > intended) > > and this path is broke.buggy and almost no other compositors hit it because > > they have the gl window offset within a parent window with borders. at > > least > > with a window that has borders or at some point had borders. > > > > As always, very informative, Raster! > I am not versed on the GL abstraction layer used by e, but, reading above, > I remembered that gnome-shell had a similar problem some years ago (cf. > https://bugzilla.gnome.org/show_bug.cgi?id=690451), > and It is still on NVIDIA's driver documentation ( > https://us.download.nvidia.com/XFree86/Linux-x86_64/470.63.01/README/knownissues.html > ) that's not the same issue though... this blit is entirely internal to the xserver when drawing from backbuffer to the window. a blit is a full copy of all that data which is not cheap for any decent resolution. (a 1080p screen at 60hz requires 460MB/sec of bandwidth alone). -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
