Ian Britten <[EMAIL PROTECTED]> writes: > I'm doing some planning for some of our upcoming development, for which I > think I'll be needing some of XRenders new capabilities, and I was just > looking for some feedback/status/roadmap-type of info, to see if I'm on > the right track, plan timelines, (re)design, etc, > > Our software is used for mapping (GIS), and as such, we have a pretty > extensive (abstract) draw mechanism, with implementations for various > toolkits/platforms (GTK, X, Windows, PostScript, etc) > > To our 'canvas', we draw all kinds of graphics, which mostly boil down to > lines, polygons, points, images, etc. (We already handle text ourselves via > FreeType). These graphic primitives are drawn with simple solid colour > specifications (RGB), using the appropriate 'native' calls (XDrawLine(), > gdk_draw_polygon(), etc) > > There is getting to be pressing demand to upgrade our entire draw engine > to support transparency, so that a given line, polygon, image, etc can be > drawn with an arbitrary transparency (Is 'alpha' the correct term for this?) > In other words, we want to draw a filled polygon, but still be able to > see the previously-drawn data underneath it. > > As I look through the various Render webpages, I get the impression that > this capability isn't present in X (and thus GTK), is often handled in > client-side code (making it hard and slow), and that Render is trying to > address/fix this. > However, most of the information seems focused on anti-aliasing fonts, > which isn't really what I'm currently interested in... Is this because > the graphics primitives are already done and I just don't see how to use > them, or is it that they aren't done yet? (Assuming this type of > ability is even planned to be done!) > > If this capability is planned, what will its interface look like? RGBA > or something else? X-type of calls (ie XDrawLines()) or PostScript-type > of calls (ie start/point/point/point/end). Will drawing be done to the > same type of Drawables, or will there be some sort of new > alpha-compositing type of drawable that calls get routed to first, with > the result then drawn/refreshed to the window? > > Basically (as I said previously), I'm just trying to get a 'big-picture' > feel of what exists, what's coming, when it will be generally available > (ie In a release, not via CVS), and most importantly, how to integrate > it into our code. > > [ If these capabilities aren't present, aren't coming, or are still a > long way off, can someone point me in a shorter-term solution (Mostly for > the GTK case..)? I've been peeking into libart thinking it might be > a solution, but does anyone else have any ideas/suggestions? ]
What exists now: The RENDER extension isn't actually a full graphics API; what it is is a set of primitives (draw glyph, draw trapezoid) that encapsulate those drawing operations that it is useful to put on the server or accelerate in hardware. RENDER provides the backend to the Xft library that is used on many modern systems for compositing text, and is also used internally by GTK+ (and Qt) for alpha-compositing images. What's coming: Current plans revolve a set of libraries called Xr and Xc. The Xc library will abstract away the difference between rendering using RENDER and rendering on the client side. Then Xr sits on top of that and provides a Postscript like graphics API. These libraries exist in prototype form now .. you can find them in CVS at http://keithp.com/cvs.html. (Xr/Xc modules) If you wanted to try using these libraries and see how they worked for your application, and report missing areas and problems, I think that would appreciated. But these libraries are likely to change significantly before they appear in a publically distributed form, and there is no exact timeline when they will be available. One might guess 6 months to a year. Eventually, it's likely that something like this will become an integral part of the GTK+ API, replacing the current simple drawing API. What to do currently: If you need something short term, I think libart is probably the best plan. Creating a post-script like API on top of libart shouldn't be very hard; if you are using it within the context of GTK+-2.0, you can use the FT2 backend of Pango for text rendering. There are some existing systems that do this; the GNOME canvas and gnome-print in particular. But the GNOME canvas is likely not suitable for integration into your existing framework, and gnome-print isn't really API-stable at the moment, so I think they are better avoided. Client-side rendering isn't necessarily slow .. at least in the case where the X server is local, I think you can get very acceptable performance out of librart. Regards, Owen _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
