Around 22 o'clock on Nov 21, Owen Taylor wrote: > This is a write-up of observations on reading through the Xr > and Xc header files and a bit of the sources;
Thanks a bunch, Owen. Actual application development experience is something we're pretty weak on... > * I'd like to have XrFormat for gdk-pixbuf's weird default > format: big-endian-premultiplied-rgba. (I can supply the > implementation.) I thought gdk-pixbuf used non-premultiplied alpha. The weird order (RGBA) we can deal with, but the non-premultiplied alpha changes a lot of underlying image composition semantics which are exposed through the API. Xr does separate RGB from A in the API, so perhaps we can make it work. > * I think fonts are one area where following the lead of postscript > is clearly a mistake. Yes, their font selection and character-based APIs are all horribly wrong, but the notion of fonts getting selected and then separately transformed leads to some nice simplifications when doing "weird" things with text. Certainly Xr will always use fontconfig for font selection, and as you've noticed, the current Xr text output APIs are rather limited. Given that X already depends on FreeType, having Xr also expose FreeType apis might be a reasonable solution to part of this problem. Attempting to pass all of that functionality up to applications is a daunting task fraught with ever-present peril of incompatibility and incompleteness. > * There should be a control over whether text is hinted > or not. (Actually XrSetFontValues above might be enough) Using fontconfig patterns for font selection would allow the usual parameters to get passed into the rasterizer. > * Clipping is clearly a missing element in the API; without > a clip operator or functional equivalent, retargeting existing > PostScript code at Xr is going to be difficult. My idea was that Xr would use the Postscript model and allow the user to convert a path into a clip region. > Also, filling shapes with a gradient, image or pattern is > a pretty fundamental operation which doesn't seem to > be currently possible. Hmm. I think that's just a matter of specifying a surface as a pattern to apply when painting. I'm wondering how sufficient the filtered image transformations will be in satisfying the gradient needs. Render has some gradient support that hasn't been implemented yet. > * It looks like the temporary surface created for XrPushGroup > will always have the same format as the parent surface; > I don't think this is right No, it certainly isn't right. You should specify a format when pushing a temporary surface, and it would be nice to be able to create alpha surfaces, RGB surfaces and ARGB surfaces. > * I think it's probably necessary to be able to XrPushgroup > with a restricted size; the overhead of creating a full > size temporary pixmap could be sunstantial. Perhaps. Of course, you could restrict it to the bounds of the current clip region. Having explicitly specified limits seems like a bad idea though. > * Is it necessary to also generalize the mask in Xr as well? > Expressed "functionally" this would be a generalization of: Yes, although I'm not sure we want separate mask and color stacks; perhaps a single stack with different kinds of surfaces would suffice? > * GDK achieves significant efficiency win with unified management > of a cache of shared memory images / pixmaps that are used both > for writing images to the X server and reading data back off > the X server. That's a good idea. I'd already considered placing the local data right into shared segments. One additional possibility is to use the other shared memory semantics and implement a new extension for using them, that would reduce the pressure to combine things on systems with limited numbers of sysv shared memory segments. > 3) Virtualize the operations of getting data from a drawable > and writing data back to the drawable within Xc and allow > GDK to replace them. That would be pretty easy to place above any kind of caching scheme; obviously we'll need something similar to manage X images from large windows in chunks. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
