> > 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 ) Best. > > -- > ------------- 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
