64x64 limit problem

OpenGL Development JOGL Development
#1

On page 371 of the red “OpenGL Programming Guide” (para 2) it states: "The maximum size of a texture map depends on the implementation of OpenGL, but it must be at least 64 x 64 (or 66 x 66 with borders). Does this mean that I will have problems rendering my 8 x 16 pixel png rectangles images as textured quads?

Have done some initial testing using textured quads and the speed is (as I’d hoped) much faster than gldrawpixels, but am unable to display the images at their original size or at a coordinate point that I can understand (yet). It’s all good fun though. :wink:

Any help appreciated.

Regards,

Sally

#2

You can have as smal (pow2) textures as you want. So 8x16 is ok. What the line says is that you can be sure that opengl supports 64x64, and smaler, textures. If you need larger textures, you’ll need to check if they are supported. Most cards support 4096x4096 nowdays.

#3

Hi! I prepared a very simple tile demo for JOGL. It basicaly benchmarks two different methods of rendering textured quads to screen (immediate mode vs. display lists). The demo simply loads one tile (.png) and draws it to screen multiple times. You can find the pre-compiled binary and source at:

http://www.g0dmode.com/javastuff/jogl-tiledemo.zip

ps. On my Amilo laptop with Radeon 9600 Mobility card, the demo renders ~600000 16x16 tiles per second. Interestingly enough, the display list method is a bit slower (about 500000 tiles / s) - this is definitely due to the small size of used list (just one textured quad).

Cheers

#4

um…

Exception in thread “main” java.lang.Error: Do not use javax.swing.JFrame.add() use javax.swing.JFrame.getContentPane().add() instead
at javax.swing.JFrame.createRootPaneException(JFrame.java:465)
at javax.swing.JFrame.addImpl(JFrame.java:491)
at java.awt.Container.add(Container.java:307)
at TileDemo.execute(TileDemo.java:37)
at TileDemo.main(TileDemo.java:22)

#5

Doh. Worked for me (of course if should not have :o) I’ve updated the zip.

Modified: Ahah! It was my 1.5.0-beta2 JVM that had a more laid-back attitude towards adding stuff directly to JFrame ;).

#6

power mac g4, 1ghz (values change with every run a bit):


      public void renderMethod2(int x, int y, GL gl)
      {
            MATRIX_TRANSLATION[12] = x;
            MATRIX_TRANSLATION[13] = y;
            gl.glLoadMatrixf(MATRIX_TRANSLATION);
            gl.glCallList(displayListHandle);
      }

1000000 tiles rendered with method1(immediate) in 6003ms, which makes 166000 tiles/s
1000000 tiles rendered with method2(display lists) in 6853ms, which makes 145000 tiles/s

instead of using a full matrix, let’s just translate:


      public void renderMethod2(int x, int y, GL gl)
      {
            gl.glPushMatrix();
            gl.glTranslated(x, y, 0);
            gl.glCallList(displayListHandle);
            gl.glPopMatrix();
      }

1000000 tiles rendered with method1(immediate) in 6081ms, which makes 164000 tiles/s
1000000 tiles rendered with method2(display lists) in 6393ms, which makes 156000 tiles/s

and now, let’s assume we’re at the right position already (which is - in most cases - pretty useless) :slight_smile:


      public void renderMethod2(int x, int y, GL gl)
      {
            gl.glCallList(displayListHandle);
      }

1000000 tiles rendered with method1(immediate) in 6131ms, which makes 163000 tiles/s
1000000 tiles rendered with method2(display lists) in 3846ms, which makes 260000 tiles/s

what a slow video-card i have…

and apple states:
for a list use a minumum of 16 verticies, less slows you down

#7

Apple knows its OpenGL :).

#8

Thank you very much for that demo. That was very useful indeed.

I only got 11000/s in both modes though which seems very slow compared to yours figures :-/

Am using a Matrox G450 card, Red Hat Linux 7.2, 512 Megs Ram and a 1 Gig processor.

Thanks again for the demo.

Regards,

Sally

#9

For having worked (or tried to work) with a G450, I think that you have good figures for this very nice card :smiley:

#10

Have tried using your 3 classes, Tile, Texture and TextureIO. My 8x16 png images render at roughly 17000 tiles per second (both modes) and it is simple to position the images at their correct size and at any location on the glcanvas. Thank you for that. :-*

But using my original gldrawpixels method I am getting about 34500 images per second (over twice as fast as the textured quad methods) - this is still too slow - that’s why I attempted writing textured quads in the first place(hoping to speed up my application). :’(

My original testing of textured quads (a day or so before I got your code), I appeared to be getting about 175000 tiles per second (blindingly fast for what I want) but did not know how to control the size or location. :stuck_out_tongue:

The code which gave me a wonderful 175000 tiles per second is below. The figures are all arbitary and were just a way of getting the quads to come out within a loop.

gl.glBegin(GL.GL_QUADS);
for (int i = 0; i< 7000; i++)  // send it round in large loop
{
   gl.glTextCood2f(0.0f, 0.0f); gl.glVertex2f(x+(5*i),
      x + (5* i));
   gl.glTextCood2f(1.0f, 0.0f); gl.glVertex2f(x+(5*i),
      x + (5* i));
   gl.glTextCood2f(1.0f, 1.0f); gl.glVertex2f(x+(5*i),
      x + (5* i));
   gl.glTextCood2f(0.0f, 1.0f); gl.glVertex2f(x+(5*i),
      x + (5* i));
}

}

