Around 12 o'clock on Oct 13, Carsten Haitzler wrote:
> hmm - so your'e going more flat than tree based? The semantics are layered as in my paper, the implementation is flat. That's just the same as the regular X server, the semantics have nested windows but the implementation has each window holding it's own clip list. In some window systems, the implementation actually recurses the clipping up to the top (trestle did it this way). I think it's important to retain the efficiency of the flat implementation, even given the additional complexity. The sample I did was a purely nested implementation; that was a bit sluggish so we have at least one counter example. > i know... xrender will be useful once it does transforms of pictures whilst > compositing. also the drivers definitely need to be abel to store pictures on > card as trxtures and keep them there too to have some decent perfromance > (probably tile the images into multiple textures to make for better storage > optimizations)... I'm about to embark on some extensions to the kdrive architecture to support storage of data on the video card in arbitrary formats, this will permit all kinds of Xrender accelerations. Doing this for the core server will be more complicated as there's a lot of infrastructure that will need rework. Once we've got the images stored in the video card, getting the hardware to accelerate the painting is child's play. > once we have that we now need a picture sharing mechanism - ie multiple > apps what the same icon/picture/texture for backgroudns or stuff - why does > each app have to upload it each time? they shoudl be able to address that > image/icon/texture (image block data) simialr to a glyph - ie have some > unique name/key and the server manage these (and cache them) to avoid > excess wire/client/server data xfers. XIDs are global. > this *COULD* be done to some extent client side - but having viirtual xid's > for pictures that may get remapped to a single picture internally to the > server woudl be server-side.. copy on write would also be useful here for > when apps modify the picture data. Hmm. There's only one problem -- GraphicsExpose events hold the XID of the drawable, making multiple XIDs map to the same Pixmap means we'd have to fix this. Not impossible, but problematic. Or we could ignore it and continue to send the events only to the original creator. Other than that, the server already supports multiple XIDs for each object -- fonts and cursors are managed that way. I don't know about copy-on-write; seems like that would be easily managed from the client side, but maybe not. In any case, such an extension would be remarkably easy to implement. [EMAIL PROTECTED] XFree86 Core Team SuSE, Inc. _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
