Integrated Glpbuffer and Java graphics2d

The program was once again written in Java in 2005, with the main design work done by David J. Eck. Its Java version is called 3d-xplormath-j. It can be run as a stand-alone program or as a series of applets on a Web site. The project was supported to some extent by the International Natural Science Foundation (DUE Award #0514781).

Design Problems in OpenGL integration

3d-xplormath-j originally used the Java graphics2d, our goal was to find the easiest way to integrate OpenGL graphics. 3D-XPLORMATH-J uses the renderer defined by the interface Renderer3d to draw. We created another renderer class to enable the program to perform OpenGL rendering in addition to the existing Java graphics2d rendering. The new renderer will set OpenGL illumination, image, and view transformations, and then render and draw using the OpenGL command.

OpenGL provides hardware acceleration 3D drawing, with improved graphics and extremely fast speed, enables 3D drawing with graphics2d. OpenGL uses Java implementations via the JOGL API. The image in Figure 1 gives a visual representation of improved graphics, which we have implemented through JOGL. As can be seen from the above two pictures, Jogl gives a more clear representation of the snail shell than the Java graphics2d. However, this distinction is not evident in objects that are not very complex. For objects that are spinning, this distinction becomes apparent, even in the form of a roll pad, as seen from the two images below.

Figure 1. Graphical comparisons. Top left: Still snail shells, using JOGL to draw. Top right: Still snail shells, drawn using Java graphics2d. Lower left: Dynamic roll-shaped pads, drawn using JOGL. Lower right: Dynamic scroll pad, drawing using Java graphics2d.

There are three classes in the JOGL that represent OpenGL "can draw area", where several 3D images can be plotted. They are GLCanvas, Gljpanel and Glpbuffer. Of these, GLCanvas and Gljpanel are two commonly used classes, but in large and complex projects, integration can be successful if you need to change a lot of code. Glpbuffer is one of the least known in three classes, but it has some unique features that are enough to draw the attention of Java programmers. In this case, it seems simple to use a pbuffer to render the object, because we can use the same framework as the Java graphics2d, as long as it is slightly modified to draw to pbuffer (a picture outside of the screen in memory). Such a picture can then be retrieved as a standard bufferedimage, and the bufferedimage can be copied to the screen.

GLCanvas and Gljpanel are GUI components. GLCanvas more compatible Awt,gljpanel is more compatible with Swing. Drawing in GLCanvas is a bit quicker, but it's a "heavyweight" component that is difficult to use in Swing. This issue was discussed in a number of articles co-authored by Amy Fowler and Chris Campbell. Using these classes in 3D-XPLORMATH-J requires replacing JPanel with GLCanvas or Gljpanel. Unfortunately, JPanel is more used in 3D drawings. For example, it is used to display bufferedimage, and these things are not as easy to implement as GLCanvas or Gljpanel. Please note: At least in Java 5.0, this is the case. At the end of the article, we'll briefly discuss some of the changes in Java 6.0.

On the other hand, JPanel can be used without destroying the program graphics2d the drawing frame. Glpbuffer represents an area in memory that can be used as an OpenGL command-drawing interface, very similar to the graphics2d bufferedimage. This allows you to obtain a copy of the image drawn in bufferedimage form. BufferedImage can then be copied to the screen using the standard graphics2d technology. In this article, we will show you how to do this and discuss the performance implications of doing so. The most important use of pbuffer is that it is still an experimental aspect of JOGL and is supported by different programs on various platforms. Drawing to a buffer instead of drawing directly to the Gljpanel or GLCanvas slows down is also one of our considerations. After testing in the Linux, Mac, and Windows environments, the differences between the three are small and do not affect the use of pbuffer. Run the same animation, draw 500 frames, each frame to draw 500 balls of any size, the speed of each platform is as follows:

84.65ms=.08465s

		Estimated time per frame
glcanvas	39285ms=39.285s	78.57ms=.07857s
gljpanel	42325ms=42.325s
50945ms=50.945s	101.89ms=.10189s

106.322ms=.106322s

		Estimated time per frame
glcanvas	48795ms=48.795s	97.59ms=.09759s
gljpanel	53161ms=53.161s
82221ms=82.221s	164.442ms=.164442s

Class	Estimated time of the entire animation	Estimated time per frame
GLCanvas	50813ms=50.813s	101.626ms=.101626s
Gljpanel	67704ms=67.704s	135.408ms=.135.408s
Glpbuffer	70703MS = 70.703s	141.406ms=.141406s

These tables show that the time spent using Glpbuffer is not long and is more pronounced on the MAC platform than on other platforms. So we decided to use pbuffer to try to integrate and use its experimental features to take a chance. The program code used to generate these tables can be downloaded from the sample code. There is also an interactive program that is used to compare the two technologies in an interactive way.