Around 18 o'clock on Jun 24, Owen Taylor wrote:
> A) Whether it was reasonable to ask simple clients to do > conversion themself. (Presumably you'd need the toolkit > to do it.) Colorspace conversion has to be done in the client to provide the best available fidelity. Simple clients will continue to use the "all monitors are identical" approximation; sophisticated clients will continue to be able to use XDCCC for color matching. > XDCCC allows a table per visual. Is this realistic? > DirectColor can probably be ignored. What about multiple > screens? I was under the vague impression that with > RENDER you could share picture between screens. The per-visual stuff was added because Sun advertised a bogus linear RGB visual as one of the TrueColor varients in the X11/NeWS server. I don't know if they still do that. As applications are in control of which visual the images are designed for, applications must adapt the image to the visual rather than having the X server attempt to do so automatically. Any color space correction within the server loses information. And, no, Render doesn't currently permit cross-screen compositing. There's no fundemental internal reason for this limitation, it just follows the existing protocol practice. > > - Gamma correction can be turned of in each destination picture; it's > > on by default. > > Hmm, guess we need some benchmarking then to see what software > speeds are for gamma correction :-) That'll be easy to add to x11perf; I've already added tests for Render text and trapezoids... > I got the impression that compression in the XDCCC tables was > to reduce storage for the properties, and that someone using > the tables would presumably do the interpolation once. Yes, that's the primary reason. > Do you think linear interpolation per pixel is really reasonable? The current Xlib XCMS code does precisely this, but it's not exactly in a performance critical place. Optimizations are clearly possible in the implementation. > Just trying to find some way to avoid having to continually > premultiply than de-premultiply again... I'll have to look through Jim Blinn's article on gamma corrected compositing, I hope there are some tricks we've missed. Of course, the common case is an opaque source, translucent mask and dest without alpha, so everything just falls out. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
