简体   繁体   中英

Runtime blending large images (Java/JOGL/Processing)

I need to alpha blend 2700x1600 images at runtime. It's essentially a slideshow, though with multiple "decks" running simultaneously. Each column in this diagram represents a program state at any moment in time:

imageA1 <-blend-> imageA2 <-blend-> imageA3 ...
imageB1 <-blend-> imageB2 <-blend-> imageB3 ...
imageC1 <-blend-> imageC2 <-blend-> imageC3 ...
imageD1 <-blend-> imageD2 <-blend-> imageD3 ...
imageE1 <-blend-> imageE2 <-blend-> imageE3 ...
imageF1 <-blend-> imageF2 <-blend-> imageF3 ...

Not totally surprisingly, I'm having problems keeping my framerate up. I've tried doing the blending on an offscreen buffer, but that hasn't seemed to help much if any. Are there any general strategies for working with images this large that might apply to this situation? Something to leverage the graphics card as much as possible, perhaps?

This is my basic strategy (very simplified code, Processing rather than Java) as of right now:

PImage a = loadImage("imageA.png");
PImage b = loadImage("imageB.png");
PGraphics buffer = createGraphics(width, height, OPENGL);

void draw () {
    buffer.beginDraw();
    buffer.tint(255, 200);
    buffer.image(a, 0, 0);
    buffer.tint(255, 100);
    buffer.image(b, 0, 0);
    buffer.endDraw();
    image(buffer, 0, 0);
}

I'm using Java/ Processing , but advice in raw JOGL is welcome.

I'm also having a bit of trouble managing memory; each of these images uncompressed is ~17MB (2700x1600x4 bytes), and there are a total of ~60 images I'll be blending (not all simultaneously!). I have strategies in mind for the memory issue that are outside the scope of this question, but I include it here in case there is a clever way to balance memory usage between the computer's memory and the graphics card's.

(Extra info, for those who care: My understanding is that Processing's image() calls (which draw image objects to the screen) uses JOGL for its underlying implementation. This understanding comes from looking at the source for Processing's PGraphics.imageImpl() method , which when using the PGraphicsOpenGL renderer (I am), ends up at native JOGL calls within PGraphicsOpenGL.rawPolys() .)

Your worst enemy will be disk I/O. In the past, I have used a memory buffer which held all the images that needed to be processed. In your case, that buffer would be a slice of your 60 images... say a 10 image slice buffer.

Producer Thread-1:

load image from disk--->|10 image Buffer|----->process image in a FIFO manner

Consumer Thread-2: image ready for display --->|Display buffer|----->paint image

Also, you could profile your code with JProfiler to see other bottlenecks.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM