Optimally this would be done completely with OpenGL using pbuffers and texture hardware.
Alex --- Mark Vojkovich <[EMAIL PROTECTED]> wrote: > Current XAA only supports rendering to a single surface where the > location to draw at is indicated by pDrawable->x and pDrawable->y. > It doesn't know anything about alternate storage locations for > windows. > And it probably blows all the GC validation out of the water because > drawables that it previously thought were always in hardware > (windows), > are now possibly in system memory. My first impression is that > expecting GCOps to redirect to Pixmaps is the wrong implementation > and the Window->Pixmap redirection should have happened transparently > in a wrapper higher up. Also, how is OpenGL supposed to work with > something like this? > > Mark. > > On Thu, 20 Nov 2003, Michael Matz wrote: > > > Hi, > > > > [please leave me CC'ed, I'm not (yet?) subscribed to this list] > > > > I ported over Keith Packards new extensions (COMPOSITE and DAMAGE) > from > > the freedesktop Xserver to Xfree86, which seems to have worked more > or > > less. See http://ktown.kde.org/~matz/BuntX.png which shows XFree86 > on a > > mga card, with those extensions (plus XFIXES) and xcompmgr running > for the > > translucent windows with shadow. To make this work I had to > disable XAA, > > though (i.e. "Accel" "off"). > > > > If I leave it on, the windows content is totally off (i.e. I get > shadows > > around where the windows logically are, and I can move them, just > the > > content shows a mixture of background from somewhere else, or > anything, > > just not the real content). > > > > The way COMPOSITE works is by allocating a Pixmap for each toplevel > > window, and setting it with pScreen->SetWindowPixmap. It then > expects the > > rest of the xserver to render into these pixmaps for all normal > render > > requests, and provides a mean to copy those pixmaps back to the > screen > > (possibly in fancy ways). > > > > Of course this will be fast only if that pixmap lies in offscreen > > video-mem and the graphic chip is used for rendering into it > (although > > theoretically it all works if it's somewhere else, it just becomes > > slower). > > > > So, when XAA is active, one of the following things goes wrong: > > * it doesn't render into the window pixmap > > * it's not able to correctly blit back the window pixmap to the > screen > > * something else ;) > > > > My question: is XAA supposed to handle the case of rendering into > such a > > pixmap tacked to a window at all, or do I have to implement some > magic > > there? I looked at xaa/*.c but I have some difficulties > understanding all > > the different kinds of indirections ;-) At least I couldn't find a > > definite place where the rendering GCOps would look at > GetWindowPixmap, > > like for instance the fb driver does (through the use of > fbGetDrawable). > > > > In a first iteration I would probably already be satisfied if not > the chip > > is used to render into the pixmap, but simply calls into the upper > layers > > of the server to do that, i.e. basically > > > > Graphical-xaa-op (drawable) > > if (drawable == WINDOW > > �&& drawable-has-window-pixmap) > > return call-upper-op (drawable->GetWindowPixmap); > > /* or call-upper-op (drawable) ? */ > > do accelerated stuff on drawable > > > > Is it indeed the case that this isn't expected by XAA at all > (although the > > possibility of having a window pixmap is already in the server > before > > Keiths additions, Get/SetWindowPixmap seems to be part of XFree86 > since > > 1998). > > > > Sorry if those are stupid questions, I'm a GCC hacker in my day > job, I > > just have vacation ;-) Someone wants to lend me a helping hand? > > Btw. my current patch is at > http://ktown.kde.org/~matz/fdo-2-xf86-5.diff . > > > > > > Ciao, > > Michael. > > > > __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
