PolygonStipple on a SWT GLCanvas: ByteBuffer question

[TalanOFF]

Hi, everyone,

I've been looking for several days for a solution to my problem.

I'm currently trying to draw a simple rectangle on a GLCanvas.
It works pretty well but as soon as I try to add polygon stippling the rectangle doesn't get drawn at all.

Here's the code I use for it:

1. initialize a ByteBuffer instance as a stipple mask of
32x32 bits = 128 bytes

private void initByteBuffer(){
   //to avoid IllegalArgumentException the buffer capacity must
   //be 1024 + 128 bytes
   fly = ByteBuffer.allocateDirect(1024+128);
   fly.put(new byte[]{
	(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00,
	(byte)0x00, (byte)0x00, (byte)0x00, (byte)0x00,
	(byte)0x03, (byte)0x80, (byte)0x01, (byte)0xC0, 
	(byte)0x06, (byte)0xC0, (byte)0x03, (byte)0x60,
	(byte)0x04, (byte)0x60, (byte)0x06, (byte)0x20, 
	(byte)0x04, (byte)0x30, (byte)0x0C, (byte)0x20,
	(byte)0x04, (byte)0x18, (byte)0x18, (byte)0x20, 
	(byte)0x04, (byte)0x0C, (byte)0x30, (byte)0x20,
	(byte)0x04, (byte)0x06, (byte)0x60, (byte)0x20, 
	(byte)0x44, (byte)0x03, (byte)0xC0, (byte)0x22,
	(byte)0x44, (byte)0x01, (byte)0x80, (byte)0x22, 
	(byte)0x44, (byte)0x01, (byte)0x80, (byte)0x22,
	(byte)0x44, (byte)0x01, (byte)0x80, (byte)0x22, 
	(byte)0x44, (byte)0x01, (byte)0x80, (byte)0x22,
	(byte)0x44, (byte)0x01, (byte)0x80, (byte)0x22, 
	(byte)0x44, (byte)0x01, (byte)0x80, (byte)0x22,
	(byte)0x66, (byte)0x01, (byte)0x80, (byte)0x66, 
	(byte)0x33, (byte)0x01, (byte)0x80, (byte)0xCC,
	(byte)0x19, (byte)0x81, (byte)0x81, (byte)0x98, 
	(byte)0x0C, (byte)0xC1, (byte)0x83, (byte)0x30,
	(byte)0x07, (byte)0xe1, (byte)0x87, (byte)0xe0, 
	(byte)0x03, (byte)0x3f, (byte)0xfc, (byte)0xc0,
	(byte)0x03, (byte)0x31, (byte)0x8c, (byte)0xc0, 
	(byte)0x03, (byte)0x33, (byte)0xcc, (byte)0xc0,
	(byte)0x06, (byte)0x64, (byte)0x26, (byte)0x60, 
	(byte)0x0c, (byte)0xcc, (byte)0x33, (byte)0x30,
	(byte)0x18, (byte)0xcc, (byte)0x33, (byte)0x18, 
	(byte)0x10, (byte)0xc4, (byte)0x23, (byte)0x08,
	(byte)0x10, (byte)0x63, (byte)0xC6, (byte)0x08, 
	(byte)0x10, (byte)0x30, (byte)0x0c, (byte)0x08,
	(byte)0x10, (byte)0x18, (byte)0x18, (byte)0x08, 
	(byte)0x10, (byte)0x00, (byte)0x00, (byte)0x08
   });
}

2. Try to draw a rectangle using polygon stipple:

public void draw() {
	GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
	
	GL11.glEnable(GL11.GL_POLYGON_STIPPLE);
	GL11.glPolygonStipple(fly);

	GL11.glRectf(-0.5f, -0.5f, 0.5f, 0.5f);
	GL11.glFlush();
}

The result of this is black There should be a white/stippled rectangle right in the middle of the viewport but there is none.

I'm new to this OpenGL stuff in Java (but not to Java itself).
There must be something wrong with the ByteBuffer (especially the size of it) which I just don't understand. The rectangle is drawn the way I want it to be drawn when I GL11.glDisable(GL_POLYGON_STIPPLE)...

Why does the buffer has to be at least 1024 in size plus the actual bitmask?
And why doesn't it work (the ultimate question )?

I hope there's someone who can help me.
Thanks in advance.


Signed: TalanOFF

[Fool Running]

The reason for the buffer needing to be large (1024 bytes) is because it is hardcoded to that for some reason :lol: .
As for the problem, try adding a fly.flip() after you put the bytes into the buffer. The put() function increments the position of the buffer so you are trying to tell OpenGL to use the pattern after your first 128 bytes (i.e. all 0's) so nothing is drawn. Flip() should correct that. (If that is truly your problem :lol: )

BTW: I don't think you need to call glFlush() (someone can correct me on this)

For the Devs: Is there a reason why the buffer is hard-coded to be 1024 bytes? According to the OpenGL documentation, you can only supply a 32x32 1-bit bitmap to that function. (128 bytes)

[darkprophet]

Im not a dev, but I have asked that question before. Basically, there is a method somewhere that requires atleast 1024. So instead of finding out what each method call is limited to (which is alot of work), they just cap it to all methods.

Same reason why all IntBuffers have to have atleast 4 remaining.

DP

[TalanOFF]

Thanks for replying!

@Fool Running:
I've noticed that hard-coded issue but I don't get it... allocating one whole kB to just have 128 bytes being read and processed is a bit weird.

And you're right: there's no need to call glFlush() but I do that just to see how it works

@darkprophet:
Hmm, that looks like devs are out for more speed but also increase memory usage.

@all: solution
I have solved my problem now. Calling the flip() method on the byte buffer results in the same exception as if I had allocated not enough memory for the buffer (which has to have additional 1kB of space). Consequently the flip() method not only resets the current position to be zero but also sets the buffer limit to be the value of the position before the call.
Instead of calling flip() I had to use rewind() which really resets the current position to zero.

I hope that helps those who are facing same problems

Thanks for support!

@mods:
Feel free to close that one.

Signed: TalanOFF