Skip to main content

Loading pictures

14 replies [Last post]
francoislionet
Offline
Joined: 2008-01-13
Points: 0

Hello all,

In my games, I need to load a few number of pictures. So I use the MediaTracker to find out if the image(s) are loaded.

My question.

Is it better to :

-> Load each image one by one, with each time a mediatracker waiting for the image to load before proceeding to the next one?
-> Initiate a load for all the images, and make one only MediaTracker wait for all the images.
-> Make a mix of those, like load 5 images in a row, and wait for these 5 images to load before proceeding to the next ones?

I am also concerned about memory. When I initiate an image load, this must take some space in the heap (PNGs). Have you got any idea how much per image?

Thanks, Francois

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bddeveloper
Offline
Joined: 2008-01-14
Points: 0

Hello Bill,

It is up to the CE companies to implement DVBBufferedImage correct?

Scott

Bill Foote

bd-j-dev@mobileandembedded.org wrote:
> Hello Bill,
>
> It is up to the CE companies to implement DVBBufferedImage correct?
>
> Scott

Sorry, I don't totally understand the question. It's up
to the CE companies to implement everything. They can do some
or all of this by buying implementations from one or more
companies.

I guess it's more likely that java.awt.Image would come from
an implementation that originally came from Sun (though this
is not a requirement), and it's somewhat more likely that
DVBBufferedImage comes from a middleware implementation written
by the CE company or some third party. That said, DVBBufferedImage
is pretty much a trivial class that uses the appropriate class
from java.* in its implementation.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

bddeveloper
Offline
Joined: 2008-01-14
Points: 0

Ok now I think in understand how there are differences in each player, some implement their own others don't and then there is the hardware differences.

Bill Foote

bd-j-dev@mobileandembedded.org wrote:
> Hello all,
>
> In my games, I need to load a few number of pictures. So I use the MediaTracker to find out if the image(s) are loaded.
>
> My question.
>
> Is it better to :
>
> -> Load each image one by one, with each time a mediatracker waiting for the image to load before proceeding to the next one?
> -> Initiate a load for all the images, and make one only MediaTracker wait for all the images.
> -> Make a mix of those, like load 5 images in a row, and wait for these 5 images to load before proceeding to the next ones?

I haven't measured, but in my opinion, #1 is probably best.
Since there's only one CPU on the slow devices that you care
about optimizing, doing two CPU-bound things simultaneously
just adds context switch overhead.

However, on a device where reading the image file is slow, you might
get more interleaving of the file read and the image decode if you
do two or three at once; if nobody out here has measured this on
a representative sample of players, it could be worthwhile to write
a little test. I'd be interested in the results!

> I am also concerned about memory. When I initiate an image load, this must take some space in the heap (PNGs). Have you got any idea how much per image?

In terms of heap space used for the actual decoding process, I've
never known that to be a problem. The thing you do need to worry about
is the memory that holds the pixmaps when it's done. Some implementations
might even have issues with memory fragmentation - pixmaps can be stored
in the native heap. It's a good idea to use image mosaics when possible,
and avoid allocating and de-allocating BufferedImage instances.

Cheers,

Bill

> Thanks, Francois
> [Message sent by forum member 'francoislionet' (francoislionet)]
>
> http://forums.java.net/jive/thread.jspa?messageID=258898
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
> For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

bddeveloper
Offline
Joined: 2008-01-14
Points: 0

Hello Bill,

Lets say there are 10 images to my application and I've actually just created one large one using the mosaic technique, then at runtime I split it out into 10 java.awt.Image files, but I don't use them all at once.. i use them based on user input, such as showing the "unpause game" image only if the game is paused.

My question I guess is: Is it better to not create the "unpause game" Image object till I'm ready to use it? Or is there enough heap space to have all my java.awt.Images rendered and just ready to be drawn on to the Graphics object?

Thank you,

Scott

Bill Foote

bd-j-dev@mobileandembedded.org wrote:
> Hello Bill,
>
> Lets say there are 10 images to my application and I've actually just created one large one using the mosaic technique, then at runtime I split it out into 10 java.awt.Image files, but I don't use them all at once.. i use them based on user input, such as showing the "unpause game" image only if the game is paused.

If you make a mosaic, then you have one large java.awt.Image - you
can't split it into separate java.awt.Image objects.

Take a look at com.hdcookbook.grin.util.ManagedImage, and its
two subclasses ManagedFullImage and ManagedSubImage to see one
way of dealing with an image mosaic at runtime. HDC page 23-5
shows a sample mosaic.

