Community
Participate
Working Groups
We need to create 1-bit and 8-bit Images that we can draw onto with a GC and subsequently draw onto other drawables. Although the API does not seem to exclude this possibility, the actual implementations, at least on Windows and Linux, do not create such images(I did, however, read a posting somewhere that suggested that on Photon SWT really does create such an image using constructor Image(Device,ImageData) if the ImageData is defined that way). This is actually quite a severe limitation for graphical RCP applications, yet I think it should be fairly easy to support, at least on the main platforms(On windows by using a DIB, which is now already being used for a large image). There are some API issues, however. With the current API, the only way to define such an image is with the constructor indicated above - which is somewhat wasteful if you just want to start with a new Image to draw onto. So it would be helpful to add Image constructors that include depth and palette. The other issue may be a little more complicated. Although maybe not essential, it would be helpful if these palette-based images were to be considered device independent. The actual implementation on Windows, for example, is that the Image will be represented internally by a DIB(Device Independent Bitmap), which truly _can_ be displayed on any device. This does not quite fit with the current description of Image that "Instances of this class are graphics which have been prepared for display on a specific device." Obviously this description would need to be changed somewhat to include the possibility of device independent Images(Maybe something like "Instances of this class are graphics which have been prepared for display on a specific platform or even a specific device"). What I would propose is that in constructor invocations where null is specified for Device, and where palette and depth are specified explicitly(either in constructor or through ImageData), that the resulting Image created be device _independent_. In the above scenario, the role of ImageData would shift to "Instances of this class are platform-independent descriptions of images". Yes, an ImageData would happen to be device-independent too, but what would distinguish it from Image would be its _platform_ independence. This need to create and draw onto and display 1- and 8-bit images is actually very critical for us. Without it we'll be forced to use AWT and the SWT_AWT bridge. However, the additional API issues mentioned here are NOT critical. It'd be workable to create such an Image from an ImageData and for it to be constrained to a specific Device.
CAR, SSQ, is there something that can be done in the meantime? What exactly is failing because you can't create 1-bit and 8-bit images?
Useability of our app will eventually fail. We visualize massive amounts of data, with the need to slice through volumes at a high rate, so it requires caching a LOT of images. We never need a display resolution greater than 8 bits, and for the most common form of visualization we only need 1 or 2 bits(could be two 1-bit images, with one having a transparent background). With the requested support we could cache 4, 16 or even 32 times as much rendered data in our 4G RAM, which for certain tasks will be essential. Are we unusual? Yeah, but even scaled down I'm sure there are a lot of apps that could gain from being able to work with palette-based 8-bit images, even if only to enable palette manipulation. I'm surprised you're not already getting pressure from JPL/NASA/Mars, given that they're beginning to use RCP - although my guess is that they're using JAI and SWT_AWT.
I didn't mean to imply anything when I asked the question.
No, no - I realize that RCP is going to be opening you up to a whole lot of needs that you've never had to consider before, and that ultimately you still don't have to do anything outside of your real mandate. If I were worth much at all, I'd be trying to contribute the work myself!
We already do support 8-bit images (DIB) on Windows using Image(Device, ImageData). Currently, we scale 1-bit and 2-bit images up to 4 bits because we are working around a bug in Windows 98. Implementing anything but the screen depth on GTK and Motif platforms would not be easy, because we would have to convert every time we draw, which would be slow (or keep a cache, which would take more memory...). Might not be quite as hard on the Mac, but would take some work.
Oops - I even looked at the code for Image.init(Device,Image,ImageData) for Windows and misread it: I thought a DIB was being created and then converted to a DDB, but now I realize I was seeing the MASK creation. But is there any chance you could expose an option to enable/disable the 1-bit Windows 98 workaround? It sounds discouraging that it's difficult to provide 1-bit and 8-bit image support for GTK and Motif, as GTK will be our primary production platform. Are the GTK and Motif APIs really that limited? I would think that having to do conversion at draw time wouldn't be any more helpful than our creating an Image from ImageData at draw time, and caching a screen-depth representation wouldn't gain us anything. Is there any chance your new OpenGL support could provide the opportunity to get around the limitation?
I changed it so that the Windows 98 workaround now only runs on Windows 95/98. So if you get today's integration build (not available until later today) you should be able to create un-scaled 1 bit images on Windows 2K, XP, ... Silenio, can you answer Ian's other questions? Thanks!
The problem is not in the GTK or Motif APIs. It is more an X Windows limitation. XCopyArea() requires that the destination and source drawable have the same depth. So if a Pixmap is created with a depth other than the root drawable depth (screen depth), conversion has to be done somehow. I believe only with XRender extention it is possible to compose drawables with different depths. OpenGL is probably an over kill for solving this problem and we would have to investigate more...
Thanks Carolyn and Silenio! As to the X limitation that affects GTK and Motif: I really don't mind whether a solution is heavyweight or not. I might ending up using the OpenGL stuff eventually anyway, for some of its other benefits. Mostly I'd like the easiest solution possible - if only so you could justify the effort! A concern I have is that I'm not sure whether any conversion you might do transparently could be any faster than the creation of an Image from ImageData. I'd much prefer that the hardware do the work if possible. What we've got right now is workable for up to a year, but eventually the scope of the project will include the fast slicing of large 8-bit volumes that I referred to earlier. I'm trying to decide whether I should switch to AWT now to avoid the risk of a bigger conversion effort later. However, that said, the first time I bet on you guys was with Envy 0.7x and you've never failed me in the many years since :).
Ian, does AWT do what you want right now?
In AWT you can quickly draw 8-bit images on a display of greater depth. I don't think you can do true hardware palette manipulation, but it seems quick enough to create a new BufferedImage on the same WritableRaster with a different IndexColorModel and then draw it - certainly quick enough to support a responsive brightness slider for a 1600x1200 display. So, yes, what I really need is there. I haven't yet experimented with the Java 1.5 OpenGL support, so I don't know to what extent the hardware really gets exploited by various drawing operations, but that would just be gravy. Maybe I was a little too worried, above, about the performance of any conversion you might do at draw time. , and their palettes can be manipulated.
Can you post an SWT snippet so we can get an idea?
Ian, does the discussion in bug 119363 help you at all?
Carolyn, YES! Although I didn't mention it at all above, we too have been very interested in JAI and I've been very nervous about JAI:SWT interoperation, because we're now fully committed to Eclipse RCP. And I laughed aloud at Mark's mention of maps.google.com because I've held it up to colleagues as my vision of how I've hoped our application will work. I've kept a bit of an eye on NASA's work for a while(JPL caught my attention initially with JADE, which I've played with a bit). There is, however, still the issue of displaying the 8-bit SWT image on a 32-bit X-Windows display. I got the impression from Silenio's comment(https://bugs.eclipse.org/bugs/show_bug.cgi?id=119363#c9) that data-buffer sharing only works for 8-bit images. In that case for X platforms aren't we still somehow stuck with needing to do an 8- to 32-bit conversion in SWT to actually display the image? I'm still interested in Silenio's mention of the possibility of using the XRender extension to accomplish the display of 8-bit images to 32-bit displays, but I haven't kept up with the recent Eclipse 3.2 work, so I don't know what might already be happening. Sorry I haven't posted a snipped here - I wasn't quite sure which issue Steve wanted a snippet for, and got distracted by other more immediate stuff. My issue is less about the code than about the capability. Imagine having a 3D volume represented as a series of images and then using a slider to move up and down in the 3rd dimension, flipping rapidly through the image "slices" of the volume. There easily comes a point where the waste of memory of using 32-bit images limits the amount of volume I can cache and move through. On the other hand, doing additional software conversion of 8-bits to 32-bits is not going to give you the same kind of responsiveness to your slider, and it seems a shame not to be able to take advantage of hardware to do this conversion. I'm talking about huge images, although for this example we really only need to cache portions no bigger than a 3200x1200 display. Basically, we want to cache 8-bit images to save memory, and to be able to display them hardware-fast on a 32-bit display(although not video-RAM speed as we don't have 4G of VRAM!)
I just looked more carefully at the snipped Silenio pointed out to Mark and see that the example was for 24-bit palette depth using DataBufferByte. But discouragingly, I see that it doesn't really share data-buffers at all. It still creates an Image from the ImageData, which is I think a slow software operation I was hoping to avoid - too slow for the kind of slider action I wrote above. I guess I do need to write a snippet before you spend any more time on this. Maybe there are ways of instantiating the image from ImageData that are fast enough, and you'll be able to point that out to me from a snippet...
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it and remove the stalebug whiteboard tag. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. --
