Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Java Unpacking Native Image  (Read 980 times)
0 Members and 1 Guest are viewing this topic.
Offline ghostsoldier23

Junior Devvie


Medals: 1



« Posted 2013-01-10 22:08:22 »

I use the compatible native image returned from GraphicsConfiguration for the buffers in my rendering code.

The problem I now have with this, is how can I unpack/pack these pixels?  I need to modify the RGB values.... but it doesn't seem to be working even though the DataBuffer is still of type DataBufferInt.

The integer pixels appear to be packed in a different format than TYPE_INT_RGB.

Is there a more format independent method to unpacking/packing int pixels than:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
   public static int[] unpackInt(int argb, int type) {
      int[] vals = null;
      int p1 = 0;
      int p2 = 1;
      int p3 = 2;
      int p4 = 3;
      switch (type) {
      case TYPE_RGB:
         vals = new int[3];
         vals[p1] = argb >> 16 & 0xFF;
         vals[p2] = argb >> 8 & 0xFF;
         vals[p3] = argb & 0xFF;
         break;
      case TYPE_RGBA:
      case TYPE_ARGB:
         vals = new int[4];
         vals[p4] = argb & 0xFF;
         vals[p3] = argb >> 8 & 0xFF;
         vals[p2] = argb >> 16 & 0xFF;
         vals[p1] = argb >> 24 & 0xFF;
         break;
      default:
         throw (new IllegalArgumentException(
               "type must be a valid field defined by ColorUtils class"));
      }
      return vals;
   }

   public static int packInt(int... rgbs) {
      if (rgbs.length != 3 && rgbs.length != 4) {
         throw (new IllegalArgumentException(
               "args must be valid RGB, ARGB or RGBA value."));
      }
      int color = rgbs[0];
      for (int i = 1; i < rgbs.length; i++) {
         color = (color << 8) + rgbs[i];
      }
      return color;
   }
Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #1 - Posted 2013-01-10 22:10:51 »

BufferedImage.setRGB()?

Myomyomyo.
Offline ghostsoldier23

Junior Devvie


Medals: 1



« Reply #2 - Posted 2013-01-10 23:23:43 »

BufferedImage.setRGB()?

setRGB causes the BufferedImage to become unmanaged, which is REALLY REALLY slow.  The only way to manually modify pixels and maintain the advantages of keeping the data managed in video memory is through modifying the data array directly.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nsigma
« Reply #3 - Posted 2013-01-10 23:38:33 »

BufferedImage.setRGB()?

setRGB causes the BufferedImage to become unmanaged, which is REALLY REALLY slow.  The only way to manually modify pixels and maintain the advantages of keeping the data managed in video memory is through modifying the data array directly.

Er, I think you got that all backwards!   Roll Eyes

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline ghostsoldier23

Junior Devvie


Medals: 1



« Reply #4 - Posted 2013-01-10 23:49:04 »

BufferedImage.setRGB()?

setRGB causes the BufferedImage to become unmanaged, which is REALLY REALLY slow.  The only way to manually modify pixels and maintain the advantages of keeping the data managed in video memory is through modifying the data array directly.

Er, I think you got that all backwards!   Roll Eyes


Really?  That's mainly based on information I've gathered form other people and Sun's documentation.

Can you be a little more specific?
Offline ghostsoldier23

Junior Devvie


Medals: 1



« Reply #5 - Posted 2013-01-10 23:53:15 »

BufferedImage.setRGB()?

setRGB causes the BufferedImage to become unmanaged, which is REALLY REALLY slow.  The only way to manually modify pixels and maintain the advantages of keeping the data managed in video memory is through modifying the data array directly.

Er, I think you got that all backwards!   Roll Eyes

I just tried commenting out the data fetching code and replaced it with setRGB and getRGB.  It dropped my solid 60fps rendering to 4fps.   Stare
Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #6 - Posted 2013-01-11 00:27:26 »

Er, I think you got that all backwards!   Roll Eyes
His point is that you can't modify the data array either as that too will make it unmanaged. The image data is stored on the GPU, so once you've retrieved the data array Java can't assume that the CPU array is in sync with the GPU data, so it must unmanage it.

Myomyomyo.
Offline nsigma
« Reply #7 - Posted 2013-01-11 10:01:04 »

Can you be a little more specific?

Sorry, I was replying on my phone so kept it brief.  I thought your comment was confusing to the OP - hadn't twigged you were the OP!  Wink

Your statement is wrong though, as is this in many ways -

The image data is stored on the GPU

A BufferedImage is always stored in Java memory.  It's always rendered to in Java memory.  When the image is drawn to the screen (or another accelerated surface) the data is sent to the graphics card.  If you draw an image more than once without changing it the graphics pipeline will cache a copy on the graphics card.  Every time the image is updated any graphics card copy is disposed of.  Therefore, the data is not really stored on the GPU.

If you alter a BufferedImage before each time you draw it (ie. every frame) then a copy will never be cached on the GPU.  Therefore, it makes no difference whether it's a managed or unmanaged image.

The fastest way to work with BufferedImage pixel data in Java is to grab the data array directly.  This makes the image unmanaged, but often this is not an issue for the reason above.  Managed images are only useful for image resources that remain unchanged for a period of time.

That you got a lower frame rate using set/getRGB is not a surprise.  These involve extra data coercion and copying.  They almost certainly don't un-manage an image any more (most articles about this were written Java 1.4 time, and a lot has changed).  They will be slower for what you're doing though.

To answer your original post, don't use compatible images for this at all - it can cause a wealth of problems as you don't know what format you're getting, and on some systems (Linux) there was and may still be a bug where you could never get the data array from a compatible image.

Just create a BufferedImage directly using TYPE_INT_RGB, TYPE_INT_ARGB or TYPE_INT_ARGB_PRE.  You'll have a guaranteed format to work with so won't have to do any data coercion in your code - the pipes for drawing these formats to the screen are some of the most optimized, and will almost certainly outperform the pack / unpack code you have to use to work around it.

Use the pre-multiplied image format if you're doing any direct manipulation involving alpha (eg. custom blending) - it will save you a bunch of headaches.

Hope that helps you out.  The problem with all this Java2D, managed image stuff, etc. is that a little knowledge is dangerous!  Wink

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline ghostsoldier23

Junior Devvie


Medals: 1



« Reply #8 - Posted 2013-01-23 20:04:40 »

Ok that certainly clears things up.  Thank you!

I'm a bit confused though... I do get a performance improvement by using CompatibleImage for the on-screen image buffer.  You think I should switch to TYPE_INT_ARGB_PRE?
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (37 views)
2014-12-15 09:26:44

Mr.CodeIt (31 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (99 views)
2014-12-08 04:46:31

JscottyBieshaar (60 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (38 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!