Re: DRI integration

Keith Packard wrote:
> 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.

OK.


>>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.

OK.


>>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.

I don't see that as an abuse of GL.  It seems reasonable to allow 
image buffers to be accessed by any number of renderers.


>>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.

Mesa's s/w renderer is basically based on reading/writing spans too, BTW.


> 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.

So which aspects (specifically rendering operations) of "Xlib-on-GL" 
concern you, if wide lines, plane masks, etc aren't a big deal?

-Brian