Hi,
> > What this does: Detects the XShm extension, tests it, and generally
> > sets stuff up for the rest of the code to use it. There's no harm in
> > enabling the #define, as everything still works.
>
> Unfortunately, I can't bind the shared memory segment to the
> gfx_pixmap_t's existing data block; I have to allocate the new segment,
> and copy it over.
Why do you need shared memory for gfx_pixmap_t blocks? They're just read
from by our very own crossblitter functionality; the only thing that needs
to be shared between X11 and FreeSCI are the four visual planes (static
buffer, back buffer, front buffer, and the window).
> Unless we perform some major hackery in the internals (ie each
> gfx_pixmap_t is pre-allocated as a shm block), I don't see any
> way around this.
If this is neccessary, we'll introduce a new driver flag "PREFERS_SHM" or
something like that, add an shm ID and a pixmap flag for shared memory.
That should be a relatively clean way to do this.
> I'll check in what I have (again, it can easily be #defined out) if the
> concensus wants something to bang on. Otherwise I'll keep this private
> until it seems to work better. Anyone interested?
I'm at work now, so I can't really do anything significant there; still,
I'd like to hear your opinions on the points above.
> I'm also looking into that endian-ness thing.. is it completely broken,
> or is it almost-but-not-quite fixed already?
Let me first start off with a precise error description, to make sure
that everybody understands what we're talking about:
When using the xlib target and displaying on a remote X server running on
a different endianness as the host system with more than 8bpp, colors are
screwed up (The "Solaris Real Player effect"). This is because the pixel
values calculated by the gfx translation layer are based solely on the
shift and bitmask values returned by the driver; no byte swapping is
expected to be done.
What needs to be done to resolve this:
a) Detect the situation. I'm pretty sure there are some flags to determine
this (local endianness is known to FreeSCI by means of the WORDS_BIGENDIAN
preprocessor macro- we don't support VAX endianness ATM).
Pointing out the situation may be done by a driver "capability flag",
which should be renamed into "gfx driver flag" since it really covers a
more than capabilities.
b) Decide on a method to resolve it in the implementation.
There are three places where this might be done:
1) In the pixmap translation layer
2) In the pixmap registry functionality provided by the Xlib driver
3) In the crossblitting layer
Point 3 would be slowest, since translation would have occur every time we
do the blitting. Still, we won't be able to do alpha blending or something
similar if we don't consider endiannesses there.
OTOH, cross-endianness alpha blending is probably as painful as it sounds,
so this might be an acceptable sacrifice.
Point 2 would be reasonably fast, clean, and easy to implement. Still, to
draw a single pixmap once, we'd have to touch it at least twice- once for
translation, once for endianness correction.
Point 1 would be the fastest solution, but it would require to double our
set of scaling operations. We already have 3x4 of them:
{8bpp, 16bpp, 24bpp, 32bpp} x {simple, linear, trilinear}
I'm slightly in favor of 1, for reasons of performance. Any thoughts?
llap,
Christoph
