Lack of standard for buffer handling and upload

[GoogleCodeExporter]

Currently there's a lack of standard on how buffers are uploaded or handled in 
general. In particular there's no description on which range is considered 
valid when it comes to manipulating buffers. 

There are several issues in particular:

LwjglRenderer and OGLESShaderRenderer use different ways of uploading the 
buffer. LWJGL uses the range [0, limit] for the buffer data, but uses 
[VB.offset, limit / compLength] for glVertexAttribPointer for all vertex 
buffers except index buffer. 
OGLES uses [0, capacity] for the buffer data, and uses [0, capacity / 
compLength] for all vertex buffers (in both cases clear() is used). Clearly 
OGLES and LWJGL use a different approach of uploading the buffer. This can 
cause issues of valid data being displayed where it shouldn't, for example 
BitmapText uses limit() to display only a certain number of characters, but due 
to OGLES different handling, text characters are displayed on screen that 
should not be displayed.

The second issues lays in how jME3 API itself exposes this information. For 
example VertexBuffer.getNumElements() uses the buffer's capacity instead to 
retrieve number of valid elements. VertexBuffer.updateData() detects changes to 
the buffer's limit and then forces a data size update, in compliance to how 
LWJGL renderer handles buffers. VertexBuffer.copyElements(), 
VertexBuffer.setElementComponent(), Mesh.scaleTextureCoordinates(), 
Mesh.prepareForAnim() and Mesh.setInterleaved() reset the buffer's limit to 
capacity, which is noncompliant to how the LWJGL renderer handles buffers. 
Mesh.updateCounts() uses the buffer's capacity to determine vertex count, which 
is noncompliant with the LWJGL renderer.

The third issue is how to handle the buffer's position value, which in all 
cases mentioned above is not used. The beginning of the buffer is always 
assumed to be zero, rather than the buffer's position. Any method mentioned 
above that computes length of anything by utilizing either limit() or 
capacity() is noncompliant with how Java specifies valid buffer ranges. Any 
method that calls clear() is noncomplaint with both requirements (position and 
limit). Any method that uses rewind() is noncompliant with the position 
requirement. 

Original issue reported on code.google.com by ShadowIs...@gmail.com on 4 Jun 2012 at 3:24

[GoogleCodeExporter]

Issue 503 has been merged into this issue.

Original comment by ShadowIs...@gmail.com on 4 Jun 2012 at 3:24

[GoogleCodeExporter]

Issue 502 has been merged into this issue.

Original comment by ShadowIs...@gmail.com on 4 Jun 2012 at 3:25

[GoogleCodeExporter]

After discussion with the jME3 team, it was decided that any jME3 method that 
manipulates buffers will treat the buffer as if its position was zero. In 
addition, the method may inadvertently force the buffer's position to become 
zero. Although this can be seen as a bug from user perspective, it is expected 
behavior as the buffer's position value is not used in any of the methods. This 
applies to data in both VertexBuffers and Images.

As for limit, it was decided that all jME3 API methods and renderers shall use 
the limit() to determine buffer size. Under no circumstances may the clear() or 
capacity() method be used to either set limit to capacity or determine buffer 
size.

Any methods that use capacity() shall now use limit(), and any methods that use 
clear() shall now use rewind().

Original comment by ShadowIs...@gmail.com on 4 Jun 2012 at 3:47

[GoogleCodeExporter]

Original comment by ShadowIs...@gmail.com on 9 Jul 2012 at 3:25

• Changed state: Started

[GoogleCodeExporter]

Original comment by ShadowIs...@gmail.com on 6 Sep 2012 at 6:11

• Added labels: Difficulty-Easy