On Fri, Apr 1, 2011 at 5:05 AM, Aaron Plattner <aplatt...@nvidia.com> wrote: > On Wed, Mar 30, 2011 at 10:21:42PM -0700, Dave Airlie wrote: >> From: Dave Airlie <airl...@redhat.com> >> >> This splits CopyWindow before the exa/fb layers, and uses a >> new interface called PixmapCopyRegion to do the actual copy. >> >> The main point of this is a step towards removing WindowPtr's >> from the interface that drivers see or use. >> >> I've only lightly tested this with Xephyr in fb and fakexa modes, >> but moving a window still moves and goes via the new paths. >> >> Open thoughts: >> a) exa should I restore the fallback hook for pixmapcopyregion >> instead of copy window? feeling I have is yes. >> >> b) should the hook take Pixmap or Drawable, it probably at least >> needs an assert if it takes drawable and gets passed a window. >> >> c) is PixmapCopyRegion a good enough name? >> >> uxa: left as an exercise for the reader. >> >> (not signed off yet). > > Is this what you were alluding to when you were talking about breaking the > overlay code? We wrap CopyWindow so we can blit bits of the overlay and > underlay surfaces around as appropriate. I guess this would translate to > two calls to PixmapCopyRegion on the overlay pixmap, and we'll just have to > figure out from the combination of pPixmap == overlay pixmap && > miOverlayCopyUnderlay that we're supposed to be copying pixels around on > the screen pixmap instead? >
Well I was thinking of adding an array of pixmapptrs to WindowPtr with an numPixmaps, as a future step, then getting rid of the GetWindowPixmap call tree, this would then iterate over all the pixmaps attached to the WindowPtr for these interfaces? I suspect we might need to pass a pixmap index maybe to the PixmapCopyRegion or maybe the driver can stash that somewhere. Ideas on a postcard? Dave. _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel