Accepted answer

you can draw directly on the gc (graphics context) of a new (big) image. having one big image should result in much less resource usage than thousands of smaller images (each image in swt keeps some os graphics object handle)

what you can try is something like this:

        final list<image> images;
        final image bigimage = new image(display.getcurrent(), combinedwidth, height);
        final gc gc = new gc(bigimage);
        //loop thru all the images while increasing x as necessary:
        int x = 0;
        int y = 0;
        for (image curimage : images) {
            gc.drawimage(curimage, x, y);
            x += curimage.getbounds().width;
        //very important to dispose gc!!!
        //now you can use bigimage


presumably not every image is visible on screen at any one time? perhaps a better solution would be to only load the images when they become (or are about to become) visible, disposing of them when they have been scrolled off the screen. obviously you'd want to keep a few in memory on either side of the current viewport in order to make a smooth transition for the user.


i previously worked with a java application to create photomosaics, and found it very difficult to achieve adequate performance and memory usage using the java imaging (jai) libraries and swt. although we weren't using nearly as many images as you mention, one route was to rely on a utilities outside of java. in particular, you could use imagemagick command-line utilities to stitch together your mosaic, and the load the completed memory from disk. if you want to get fancy, there is also a c++ api for imagemagick, which is very efficient in memory.

Related Query

More Query from same tag