Intel 2700G performance vs Vincent OpenGLES

Hi all,

i’m new to this forum - so i am not sure my question is placed right here.
Anyway - here’s the story and the question:

I am developing a map display sw in JAVA including a JNI layer to openGL.
As you know the X51v supports openGl (common lite profile) by hardware (Intel G2700). For performance measures i wrote a little benchmark which displays ~2000 lines rotating over 3 axes.

When using Intels hw support library (libGLES_CL.dll) i get ~6-10 FPS.
Thats not very much.

Now the question:
When using the Vincent OpenGL_ES library - which is an open source implementation of OenGL_ES and is a software implementation only - i get ~12-16 FPS.

Does anyone have an Idea of an explanation for that behaviour ?


Performance should certainly be much better than that. How are you drawing the lines? Are you doing anything else in your main render loop? Which render states do you set?

No - nothing but an endless loop with a repaint() call.

I am working with a GLfixed buffer, allocated as native buffer.
The code is just simple:

protected boolean eglInitialize(int aWidth, int aHeight)


return true;


Whenever a resize happens:

protected void eglReshape(int aWidth, int aHeight)
GL.getGL().glViewport(0, 0, aWidth, aHeight);
if (!getEgl().success())
System.out.println(“glViewport:” + getEgl().getError());
System.out.println(“glViewport:” + aWidth + “/” + aHeight);

GL.getGL().glScissor(0, 0, aWidth, aHeight);


float lAspect = ((float)aWidth / (float)aHeight);
GLU.gluPerspective(90.f, lAspect, _NearDistance, _FarDistance);


Initialization for the Line buffer (happens once)
private void initLinesTest02(Component aComponent)
int lIncrement = 10;

for (int Y = 0; Y < aComponent.getHeight(); Y += 2)
  addLine( (float) 0, (float) Y/100f, (float) aComponent.getWidth()/100f, (float) Y/100f);
for (int X = 0; X < aComponent.getWidth(); X += 2)
  addLine( (float) X/100f, (float) 0, (float) X/100f, (float) aComponent.getHeight()/100f);


… and last not least: the drawing:
lTime is just an incrementing variable to get different angles
_Mode is set to GL.GL_FIXED.

public int draw(EGL aEGL, java.awt.Color aColor, float aRotationX, float aRotationY, float aRotationZ)


GL.getGL().glTranslatef(0.f, 0.f, -10f);
GL.getGL().glRotatef((float)(lTime), aRotationX, aRotationY, aRotationZ);
lTime = (short)(lTime%360);
if (lCount > 0)
  GL.getGL().glVertexPointer(2, _Mode, 0, _ByteBufferVertices);
  GL.getGL().glDrawArrays(GL.GL_LINES, 0, lCount);
  if (!aEGL.success())
    System.out.println("glDrawArrays FAILURE" + aEGL.getError());

return lCount/2;


sorry - i forgot:

draw is called 4 times per frame with some rotation params:

draw(aCanvasEgl.getEgl(), java.awt.Color.yellow, 1, 1, 1);
draw(aCanvasEgl.getEgl(),, 0, 0.0001f, 1);
draw(aCanvasEgl.getEgl(),, 0, 1, 0);
draw(aCanvasEgl.getEgl(),, 1, 0, 0);

may be i should wait a few seconds before posting a reply;)

the screen resolution is set to 480/640 (full vga)
lines (horizontal and vertical) per draw: 2242.

What line width are you using?

So if I understand you correctly, you’re drawing 8968 lines per frame, at 6-10 fps. That still seems too low to me, even if it’s ~90k triangles/s (lines are drawn as two triangles by the hardware). I don’t think lines are implemented very efficiently.glBenchmark shows that you should easily be able to get more than twice that.

The 2700G accelerates triangle setup and rasterization. It shines when you render textured, antialiased triangles with blending and high depth complexity. But neither tri setup nor fillrate should really be a bottleneck when you’re drawing simple lines. So a software rasterizer shouldn’t be far behind, but it shouldn’t be ahead either.

Maybe you could try to create and use two triangles per line (either 6 vertices with duplicates or 4 + index)? That could result in some speed-up.

btw, why do you use scissor if you set it to the viewport size anyway? :slight_smile:

Sorry for the late response - thread notification was realized as spam.

Linewidth = 1.0f

I di what you proposed - i am drawing now triangles.

To keep it comparable i used 3 vertices per line - not 6 as you proposed.
performance is now: HW-dll: 15 FPS, Vincent DLL: 3 FPS.

Scissorbox: is in use to verify that GL does not paint into windows in use by the surrounding HMI. Only the Center window should be used by GL.
Normally it was not necessary but there seems to be a small bug within the viewport code: the window size of the viewport is only set correctly after the 2nd viewport call. therefor i used the scissorbox to ensure that GL does not draw out of the bounds of its window.

Conclusion from my side:

The overall performance is better with triangles than with lines.
Performance is still less than expected.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.