Still have same issue. If I understand right - first we draw to xw.buf and than copy it to xw.win. In this case should by XftDrawCreate(..., xw.buf, ...).
2013/1/19, Christoph Lohmann <2...@r-36.net>: > Greetings. > > On Sat, 19 Jan 2013 15:03:27 +0100 Mihail Zenkov <mihail.zen...@gmail.com> > wrote: >> 2013/1/19, Mihail Zenkov <mihail.zen...@gmail.com>: >> > 2013/1/19, Christoph Lohmann <2...@r-36.net>: >> >> Please all report back of any performance issues in st not using >> >> xdbe. >> >> You can easily enforce Xdbe by commenting out the lines that query >> >> for >> >> the Xdbe extension and reset the xw.buf. >> > >> > With radeon-kms it show empty black screen with flickering on refresh >> > with usedbe = False and usedbe = True. >> >> Fix for this behavior: >> -xw.draw = XftDrawCreate(xw.dpy, xw.win, xw.vis, xw.cmap); >> +xw.draw = XftDrawCreate(xw.dpy, xw.buf, xw.vis, xw.cmap); > > I pushed a patch to the st git repository which activates the XCopyArea > double buffering to st. In my first tests this is spaking the CPU usage > of X11, which is because it is not handling special cases and simply > does redraw if something new happens. > > Please guys try this out. Of course I will remove this in some commits > so people having the dbe extension will use this fast drawing in the > next st release. > > I still need some easy way to do the double buffering on my side without > doing too many X11 calls. > > It is really annoying to have to assort to hacks in X.org for something > that should be implemented in the graphics subsystem itself. Just give > be a buffer and I will tell you when to swap but please handle every‐ > thing else on your own. That’s what dbe does, but more hacks interfere > with other hacks (Xinerama) which do hacking hacks in hacking the hack > hacks. > > > Sincerely, > > Christoph Lohmann > > >
