Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (533)
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  
  NIO memmapped images ?  (Read 1939 times)
0 Members and 1 Guest are viewing this topic.
Offline abies

Senior Member





« Posted 2004-03-06 21:43:25 »

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 ?

Artur Biesiadowski
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #1 - Posted 2004-03-06 22:53:26 »

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?

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline abies

Senior Member





« Reply #2 - Posted 2004-03-07 08:39:31 »

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.

Artur Biesiadowski
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #3 - Posted 2004-03-07 09:07:05 »

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

"<=8gb"

A bit insane, isn't it? Grin

>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) Smiley

弾幕 ☆ @mahonnaiseblog
Offline abies

Senior Member





« Reply #4 - Posted 2004-03-07 10:06:45 »

Quote
> 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).

Quote

>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) Smiley


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.

Artur Biesiadowski
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #5 - Posted 2004-03-07 10:36:07 »

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline abies

Senior Member





« Reply #6 - Posted 2004-03-07 11:06:26 »

Quote

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...

Artur Biesiadowski
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.

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

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

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

Riven (21 views)
2014-07-23 20:56:16

ctomni231 (50 views)
2014-07-18 06:55:21

Zero Volt (45 views)
2014-07-17 23:47:54

danieldean (36 views)
2014-07-17 23:41:23

MustardPeter (39 views)
2014-07-16 23:30:00

Cero (56 views)
2014-07-16 00:42:17

Riven (55 views)
2014-07-14 18:02:53
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!