Any ideas ?

Regards,

Sally

#11

Why not use batch commands ? Put quads into big array and draw it at once. Currently you are testing performance of JNI binding/opengl driver, not that of the GPU itself.

#12

[quote]Why not use batch commands ? Put quads into big array and draw it at once. Currently you are testing performance of JNI binding/opengl driver, not that of the GPU itself.
[/quote]
Yes, I’m aware of that. The original point was to test fast blitting of “tiles” to arbitrary locations on screen. So, no simple batching can be applied (display lists, VBO, etc).

Edit: sally, what kind of use cases you’re facing? Arbitrary blitting or somekind of grid scheme?

#13

It’s more like a grid display, I guess. All I’m trying to do at the moment is draw 8x16 rectangles just like your demo. I use 2 seperate tiles (from 2 png files of the same size), (tileone and tiletwo). Supposing I had 40 rows of these images and 70 columns, I would have 2800 images on my glcanvas (some of them would be tileone and some tiletwo). When the user presses a . key, the whole screen is redrawn and where some grid areas were tileone, they now become tiletwo and visa versa. When the user keeps his/her finger on the . key, the canvas should change constantly and at a reasonable rate (it’s an analysys tool and the user’s eye is looking for raster patterns) and whilst the program does work correctly, the changing of the display is slow and jerky with the techniques I have tried so far. If I could only get this to work at a decent rate I would be a very, very happy lady. ::slight_smile:

I am really very new to graphics programming and opengl etc although I have done a fair bit of Java programming (mainly for fun and learning) when I was at school.

Thanks for your help.

Sally

#14

[quote]Why not use batch commands ? Put quads into big array and draw it at once. Currently you are testing performance of JNI binding/opengl driver, not that of the GPU itself.
[/quote]
Yes, I understand what you mean. I shall give that a whirl.

Thanks

Sally

#15

sally, are you doing anything else per tile. Possibly binding the texture? It will slow you down. Instead bind texture1, then draw all tiles using texture1. Bind texture2 and draw all tiles using texture2, etc.

#16

[quote]When the user keeps his/her finger on the . key, the canvas should change constantly and at a reasonable rate (it’s an analysys tool and the user’s eye is looking for raster patterns) and whilst the program does work correctly, the changing of the display is slow and jerky with the techniques I have tried so far.
[/quote]
Ok, roughly, what kind of frame rates are you after? Even the most unoptimal way of drawing the tiles(showcased in the demo) would result in ~4 frames/s for your setup (11000 / 2800). I think this figure could be quite easily raised to 10 or 20 fps. Are the tiles changed arbitrarily or are there somekind of patterns or rules in the process? Also, what kind of scheme are using for the keyboard input?

Cheers

#17

I’ve updated the demo to include a simple example (run with tiledemo2.cmd) of using vertex arrays to achieve better fillrate. There’s a new class called TileGrid which is a grid based representation of tiles. The grid can be modified dynamically - i.e. the tile images can be changed at each grid location separately.

PS. On my Amilo P4-HT 2.6GHz, ATI Radeon 9600 Mobility the following is printed out:

“10000 20x20 tile grids rendered in 1313ms, which makes 7000 grids/s and 2800000 tiles/s”

#18

I think I would be happy with 20fps, but 30 would be better. To give you a bit more detail about what I’m doing: the program is a bit analyser. The data (1s and 0s represented by the 2 tiles) are read in and stored in an array. If the user sets a rasterwidth of 70 then the 1s and 0s in the array would be displayed wrapping around over 70 columns. So when the user presses the . key (also the > key on a qwerty keyboard) the rasterwidth would increase by 1 making all the bits wrap around 71 columns. If the user presses the , (or < key) the rasterwidth would decrease by 1 giving 70 again. Each time the appropriate key is pressed all the tiles are re-read in from the array and appear to be shuffled around on the canvas. If the user kept their hand on , key, for instance the rasterwidth should slikly move down to 1 column (going through each rasterwidth from 70 - 1 on the way of course). Interesting patterns can be spotted by the human eye over various widths which give frame lenghts of some types of data.

For my keyboard input I have just used an awt.Event KeyListener.

Regards,

Sally

#19

[quote]I’ve updated the demo to include a simple example (run with tiledemo2.cmd) of using vertex arrays to achieve better fillrate. There’s a new class called TileGrid which is a grid based representation of tiles. The grid can be modified dynamically - i.e. the tile images can be changed at each grid location separately.

PS. On my Amilo P4-HT 2.6GHz, ATI Radeon 9600 Mobility the following is printed out:

“10000 20x20 tile grids rendered in 1313ms, which makes 7000 grids/s and 2800000 tiles/s”
[/quote]
Thanks for the new demo. Although my results were far from impressive on my 1Ghz Intel Pentium III, Matrox G450 - the program stood still for about 10 minutes before giving:

10000 20x20 tile grids rendered in 325425ms, which makes 0 grids/s and 0 tiles/s
10000 20x20 tile grids rendered in 325325, which makes 0 grids/s and 0 tiles/s

Do these results mean I’m not going to get my 20fps? :-/

Regards,

Sally

#20

Hmmm, it seems that the vertex arrays are really ineffective on your board. That’s no surprise really, because the arrays are transferred to the GPU from Java heap each time they are drawn. I’m actually working on a VBO version of the demo (this is the last one, I promise :wink: ), which should perform quite nicely on board with VBO capabilities. I’ll post it here later on today…