On Fri, 12 Oct 2001 16:50:23 -0700 Keith Packard <[EMAIL PROTECTED]> babbled profusely:
> > Around 9 o'clock on Oct 13, Carsten Haitzler wrote: > > > well actually the server woudl have to implicitly do backing store for all > > parent windows (and now all children render to the backign store) that have > > alpha in their background mask (ie having alpha means an alpha value of > other > > than 0 or 255 if we talk abouta range of 0-255, with 0 being transparent) > > It's not about parent/child relationships -- it's about coverage. My goal > is to allow each window to draw to one or more "layers" using different > clip lists. Once I can do this, I can create virtual frame buffers for > areas of the screen overlaid by one or more translucent windows -- each > window in that area will draw to the overlay "layer", areas not overlaid > by translucent windows will draw straight to the frame buffer. hmm - so your'e going more flat than tree based? > By separating the notions of layering from the window heirarchy, I hope to > minimize the amount of compositing needed to create the final screen image > from the collection of translucent windows. i guess thats good - macos-x has an advantage that its only 1 layer deep (desktop and then toplevel windows) so it only has to go down 1 level... :) > I've already started the layer implementation -- it was needed to support > the RandR extension. Making it handle per-layer clip lists for each window > is another large part of the puzzle. > > Obviously, with such an implementation, you've got support for backing > store, save-unders as well as translucency. I hope to reduce the amount > of code in the server while improving it's functionality with this new > mechanism. > > > yup. people keep asking for transparency - and i can't do more than nasty > > hacks that look good in screenshots - but not in real ... moving.. life :) > > You need to get away from the client-side and move into the X server where > performance is only a matter of programming the accelerator registers > correctly :-) 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)... 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. 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. i'm thinking about it :) > [EMAIL PROTECTED] XFree86 Core Team SuSE, Inc. > > > _______________________________________________ > Render mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/render -- --------------- Codito, ergo sum - "I code, therefore I am" -------------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] Unemployed Bum [EMAIL PROTECTED] Mobile Phone: +61 (0)413 451 899 Home Phone: 02 9386 9362 _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
