Around 17 o'clock on Dec 30, Owen Taylor wrote:
> * Optimized software/hardware suppor for compositing (pix_format=xBGR > mask_format=Axxx), (pix_format=RGBx, mask_format=xxxA) with pix and mask > pointing to the same buffer. Probably people with better > initial choices of formats would like to see xRGB/Axxx > added at the same time. These optimizations are pretty easy to add in software; the code all linves in programs/Xserver/fb/fbpict.c. If you have some existing code which operates on the datatype you use, send it along and I'll just plug it in. Adding appropriate formats is easy as well. With code in hand, I can add this to XFree86 4.2. > * Some way of compositing source data from memory without risk > of round-tripping it to the video card first, such as a > CompositeImage request I've thought quite a bit about how such a request would look; the main problem is that there are two source operands to the composite operator and I'd like to allow either (or both) to be provided over the wire. I'd also like to support image compression, likely using the basic compression stuff from PNG. How about magic XIDs for the existing composite operator which indicate that the data are inline (and, optionally, compressed)? The alternative is to add several new op codes, one for each combination of data. As you've noticed, it's nice to allow both source and mask data to come from the same image in different formats; that will mean additional magic is require to avoid transmitting the A separately from RGB in your non-premulitplied environment. The alternative seems to be to continue usin PutImage and to make the server smarter about video memory managment for pixmaps. One should avoid migrating image data across the AGP bus except when necessary. A scheme I've used in the past is to allow pixmaps to exist either or both sides of the bus; data are migrated when necessary (like copying to a window). Rendering can occur on either side of the bus, and possibly both depending on where the data are actively used. Ref US patent 6,006,238; (fortunately, that patent was carefully worded to refer only to networked environments (one does try)). > We can represent not premultiplied data in the framework > of RENDER by using the data both as source and mask, though > that's not possible with XFree86-4.1 and and seems to be > unacceleratd/optimized with current CVS. Current CVS should have all of the operators working correctly in all modes; that's made possible by having really general code at the bottom that catches all of the "uncommon" cases. It takes four or five function calls per pixel, and a bunch of other activity. With an infintely fast CPU, that should be the same speed as your custom code; most of that code tries to touch memory only when needed. Until then, we'll need to special case the GTK formats. > It would easy to optimize this in the software compositing > case. In the hardware compositing case, knowledge of > premultiplied formats would have to be added to XAA. XAA needs a lot of work to fully accelerate Render. I suspect we're going to have to spend some quality time reworking the Render infrastructure, both at the DIX/DDX interface and below XAA as well. One significant issue is that XAA needs to allow multiple image formats in video memory; the cards can do ARGB->screen compositing, but XAA can't stick 32bpp pixmaps in the frame buffer when the screen is running at 16bpp. > Alternatively, if people want to be able to cache > source data on the server, you'd need some way of hinting > to the server: "put this pixmap in the optimum place for > compositing source data". The server can figure that out itself; it's not hard, and the image case is the easiest -- don't push bits to video memory until you figure out what the application is going to use them for. Shuffling them around in main memory is essentially free. Keith Packard XFree86 Core Team Compaq Cambridge Research Lab _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
