Skip to main content

Native rendering and mysteries of JAWT

6 replies [Last post]
Joined: 2003-06-10

This is a continuation of this thread:

Bino suggested I post here so that Chet might contribute.

Basically my questions involve native methods and JAWT:

Question #1
It seems that since that union in jawt_Win32DrawingSurfaceInfo holds either a native window handle, DDB, or DIB that I can somehow use the JAWT stuff on something that isn't a heavyweight, like an offscreen bitmap. �It seems that I could be asked to draw on some sort of backbuffer is that possible?

Question #2
I'm currently only using the hdc member of jawt_Win32DrawingSurfaceInfo, but how do I know which interpretation of the union of { HWND, HBITMAP, void*pbits } is valid? (Thus far it has always been the HWND since I always use a Canvas, see question #1.)

I have solve my initial issues with painting live video to my own Canvas from a native thread that pushes the video frames to the screen. I have a multi-media application that interfaces with custom hardware on Windows (a high-end video capture & processing device). But while I was doing that I noticed members of the JAWT structure for Win32 drawing surfaces that I didn't know how or when to use. The structure suggests that the native GetDrawingSurface method can be used on something other than a Canvas. Yet I haven't seen any documentation on what is allowed and how it is to be used.

Since I must interface with native code and I have a Swing UI, I'm looking at all the various ways that I can get images to the screen in a Swing-friendly way. I'm currently using a Canvas subclass that I set to the size of my video frames nested inside another heavyweight that I manually resize to control clipping so it plays nice with my Swing UI. (That wrapping heavyweight is currently a ScrollPane.. but I don't want the borders that get rendered for a ScrollPane on Windows so I will likely be changing that and implementing my own scrolling.)

Anyway, some answers for the 2 questions above would be most helpful, thanks in advance.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-16

Just to clarify Scott's question, Scott would like to use JAWT
on an Offscreen Image. Looking at the DrawingSurface code, it seems to suggest
that starting with we can indeed render using JAWT to a VolatileImage.
I was not sure if this is generally supported and if so, is there any
catch to what you can do with it ? Chet I seem to recall talking to you about
this, but I dont remember anymore what the issues were.

By the way, what do you get for the VolatileImage, Do you get a DX7 type
surface or so you get a HDC ? Are there any examples that illustrate how to do
this. Thanks.


Joined: 2003-08-07

Unfortunately there is no way currently to "share" the handle to the back buffer. The JAWT stuff is set up currently for onscreen windows/components only (HDC, HWND, etc.). There is other information in the JAWT structure (if you're poking around in a native debugger and happen to see it hanging out there), but that is just prototype fields for a future time when we will expose back buffer handles.

One of the ways that we are exploring doing this (and this will NOT make 1.5, I'm sad too say; too much to do, too little time) is by locking an offscreen image. This will hand back a pointer to some sort of accelerated representation, such as a DX7 surface. Then the surface must be unlocked it order for Java2D to continue using it. While locked, the surface could be rendered to using the appropriate native rendering interfact (dx7 calls, for example).

The care taken in not exposing this too soon is:
- Once we put in an API, we're stuck with it. Even in an out-of-the-way place like JAWT. So we'd better be sure we like something before we put it there...
- Sharing offscreen surfaces requires much more care and thought than sharing windows. For example, an accelerated surface in DirectX can simply go away at any time due to some OS occurrence. We handle this internally by recreating objects that use that surface. If we do that while you happen to be using a shared handle to the surface, . We believe the locking mechanism (or something like it) is a good way around these problems, but we need a bit more time to sort it out and make sure it's robust enough to support.

Sorry I couldn't help you on this one...


Joined: 2003-06-10

Ah, well I'm glad you cleared it up anyway.

Is the plan to only allow access at some point to accelerated back buffers? Are there any plans to allow access to a BufferedImage?

I know that acceleration on Linux is being looked at via OpenGL. I figure if you are going to expose accelerated images you may have to account for that as well.

I was wondering if it might actually make sense to change the existing Windows implementation to use OpenGL as well.. the advantage being that the amount of shared code would be higher, and as a side effect, perhaps OpenGL bindings (e.g. the JOGL project at might get pulled into the core JRE. But all that is outside of the scope of this thread, and I'm probably just dreaming anyway :).

Thanks for filling me in.

Joined: 2003-06-24

Hi Steve,

We're hoping to eventually port our OpenGL pipeline over to Windows, which should be a beneficial alternative for some Windows users (e.g. those using JOGL, as you mention). Right now, in order to run a JOGL app, you have to disable DirectDraw, as the two don't play well together, which means any 2D rendering is not hardware accelerated. But if we were to enable our OpenGL pipeline on Windows, Java 2D and JOGL would work well together. I think it is important that we ensure that these technologies work as a cohesive layer, so that developers can make use of both API's simultaneously in the same app, when appropriate.

Thanks for the feedback.

Joined: 2003-08-07

Thought I'd muse some more on OpenGL and buffer sharing:

- In answer to your question about sharing the BufferedImage data in native code, you can do this already and you don't need JAWT. You can get the
DataBuffer object from a BufferedImage and then you should be able to
request a native array to that data from JNI; then you can pixel-twiddle
to your heart's content. Of course, if all you're doing is software
manipulation of that data (vs. using some native API), then you might
as well stay in Java and do your twiddling there. Check out the setRGB/getRGB
methods in BufferedImage, as well as the Raster and DataBuffer classes.
Caveat: if you do request the DataBuffer from a BImage, be warned that we will
punt on managing (read: "accelerating") that image. Managing images for you requires that we know what's happening to the data at all times; if you grab
your own pointer to it, all bets are off.

- In answer to your request for accelerating via OpenGL on Windows, Chris mostly answered your question. But I'd like to add that the plan is to have multiple renderers on all platforms and choose the best one that suits the configuration. One thing that concerns me about defaulting to OpenGL in all cases on Windows is the fear that some video card makers have written drivers that make Quake run really well ... and not much else. I would love to be proven wrong on this, but until then my assumption is that full DirectX support is more of a priority for video card makers and thus might be the more robust and full-featured way to go. But if we have multiple options available, then we can always test these assumptions and change the defaults accordingly.


Joined: 2003-06-10

Who's Steve? (I'm Scott, my brother is Steve, but he doesn't have a clue about programming... )

Re: OpenGL - Awesome. Looks like you have things covered. Next I want a Java3D implementation in pure Java built on JOGL.. but this is the Java2D forum so I'll just shut up and be thankful for what I get :)