[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] Optimizing pixmap reads and write
From:       Jim.A.Graham () Sun ! COM (Jim Graham)
Date:       2008-11-04 11:02:19
Message-ID: 0K9T00D362NUR750 () fe-sfbay-09 ! sun ! com
[Download RAW message or body]

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
> 


[prev in list] [next in list] [prev in thread] [next in thread]