NIO memmapped images ?

[abies]

I have following situation:

- I have number of medium size images. Total size of them is a lot greater than size of expected GPU memory.
- Only part of them will be used at given time. Set of used images will change gradually - images can go in or out by 1-2.
- Average blitting speed is very important, images are opaque, or 1-bit transparent
- It is acceptable that once per some time there will be small hiccup, as long as for the rest of time speed is acceptable

I'm considering following scenario. On application install, I take images distributed with it and convert to native format (specific for given system/color configuration) and write them to disk. I then memmap all images to memory as readonly and let OS manage them, paging them in and out of memory as needed.

Question is, is there a way to do it automagically ? I can think about managing number of VolatileImages and recreating them from disk when needed - but to recreate them, I would need to create a normal image first ? Is there a way to directly circuit raw buffer from disk to VolatileImage (best case) or to some other image (I could accept one level of manual control, recreating VolatileImages if needed).

For me, it would be best to just do (pseudocode)

VolatileImage vi = Something.createVolatileImageWithBackstore("path/to/file.raw");

and then
graphics.drawImage(vi,0,0);

It would be easiest if GPU could directly get data from disk buffer - no need to engage CPU here. I'm afraid it is not possible in java, but what is the way to do it in least number of hops and use OS disk buffer/page code instead of managing image memory myself ?

[Abuse]

As I see it GPU memory is irrelevant, getting the images into main memory is the important step. (Java will manage the caching of images in vram automatically, and, with the improvements in 1.5, you will be able to specify a priority to the image)
Are you going to have more images than can fit in main memory?

[abies]

Probably not more that could fit in main memory + swap - on the other hand, why use more memory than needed ?. I would hate to see image written to swap and then read from swap, when it can be as well read from read-only file. For me, this is one of main benefits of memmapped files - ability to avoid polutting swap with data which is already on disk.

Games published by our own members! Check 'em out!

[oNyx]

> Probably not more that could fit in main memory + swap

"<=8gb"

A bit insane, isn't it?

>Java will manage the caching of images in vram automatically

ImageIO does caching by itself, too(as long as you don't explictly disable it)

[abies]

> Probably not more that could fit in main memory + swap

"<=8gb"

I'm talking about normal config, let's say 256M+double that swap (OS also have to take some space). I'm thinking about 100-500M of images (after uncompressing), with 10-50M needed at given time (very rough estimate).

>Java will manage the caching of images in vram automatically

ImageIO does caching by itself, too(as long as you don't explictly disable it)

Isn't this caching only useful for reading images first time, when going back in stream is useful ? I have a feeling that cached files are just contents of original stream, written to disk and deleted after managed image is created in memory, not memmapped dump of native image memory.

[Orangy Tang]

Are you trying to optimise loading of images for fast app startup, or actual drawing speed? It sounds like you're trying to do both at the same time.

IMHO, install-time conversion to a native format isn't worth it. The actual native format may change after install, such as change of desktop colour depth or updating drivers. If you really want to speed up loading of images then I've found that you get much better results by having a few large tilemap images and chopping them up at run time rather than lots of little files.

[abies]

IMHO, install-time conversion to a native format isn't worth it. The actual native format may change after install, such as change of desktop colour depth or updating drivers. If you really want to speed up loading of images then I've found that you get much better results by having a few large tilemap images and chopping them up at run time rather than lots of little files.

I already have images composed from tiles. I do not want to optimize loading speed - at least not startup time - I want to optimize memory usage without working too much on smart image cache. I would just like to minimize pause time when new big image has to be loaded into GPU.

As for the format change after install - no problem to recreate cache after each color depth change, detected at startup time.

My idea is simple. Currently, java has data image in heap and it automagically copies it to GPU when needed. If there is not enough RAM for application, parts of heap will be written to swap and then read back from it. I would just like to replace image data parts of heap by readonly file on disk - no need to write anything on swap out.

It is not _critical_ - I can just bite the bullet (?) and implement smart image cache myself. It is just this extra copy in memory which looks like a waste to me...