> It's the best we can do. I'm not going to compute the >clips in two passes: one to find out how many rects there >end up being, and one to store the rects.
At least you would be able to indicate the last one which would serve the same purpose. Or an optional "flush" call to the driver. A batching driver could queue stuff up until a flush. A flush would happen after a set of operations that originated as a single complex drawing operation. > XAA doesn't care about surface particulars. It asks the driver >if it could stick this pixmap in videoram for it because the migration >logic says it should go in videoram. The driver can refuse or can >accept by returning an XAASurface for it. XAA passes that surface >back to you in the SetupFor function. To XAA, it's just a device >independent structure. The driver has private storage in the >XAASurface. Sounds reasonable. > > How does X tell the driver what the surface will be used for? A > RENDER surface could have different alignment or tiling properties > than a 2d only surface. That information would be needed at > allocation time. >> There's no such thing as a "RENDER surface". Pictures are merely >>X-drawables with extra state associated with them. Any drawable can >>eventually be used as a picture. You will need to keep that in mind >>just as you do now. This has pretty serious implications. Currently the memory manager uses rectangular memory which presumably has pitch etc characteristics that are usable by the stretch blit/alpha blend components of a chip. That makes it reasonable (although probably not ideal) to assume that any offscreen surface can be used for RENDER purposes. Moving to a surface based infrastructure would allow a driver to more carfully choose surface parameters... always choosing the worst case alignment,pitch, etc characteristics seems like a problem. This may be a RENDER problem and not just an Xaa problem, but it seems like there really needs to be prior indication that a surface is being used as a RENDER source or target such that the memory manager can make appropriate choices. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
