OpenGL works slow without graphics drivers, and also in Virtual Machines (VMWare) ?

What makes you believe that the documentation will help me ?

Bye,
Skybuck.

Ok,

I took a lazy approach and simply disabled some open api calls which were
probably queueing opengl commands.

Then I started to get a hunch for what the problem was:

It turns out the "double" buffering is causing a major slowdown:

When mOptionDoubleBufferEnabled is set to true, things become extremely
slow.

When mOptionDoubleBufferEnabled is set to false, everything runs faster, but
the drawing starts to flicker

I don't think GDI would flicker that much... this means opengl software
driver just sucks compared to gdi.

// if double buffering is enabled then draw to backbuffer
if mOptionDoubleBufferEnabled then
begin
mOpenGLAPI.glDrawBuffer( GL_BACK );
end else
// else draw to front buffer
begin
mOpenGLAPI.glDrawBuffer( GL_FRONT );
end;

.... opengl draw codes...

// if double buffering is enabled then we still need to copy it to the
front buffer
if mOptionDoubleBufferEnabled then
begin
mOpenGLAPI.glReadBuffer( GL_BACK );
mOpenGLAPI.glDrawBuffer( GL_FRONT );
mOpenGLAPI.glCopyPixels( 0, 0, ClientWidth, ClientHeight, GL_COLOR);
end;

mOpenGLAPI.glFlush;

Bye,
Skybuck.

A possible solution could be to:

// glCopyPixels not used this api any more as it seems the cause of the slow
down.

// glFlush perhaps also leave this out.

And instead use:

SwapBuffers( Canvas.Handle ); // windows api call.

From what I can remember I didn't like this solution at first because this
limits the rendering speed of opengl to 60 hz or so... or it adds some
milliseconds of waiting time.

As I wanted to use the same code for gpgpu or so.... I didn't want this 60
hz limitation/retrace limitation.

But it seems this has to be used for slower systems.

Swapping the buffers instead of copieing the pixels makes sense... I can
imagine the swap buffer call to simply swap some pointers here and there.

The performance is much better, and double buffering can be used so no more
blinking.

Even when double buffering is off it seems to work, not yet sure why... and
no flicker so far.

It's note worthy to note that previous method was faster for single
buffering but produced unwanted flicker.

I am not sure if the ReadBuffer call and the DrawBuffer call are still
needed. From what I remember these specify the source and dest buffer for
the glCopyPixels call, so these calls can probably be left out.

I can vaguely remember SwapBuffers to work with two buffers always... it
seems to make sense... one offline and one online buffer... so any other
buffer calls probably not needed when using this api.

Well now I know how to fix my application so it runs on "default windows"
with acceptable speed and no flicker...

Bye,
Skybuck.

Ofcourse I should still make sure GDI is supported as well and can be switch
to for safe heaven...

Because ya never know... opengl could have more unpleasent surprises ! =D

Bye,
Skybuck =D

What you state in the title should come as no surprise.

OpenGL and Direct X both provide graphics-intensive programs with a
standardized interface for doing things applicable, for example, to 3D
animation.

This replaces having to write those programs only to work with the
graphics acceleration on one particular video card - or with modules
for all the different video cards.

So, if you don't have the drivers, if you are inside a virtual machine
which has just a plain Super VGA card without acceleration, your
OpenGL driver has to do all the computational work itself, without
making use of the graphics acceleration features of your video card.
As you've observed, this causes a major slowdown.

Profiling is not the answer. The answer is to either get the drivers,
or have one's virtualization software pass through the type of video
card you actually have - select that video card in one's virtual
machine, and ensure that the virtualization software handles it by a
pass-through.

John Savard

On Jul 17, 9:53*am, "Skybuck Flying"
wrote:
What makes you believe that the documentation will help me ?


Well ... It usually helps *me* when I read it (which
I often do)

What makes you believe that the documentation will help me ?


Well ... It usually helps *me* when I read it (which
I often do)


I don't know whether it is a rule or exception, but reading docs helps
me as well ...

"Skybuck Flying" wrote in message
b.home.nl...

What makes you believe that the documentation will help me ?

Bye,
Skybuck.

You see this is why I don't block this guy, some of his comments are
hilarious.

Almost worth quoting that one.

Thanks Skybuck

On Jul 17, 7:06*pm, "David" wrote:

You see this is why I don't block this guy, some of his comments are
hilarious.


Yep.

On Jul 17, 11:06*am, "David" wrote:
"Skybuck Flying" *wrote in message
b.home.nl...

What makes you believe that the documentation will help me ?

You see this is why I don't block this guy, some of his comments are
hilarious.

His comment would be _more_ hilarious if the documentation that came
with video cards these days said anything more than "avoid static
electricity when you plug it in".

It is true that, as I noted in my post, some basic understanding of
what OpenGL is and does would clear up the problem. And, if one knows
where to look online, there is a lot of information about OpenGL,
including documentation by the open-source project behind it.

But if one is looking *there*, there is quite a wealth of material
available, and without the basic understanding needed to know *where
to begin looking*, it's entirely possible he would fail to be helped
for another reason.

John Savard