PDA

View Full Version : *_make_current_read



Zengar
04-04-2006, 10:02 AM
Unfortunaly I don't have a time to test it out myself, but I need this information to feed some thoughts, so it would be nice if someone who used this extensions (WGL or GLX style) could contribute to an answer :-)

With this extension, we can read from one and write to another buffer (DC or drawable) in the same context. But is it possible to bind the same buffer to different context at the same time (in different threads)? I want to render to an offscreen buffer and transfer the final image to a window using glCopyPixels, but I don't want to do any context changes. I thought maybe that I can render to a pbuffer in one thread with one context and then copy the image to another one in the second thread. Would it be possible (and fast?) ?

Thanks a lot!

jide
04-04-2006, 12:56 PM
I also haven't tested it myself as I didn't knew this extension, but from what I read from specs, it seems quiete old (from GLX one):



This paves the way for allowing preprocessing of image data in an "off screen" window which is then read into the visible window for final display
I don't know what are your needs, but maybe you should have a look at FBO, even better than pbuffers now.

Zengar
04-04-2006, 01:45 PM
Well, to be frank, I think of an 3d API of my own, so to speak "OpenGL 3.0" :-) - for fun and self-educational reasons It should work on the top of the OpenGL and provide fully flexible pipeline(from batch setup to fragments etc.) using compact functional shading language. The problem is the window system implementation. I want to make it like current FBO: you create a bunch of buffers and bind them to a framebuffer, teh framebuffer can then be bound to a window or to a texture, but exists separately from it. So I considered implementing the framebuffers as pbuffers and copy the final image to the window using a "dummy" context. the *_make_current_read sounds just like what I need, but I would like to avoid the context change (so to render to a buffer while it is readonly-bound to an rc in another thread). Of course, when ARB_framebuffer_object_blit ( + multisample) will be implemented, I won't need any pbuffers, but it will take time.

jide
04-04-2006, 02:45 PM
You are really courageous :) I will never try to do such things, too hard for me. Good luck !