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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.