[OpenJDK 2D-Dev] Questions about the X11 backend

Jim Graham Jim.A.Graham at Sun.COM
Sat May 3 21:03:59 UTC 2008

Hi Clemens,

Clemens Eisserer wrote:
> Hello,
> I've (again) some questions about the X11 pipeline, just a few words
> would be really helpful:
> 1.) When looking at X11SurfaceData.c, there are several notes that
> this provides support for the software-loops to work directly on the
> native data, e.g.:
>> This file contains support code for loops using the SurfaceData
>> interface to talk to an X11 drawable from native code.
> I wonder where, and what the required mechanisms are to allow this working?

I forget the details right now and I'm not at my desk, but there is a 
native counterpart to SurfaceData in the share/native/sun/java2d tree. 
It defines ways to lock and unlock surfaces and get access to their 
pixels for the native loops to work on.  I believe that the functions 
are defined in SurfaceData.h and implemented in X11SurfaceData.c.

> I commented out all blit-"loops"-registrations in X11XPMBlit(Bg)Loops
> and although slow, everything seems still to work ... amazing :)

I believe in the absence of this mechanism the standard Blit(Bg) loops 
will be run which request a buffer of pixels from the source surface 
data (requiring them to be read via X11) copy them to a destination 
buffer (which may need to be read from the dest if the blit is 
non-opaque) and then send the results back.  The X11PM loops bypass all 
of that network traffic by using Pixmap CopyArea X11 requests, so they 
are simply an (important) optimization, but not required for correct 

> 2.) In X11SurfaceData.java the pipeline-setup quite confuses me:
> Whats lazy pipe, and why is it set for everything if x11txpipe is null?
> Is "sg2d.loops = getRenderLoops(sg2d);" only there to be overridden if
> the rendering mode changes?

LazyPipe is similar to InvalidPipe which does lazy validation of 
pipelines.  InvalidPipe simply waits for all of the attribute/state 
changes to be over and for the first rendering request to happen before 
we bother (re)validating the pipelines.

In the case of X11 windows, though, if I recall correctly, there are 
some aspects of an X11 Surface that cannot be queried/completely 
initialized until a window is visible, so we want to delay the first 
real pipeline validation until that happens.  The LazyPipe simply checks 
to be sure that the window is visible before it allows the lazy 
validation of the pipeline data - so it is even lazier than the 
InvalidPipe which just waits for the first rendering request.

> 3.) Why is there a javaGC and a cachedGC in _X11SDOps?

One is (the javaGC one probably?) for use when servicing fillRect, etc. 
requests and is set up with/validated against the latest attributes in 
the most recently used Graphics object.  Those probably include clip, 
color, and XOR vs. COPY mode.

But sometimes we need to issue some X11 rendering requests that are not 
directly triggered by a rendering request from the Java level.  An 
example would be when we need to read back or send pixel data to X11 
surfaces for software loops to operate on the pixels - we don't want to 
inherit unwanted attributes (like XOR mode) from rendering requests so 
we use our own private GC that only gets used for our internal needs.

> 4.) Is DGA still used? I see quite a lot #ifdef's for missing MITSHM
> and DGA, but I wonder wether there are still systems without MITSHM,
> and the other way round for DGA.

I believe it may no longer be in use, but Dmitri would have to answer to 
be sure.  It was a Sun-specific API for coordinating talking directly to 
the framebuffer with the X11 server.  Since then more work on the X11 
and OpenGL pipelines and the use of MITSHM and the fact that Sun stopped 
shipping framebuffers with DGA drivers at some point made the importance 
of that pipeline wane...

> Thanks for your patience and help, lg Clemens

Thanks for looking into things in such depth!  ;-)


More information about the 2d-dev mailing list