glDrawArrays and memory fragmentation

Hello to all,

I have a problem with the glDrawArrays function and I can not find an explanation.

Environment: Windows 10 and a Win32 application (VB6 + Ocx written in VC++ 2015)
In the OnDraw of the ocx the glDrawBuffer is used every 100 ms to display data from device (a 2D curve).

The curve is displayed regularly.
In the loop the simplified code is

glVertexPointer (2, GL_DOUBLE, 0, m_dataCh1);
glColor3ub (GetRValue (m_foreColorY1), GetGValue (m_foreColorY1), GetBValue (m_foreColorY1));
glDrawArrays (GL_LINE_STRIP, m_currArrayStart, m_currArraySize);

Problem: during the display (which can last 30 minutes), they are continuously allocated
pieces of 1 or 2 M memory (Private Data). At the end, the memory is so fragmented that
the application becomes unusable. I noticed that the allocations source is the glDrawArrays.

What am I doing wrong?

(I attach a program image to work and allocated and fragmented memory)

Thanks !

What you’re doing wrong is continually allocating and freeing memory.

glDrawArrays, contrary to what you might expect, does not actually draw immediately: instead it will copy off your parameters, queue up the draw call in your drivers command buffer, then return and allow your program to continue running. At some arbitrary later point in time your driver will pick up all queued-up work and run it’ that’s when drawing actually happens. So you’ll typically have at least two blocks of memory in flight: one for the current draw call you’re building, one for a previous draw call you’ve submitted but that has not yet been run.

The solution is to not constantly allocate and free memory. Instead, allocate a fixed amount one-time-only during program startup and reuse that each time. If you know that you’ll never use more than 4mb then go ahead and allocate the whole 4mb - it doesn’t matter if you actually only need 1mb 75% of the time, that’s a false optimization, as you’ve discovered.

Right now you’re using client-side arrays via system memory allocations, which is an old-school OpenGL 1.1 approach. From OpenGL 1.5 onwards the ability to store data in GPU memory via buffer objects exists, but it may not be a performance gain depending on your use case, and I’m not certain if it’s even available in VB6.

Thanks for the answer, but maybe I did not explain it clearly.

The application allocates once the array with the data to display.

At the DrawArray function, every 100 ms, I pass the initial element and the items number to be displayed. The array allocated by the application does not grow during the display.
It’s the DrawArrays that always allocates pieces of memory and I can not do anything.

The application uses OpenGl 1.1 because it is the version supported by Windows (do not ask why).

I could use other versions of OpenGl through GLEW but before I change everything i would like to understand if there is an explanation of the behavior of DrawArrays.

If I wanted to use VBO mode, what would the minimum sequence of function call for data visualizations without using the DrawArrays?

Thanks again

No, no, no, no, no, no, no.

OpenGL does not work this way and the version of OpenGL available does not depend on the OS.

The crap software implementation provided by default on Windows is limited to OpenGL 1.1; but nobody uses that. OpenGL, and the OpenGL version you can use, is determined by your GPU and your device driver.

Keep calm, please … :slight_smile: It was exactly what I meant, so we agree. It is the library for Visual C++ that does not support the call to some functions and so it is necessary to use them dynamically …

As for the code skeleton I was asking you, for the buffer allocation section, drawing and deallocation of buffer, can you tell me something?

Thank you

take a look at any recent “first-triangle” demo code (that uses openGL 3.3 or a newer version)