hail warriors.

does anybody know if glFinish() works on gl-functions implemented by extensions?

particularly those that manage pixel-buffers, supported by extension GL_EXT_pixel_buffer_object. I'm working on a benchmark that waits for those gl-operations to return ..



enjoy coding,
d3lphi

Yes, it should.

By the way, what is the difference between glFinish() and glFlush() ?

glFinish flushes the network just like glFlush but after it does that it waits for notification from the graphics hard ware or the network indicating that the drawing is complete in the framebuffer.

Just in case you are not quite sure what flushing the network (that doesn't mean only multiple computers, it can mean one computer if you that computer is doing the calculations and rendering it too) it forces previously issued commands to start.

well, ok, but what if the ogl-commands don not draw to the framebuffer but, p.e. just transfer data to the VRAM? Does glFinish() still wait for notification?

glFinish guarantees that all previously issued commands will complete within finite time, which is pretty weak really. In practice, it tends to stall until all previosuly issued commands hae been completed, but this isn't really guaranteed. What exactly are you trying to do?

Joakim, I think you're thinking of glFlush. glFinish is stronger; it is guaranteed not to return until all commands have been completed.

From the spec:

"5.5 Flush and Finish

The command

...

I'm trying to make more than one thread operate on the same RC in a performance-testing app. I know i have to be very careful in sharing the resources.

Currently i try to keep the thread the message-loop is running on from interfering with the drawing thread.
For example is there no need for the window to respond to messages concerning redrawing because the drawing thread redraws the window anyway..


Questions:
- Does anyone know if there is a simple way of ignoring all messages concerning window-redrawing?
- How does wglMakeCurrent() interact with glFinish()?
- Does opengl care about threads and who(which thread) has got the RC at all?

btw thanks for your attention

d3lphi

- Just ignore WM_PAINT and WM_ERASEBKGND, that should do the trick.
- They don't interact. When you switch to a new context, the previous context is automatically flushed, which means all queued operations are begun (but not necessarily finished.) glFinish blocks until all queued operations are finished.
- A context can only be current in one thread at a time. Since you have a drawing thread that has the context all the time, and a window thread that doesn't need to bother with the context at all, this shouldn't be an issue.

An aside: window-thread and render-thread seems like a very difficult way to set things up. Do you absolutely need to have the rendering code in a separate thread for your performance-testing purposes? If not, it will be much easier to keep them in the same thread and use a messagepump of the form: while (true) { process any queued messages; render frame; }.

ignoring didnt work, but by now its sufficient to make the window invisible. i have to look over the code anyway.


thanks a lot by now.
d3lphi