> My question I guess is: Is it better to not create the "unpause game" Image object till I'm ready to use it? Or is there enough heap space to have all my java.awt.Images rendered and just ready to be drawn on to the Graphics object?

OK, if you have separate .png or .jpg images, then you can load them
separately if you like. Which is better? It depends -- how big are
the images, and how much time do you have to decode them between the
moment you know you'll need to display them, and when they have to
show up?

Usually the answers are "not very big" and "not very long," in which
case you probably want to decode all of the images up front.

Bill

> Thank you,
>
> Scott
> [Message sent by forum member 'bddeveloper' (bddeveloper)]
>
> http://forums.java.net/jive/thread.jspa?messageID=259008
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
> For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

bddeveloper
Offline
Joined: 2008-01-14
Points: 0

Hello Bill,

I thought you were doing something like this:

BufferedImage image = comp.createImage(width, height);
Graphics2D gr = image.getGraphics();
Rectangle p = placement;
gr.drawImage(mosaic.image, x, y, x + p.width, y + p.height, p.x, p.y,
p.x + p.width, p.y + p.height, null);

Then you would have the java.awt.Image object. This now explains why you have created an ImageManager class.

Would there be a performance hit in creating multiple images out of the one big image as illustrated above?

Scott

Bill Foote

bd-j-dev@mobileandembedded.org wrote:
> Hello Bill,
>
> I thought you were doing something like this:
>
> BufferedImage image = comp.createImage(width, height);
> Graphics2D gr = image.getGraphics();
> Rectangle p = placement;
> gr.drawImage(mosaic.image, x, y, x + p.width, y + p.height, p.x, p.y,
> p.x + p.width, p.y + p.height, null);
>
> Then you would have the java.awt.Image object. This now explains why you have created an ImageManager class.
>
> Would there be a performance hit in creating multiple images out of the one big image as illustrated above?
>
> Scott

Performance? Not too much, I guess - there's an extra
BLT, but only one. But using BufferedImage like this would
result in more fragmentation of the pixmap buffer, and it does
require a transitory double-copy of the images.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

bddeveloper
Offline
Joined: 2008-01-14
Points: 0

What does BLT mean?

As long as the mosaic image(s) were removed from memory using gc (making sure no one has a hold onto them), that would reduce the double pixel in the pixel buffer. Is the pixmap buffer the same as the pixel buffer? Do you recommend re-reading a section of the book about the pixmap?

Scott

Bill Foote

bd-j-dev@mobileandembedded.org wrote:
> What does BLT mean?

It's the act of copying pixels (or other large contiguous
blocks of memory) from one buffer to another.
Um... Basic something Tranfer?

Foldoc to the rescue! http://foldoc.org/index.cgi?query=BLT&action=Search

Turns out the term comes from the PDP-10 BLock Transfer opcode.
I never knew that before!

> As long as the mosaic image(s) were removed from memory using gc (making sure no one has a hold onto them), that would reduce the double pixel in the pixel buffer.

Sure, but you've still got both copies in memory while you're
doing the copying.

> Is the pixmap buffer the same as the pixel buffer?

Um.... yes. I forget the precise term in the BD spec, but there
is a fixed buffer a bit over 10 mega-pixels/

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

bddeveloper
Offline
Joined: 2008-01-14
Points: 0

Great! Thanks.

So when a java.awt.Image it's memory is taken up in the pixmap and that memory size is around 10 mega-pixels. The pixmap space is different from the general heap space, which is different from the class loader space (the space that keeps the class files) . The heap it self can contain all object instances. Are their any other java.awt.* objects that are kept in the pixmap space instead of the heap space?

Scott

Bill Foote

bd-j-dev@mobileandembedded.org wrote:
> Great! Thanks.
>
> So when a java.awt.Image it's memory is taken up in the pixmap and that memory size is around 10 mega-pixels. The pixmap space is different from the general heap space, which is different from the class loader space (the space that keeps the class files) . The heap it self can contain all object instances.

Right.

> Are their any other java.awt.* objects that are kept in the pixmap space instead of the heap space?

I'm not totally sure - there may be some subtypes of BufferedImage
out there, for example. I guess there's DVBBufferedImage, too.

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net

bddeveloper
Offline
Joined: 2008-01-14
Points: 0

Thanks!

bddeveloper
Offline
Joined: 2008-01-14
Points: 0

The exact size for Profile 1.0 image buffer is 5.6875 Mpixels which is still 1.6+ Mpixels more then HD DVD's spec which is 3.840 Mpixels.

Scott