On Sun, 24 Mar 2002, Andreas Beck wrote:
> "Brian S. Julin" <[EMAIL PROTECTED]> wrote: > > > In the case of x vs xlib, it strikes me that the back-buffer/flushing > > behavior and the Xlib accel behavior could cooexist happily as two > > options in the same driver, what when both enabled would provide > > the best performance in the genaral cases (same host or network). > > In principle yes, but you's need to sync the framebuffer contents with > the accelerated drawing operations as well, as otherwise the next > flush would overwrite already drawn contents. > > > In the case of the DGA target, it appears to me that XQueryExtension() > > is a core Xlib function and could be used to enable/disable DGA support. > > Default behavior would then be to check to see if DGA will work, and > > if not, simultaneously draw in memory and using X primitives and > > turn on flushing if/when the directbuffer is aquired. > > Ah - I see. On IRC we (Brian and I) decided to create a bunch of helper-targets for the X one. For example, a helper-xsync using the SYNC X extension can replace the mansync helper, _if_ available. Having a helper-xbuffer target adds the functionality of the buffer X extension. It provides double-, multi- and stereo-buffering. The double/multi-buffer feature can be used for having _real_ directbuffers. The other features can be used in libgalloc/libbuf. Specifications of all _standard_ X extension can be downloaded from: ftp://ftp.x.org/pub/R6.6/xc/doc/specs/Xext/ I just don't know how he will structure the directories. Too many x-helpers shouldn't be in the display root directory. They should be in a sub-directory inside the x-target instead. The point is, I won't flood the display directory causing us loosing the overview, even when we make a 'ls', for example. Brian: Does GGI extensions X/Xlib-target (libggimisc and libwmh) require an update then? If yes, will it be a small task? Andy: libwmh is your baby AFAIK. In case of an required update and while you are about it then, you can write a helper-xshape target, which allows us to have windows with rounded corners, for example. :) > > Does someone know the original reason why the DGA target kept a private > > implementation of the XFDGA protocol extension? > > This is due to a horrid versionning nightmare while the XFree 3->4 > Transition, where we found that many systems had broken headers and would > not compile right. CU, Christoph Egger E-Mail: [EMAIL PROTECTED]
