Ideally, getGraphics should
modify the original texture, since that's what the name and usage implies. The user should assume that the original texture is being modified. The problem is, as described in FBO/PBuffer code, because of a limitation we should only create FBOs and such immediately after
the texture has just been created. So we can't truly
modify the original texture, hence the reason kevglass created a copy
of the original within the FBO/PBuffer classes. The problem is that getGraphics tries to emulate Java2D's createGraphics method, when really we should have implemented it a little differently.
Currently, if you create a new image, a new texture is created for it. If you decide to change the image, another new texture will be created for that changed image. However the original texture will not be destroyed. It will be left alive because most textures are leaded from files and used often, and it would be very inefficient to load the image again whenever it was reused. The solution would be to have the resource loader keep track of which textures were loaded from files, and if an image is changed, and the old image was not loaded, and is not in use by other images, it is destroyed automatically.
In my opinion this is too much "under the hood" stuff and it will lead to problems down the road. Since images are often programatically generated, we should not treat it differently if loaded from a file. Plus, it doesn't address the real problem: two textures are being created instead of one.
I posted a hack/workaround to the two-texture problem here:viewtopic.php?f=1&t=4511
The basic idea is that we don't create a new texture in the Image constructor. This leads to some problems (getTexture will be different after getGraphics is called, the constructor is bulky and non-intuitive, if we want render-to-texture on a file-loaded image we will still need to create two textures, etc).
A different solution would be to use a new class, MutableImage, which sets up its texture for use with FBO/PBuffer, and then Image.getGraphics would be deprecated/removed. The code might look like this:
img = new MutableImage("tile.png");
//does not include getGraphics()
img2 = new Image("tile.png");
//img2.getGraphics() --> no such method, throws error
I'll think about it a little more. Either way, these things will break a lot of existing code, so maybe they would be better suited for a "slick 2.0" if we ever come to that. If anyone has different ideas, don't hesitate to post 'em...