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
behavior.
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! ;-)
...jim
