Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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  
  Immutable BufferedImage  (Read 1890 times)
0 Members and 1 Guest are viewing this topic.
Offline Mr_Light

Senior Member




shiny.


« Posted 2006-09-17 21:37:05 »

couldn't find it on google.

I'm searching for a wrapper or something. return a copy everywhere can
t be good can it?

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline tortoise

Junior Member




<3 Shmups


« Reply #1 - Posted 2006-09-17 23:33:05 »

What do you mean?

It's been years since I've used Java2D, but last I remembered, BufferedImage is no different from any other Java class. It gets passed around by reference, not copy. Even if a BufferedImage did end up being copied, I'd imagine most of the time just the BufferedImage class gets copied and the underlying raster data is then refered to by more than one object.

Can you give some examples?
Offline pepijnve

Junior Member




Java games rock!


« Reply #2 - Posted 2006-09-18 11:57:00 »

An immutable object is an object that can not change state.

I don't think you can make an immutable version of BufferedImage since it implements the WriteableRenderedImage interface. You could make your own extension of Image and have it implement RenderedImage, but as far as I can tell the graphics pipeline won't be able to do anything useful with it. (i.e. you can't pass it to Graphics#drawImage). The other alternative would be to extend BufferedImage and override all methods that modify the image so that they throw an UnsupportedOperationException. That also sounds like a bad idea though and might not even work in practice, since the BufferedImage constructors probably use some of these methods.
It's probably easier to simlpy state in the javadoc that the returned image should not be modified and if you do, something might break or result in unexpected behaviour.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mr_Light

Senior Member




shiny.


« Reply #3 - Posted 2006-09-20 09:37:26 »

that would make it error prone.

cloning the raster / wrapping an BufferedImage and thowing some UnsupportedOperationExceptions upon invoking methods that can cause the image to be altered(eg createGraphics() setRaster etc).

I suppose I could pass an uri/url around to the generator cach it the first time and make the cach inaccessible to outside the class. I'll recieve exceptions with reguard to reading the image later then I would have wanted but I gues I have to make a compromise somewhere.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline pepijnve

Junior Member




Java games rock!


« Reply #4 - Posted 2006-09-20 11:07:31 »

that would make it error prone.
Which is why I said it was a bad idea Wink

I guess the best solution really depends on how you want to use these images. If you need them as Image/BufferedImage instances there's probably going to be a tradeoff somewhere. Passing URIs and getting errors a bit later sounds like a reasonable one.
If you don't need BufferedImages you could hide the BufferedImage instances in another wrapper class. For instance
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
class ImmutableImage {
  private final BufferedImage image;
 
  public DrawableImage(BufferedImage image) {
    this.image = image;
  }

  public void drawImage(Graphics g) {
    g.drawImage(image, 0, 0, null);
  }
}

The downside is that you have to provide methods for each operation that you want to do with the BufferedImage.
Offline Mr_Light

Senior Member




shiny.


« Reply #5 - Posted 2006-09-20 11:41:42 »

Which is why I said it was a bad idea Wink
sorry, yeah, I can't stop myself from posting early in the morning but I should.  Tongue

I guess the best solution really depends on how you want to use these images. If you need them as Image/BufferedImage instances there's probably going to be a tradeoff somewhere. Passing URIs and getting errors a bit later sounds like a reasonable one.
If you don't need BufferedImages you could hide the BufferedImage instances in another wrapper class. For instance
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
class ImmutableImage {
  private final BufferedImage image;
 
  public DrawableImage(BufferedImage image) {
    this.image = image;
  }

  public void drawImage(Graphics g) {
    g.drawImage(image, 0, 0, null);
  }
}

The downside is that you have to provide methods for each operation that you want to do with the BufferedImage.
I might be able to live with that downside, very interesting approach, thanks.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline Ask_Hjorth_Larsen

Junior Member




Java games rock!


« Reply #6 - Posted 2006-09-29 21:46:27 »

The suggested method wouldn't make the image immutable, because after running the constructor you can still have other references to the argument image outside and thus alter it. A more correct way would be to create a new BufferedImage inside the constructor which is a copy of the argument. This could still be altered if the user subclasses Graphics and overrides the drawImage method before passing it to the grawImage method of ImmutableImage, but this is getting pretty far out.

Your initial question, however, shows concern regarding "copying" of images. Do you have any other reason than that to want an immutable implementation?
Offline pepijnve

Junior Member




Java games rock!


« Reply #7 - Posted 2006-10-11 11:20:23 »

I kind of had a factory in mind that creates the ImmutableImage instances. This factory would decode the images to BufferedImages and then return an ImmutableImage instead of the BufferedImage directly. In practice that would mean there's only one reference to the BufferedImage. Images tend to get large so copying them seemed like a waste of memory (albeit for a very short period of time) and cpu cycles to me. If it's really a concern then I agree that copying is the better solution of course.
Given the BufferedImage interface and the restrictions made by the Graphics(2D) implemenation, I don't think a true immutable BufferedImage is possible. This probably isn't really a problem in his application though. It seems unlikely that the security or stability of an application would depend on this. To me it sounds more like an api design issue, where you don't want the images to be mutable in an obvious way.
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.

CogWheelz (15 views)
2014-07-30 21:08:39

Riven (21 views)
2014-07-29 18:09:19

Riven (14 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (32 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!