On 4/4/11 12:15 PM, Nathan Kidd wrote: > a) M7 tries to XCopyArea from a GLXPixmap-backed Pixmap to a regular > Pixmap; this isn't supported by XCopyArea. This is worked around by > using PutImage to emulate the copy.
This seems like a valid approach. > b) M7 copies a GLXPixmap to only part of a destination window. This > gives wrong results; you'll get black pixels from the freshly > initialized pbuffer overwriting areas of the window not included in the > copy, because current XCopyArea only knows how to push a full window. > The PutImage path is also used to fix this case. I don't understand why. The glCopyPixels() command in XCopyArea() should be copying only the range of pixels specified by src_x, src_y, dst_x, dst_y, w, and h. > c) M7 does MakeCurrent(0,0) before calling XCopyArea, also not supported > by the current XCopyArea hook. This is worked around by creating a new > temporary context if necessary. This should really be implemented by using (possibly extending) the tempctx class, IMO. > d) M7 destroys the GLXPixmap before calling XCopyArea on the associated > Pixmap; a questionable practice probably left over from the days when > you could do 2D X drawing over a GLX drawable without problem. This is > worked around by deferring GLXPixmap deletion till Pixmap deletion. (My > NVIDIA driver + X.org gives a race when trying to do the XCopyArea, a > race that M7 always seems to win when run on the console but my test app > can occasionally loose, and VGL always seems to lose.) Seems reasonable. > That's the context for the following patches. However, I'm mostly > posting them for discussion. I don't really like how ugly XCopyArea is > getting. I think it is better, cleaner, and at least as performant to > just push GLXPixmaps to the 2D X server. (In fact, I think it should > generally be faster, especially since PutImage will be slow for those > not using an X Proxy that compresses.) Also XCopyArea and XCopyPlane > will just work without intervention. As it is we don't support > XCopyPlane at all. > > > Comments and discussion most welcome. If there are no issues I've > missed, I plan to start down the push-glxpixmap-to-2d-xserver path soon. Pretty much everything in VirtualGL is ugly, by necessity. Having to preload it into an app is ugly, but that's the only way we can avoid indirect OpenGL rendering and avoid having to provide a complete OpenGL and GLX implementation. Our handling of visuals is ugly, but that's the only way we can split GLX 1.1 and X11 command streams. Regardless of how ugly XCopyArea() may or may not be, I don't know of another way to implement it and still support X servers that lack GLX. I realize that your company doesn't care about TurboVNC, but that's still the most popular X server on which VirtualGL runs, so I cannot accept any solution that removes functionality from that environment. Pixmaps may be faster when rendered on an X proxy that supports GLX, but of course not all of them do, and we also have to support the remote X server case, in which rendering the pixmap on the 2D X server will almost certainly not be faster than VirtualGL's approach. IMHO, it also seems like a bad use of time to go to a lot of trouble to support Pixmap rendering the "right" way, when it is really an obsolete approach to 3D rendering. We need to fix VGL with the specific app, then get on with our lives. I think that, with a little bit of work, I can remove some of the complexity from this patch. I do, however, need to get a copy of the app for testing and get a better understanding of how exactly it was failing before you made these modifications. As far as rrfakerut, it is what it is. I don't think it's fair to call it "half baked". It does require a bit of expertise to use, but it is the only way I currently have to try to guarantee that a new patch doesn't break something else. I will look at these patches post 2.2.1. I will definitely need to modify rrfakerut to test the functionality. Will keep you posted. ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
