Hi Roman,
This isn't well documented in SurfaceData.h, but there is a set of flags
"SD_LOCK_NEED_PIXELS" which indicates if you need to do the read. This
is used in X11SurfaceData.c, but that file has so many ifdefs and
alternate pixel access modes now that you really have to dig through it
to see this. It is also used in GDIWindowSurfaceData.cpp which is a
little less complicated than the X11 counterpart, but not by much.
SD_LOCK_NEED_PIXELS is an OR of the READ and the PARTIAL flags.
Primitives that know that they will be obliterating the entire rectangle
that they are asking to lock will use SD_LOCK_WRITE without the PARTIAL
flag. If they cannot guarantee that they will obliterate the
destination then they use the PARTIAL flag (in addition to WRITE) so
that the read will be triggered.
Hope that helps...
...jim
Roman Kennke wrote:
I'm currently implementing a SurfaceData for VxWorks/WindML.
Unfortunately, this graphics library (WindML) doesn't provide me direct
framebuffer access. Therefore I have to perform read and write
operations for rendering operations (at least, for images and likewise
non-primitives). I was thinking that in many cases I can avoid reading
the surface data (i.e. for rendering opaque images) or in some cases
writing (when transferring the surface data to another incompatible
surface). So I implemented my GetRasInfo like this (pseudocode):
malloc(pixels, size);
if (lockFlags & SD_LOCK_READ) {
readPixelsFromSurface();
}
and the Release function:
if (lockFlags & SD_LOCK_WRITE) {
writePixelsToSurface();
}
free(pixels);
Unfortunately, this doesn't work well. When rendering translucent or
bitmask images, it does NOT set the the SD_LOCK_READ flag, and therefore
I don't read the surface pixels here, resulting in uninitialized
background for these images. This means, it only renders correctly if I
ignore the SD_LOCK_READ flag and read every time, even if I wouldn't
need to.
My question is, did I get something wrong in my understanding of the
flags? Or is this a bug? Or just something that hasn't been
implemented/optimized yet, because it isn't needed on OpenJDKs primary
platforms? (Although, I would think, that at least for non-DGA surfaces
it would be a nice little optimization at least on X11).
/Roman
