Here’s what I’ve been doing so far. First of all, my experience with OpenGL is not helping me much at all. Writing images directly to the framebuffer is something I’ve never done before and it’s new to me. That’s alright though because I have the Red Book in front of me and it’s relatively straightforward. The bad news is that it’s slower than I expected it to be. I’m not thrilled that images are constantly being written from core memory to the frame buffer – I thought you could get away with keeping everything on the video card. That means, for big maps, everything is going to sit in core memory anyway. I haven’t given up on that yet.
However, when you zoom, things get bad – at least on my machine. I get video artifacts (see myweb.dal.ca/mkiefte/Screenshot.png). That’s the video drivers fault, but I don’t exactly have an obscure configuration. Joel, do you get any of that? What does zooming look like to you?
You can use the ‘Z’ and ‘SHIFT+Z’ keys to zoom as well as the mouse wheel (I don’t have a mouse wheel).
This particular way of rendering images is not the only way and it has some drawbacks. 180 degree rotation is trivial, but 90 degrees is not at all. Also the image stays in core memory. It no longer draws the entire image every time, but it’s still painful under Mesa. Quite zippy on an NVIDIA card though.
I’m going to upgrade my OS sometime soon (Ubuntu 8.04 is out today), so I’ll be caught up with respect to Java and my video drivers. One thing to consider: Java2D now has a direct pipeline to video acceleration. Do we need JOGL?
I’m going to try to do this with textures instead of directly pasting the image onto the framebuffer. This will allow rotations using the usual OpenGL viewport manipulations. I’ve never seen a texture as large as say, a Streets of Stalingrad map, but it’s theoretically possible I suppose. We do have flight simulators after all.
This is quite an improvement over my demo. I haven’t had time to look
at the code yet, only to play with the demo for a minute. What’s
nontrivial about orthogonal rotaton? For pi/2, isn’t the pixel matrix
just the transpose of the one for 0?
(What about arbitrary rotations?)
Why does the downscaling look so crappy?
If only! This has been aggravating me for ages now. I’ve never been able
to test how the accelarated Java2D pipeline works, since it doesn’t support
Intel video chipsets, nor does it support the rather oldish Radeon in my
wife’s computer. The former convinces me that we can’t rely on it, because
you’d expect that it would work on a mid-to-high end laptop which is less
than a year old—but it doesn’t. A lot of people, especially laptop users,
have Intel video chipsets…
The only way to rotate an image is to rotate it in core memory and then send it to the device. The way image rendering works using this method is quite different from anything else in OpenGL as it draws directly to the FB completely bypassing the view matrices. The only effect the view has on image rendering is it transforms the origin, but not the image – which is kind of bizarre. So I eliminated all that stuff relating to the viewing angle and perspective.
Zooming is quite doable as you can see. You can rotate the image by 180 degrees by setting both the x and y zoom to -1.0. If you only set one of them to -1.0, you get a mirror image. There’s no such thing as rotation as such.
That would depend entirely on your GPU. The program doesn’t do any scaling. On mine, it looks fine. One downside is that everyone will see something slightly different I suppose.
Or there might be some rendering options I haven’t done. It should be set to linear interpolation, but now that I think about it, I may have forgotten about that.
Crap. They make it sound so great.
This is the way to go if it works as textures use the viewing angle for arbitrary rotations. If your driver implements hardware acceleration, odds are textures will be implemented before the ability to scale direct rendered pixmaps because of the obvious number of applications that use the former. You get arbitrary rotations for free. You could even tilt the azimuth so you can get your board in perspective if you really wanted to. You can use mipmaps for optimized zooming if module developers feel really inclined to add that. And you could give depth to textures if you wanted to do some elevation-related shadow effects.
The down side is that it’s an order of magnitude more complicated to implement even to get basic funcationality. However, if the Java2D was kept parallel to the JOGL code, we could go ahead with this. I’ll try to get the demo working with textures.
