Re: DRI integration
Keith Packard <[email protected]>
| Newsgroups | gmane.comp.freedesktop.xserver |
|---|---|
| Message-ID | <[email protected]> |
Around 12 o'clock on Nov 13, Brian Paul wrote: > I've just joined this list... Thanks for participating; your input is very important to me. > Line drawing is one such problem. Simple horizontal/vertical lines > are easy enough, but touching the right pixels on diagonal lines, wide > lines and line caps/joins are hard. Doing that stuff with > glDrawPixels or individual GL_POINTS would be rather inefficient. Don't care is really the answer -- X wide lines are not used by any applications today, so performance is not an issue. Even thin lines are largely unused. A pure GL-based architecture would have the X server compute either a list of rectangles (spans) or a 1-bit mask, pass that to GL and paint through that. > X's plane masks are another. OpenGL has plane mask for color index > mode, but not RGB. Though, I'm not sure how important this stuff is > to X nowadays anyway. Planemasks aren't relevant anymore for performance and we can emulate them with a sequence of regular rasterops for compatibility. This is how it's done with the Win32 API. > If OpenGL replaced Xlib's drawing functions I'd like to think that a > small OpenGL extension could be designed to make up the difference > from Xlib's rendering feature set. My goal is not to replace Xlib, but build a bottom-end for the X server. As such, we can paper over things in many different ways, either GL extensions or horrible code within the server. The best way I see forward is to abuse GL by giving X direct access to the underlying pixels so that we needn't worry at all about rendering code for unimportant operations and can focus our efforts on hooking the important operations up to the hardware as efficiently as possible. > Has anyone ever exhaustively explored/documented how X's rendering > operations might be mapped to OpenGL? That could be an interesting > project. Not that I know of. Core X is pretty simple though, within the server it can be expressed as three primitives (GetSpans, SetSpans, FillSpans). Of these, only FillSpans is at all hard as it must deal with stipples and tiles. Render is a bit more complicated (perhaps overly so), the server internals express a single primitive Composite operation which takes a huge list of parameters and for which the frame buffer implementation contains miles of code. -keith