[eq-dev] Wrong Thinking
Stephen Furlani
I'm sure this is a case of 'wrong thinking' on my part, and a general
lack of understanding of C++ STL:
bool getContext(eq::Config* eqConfig, AGLContext eqAGL_CTX, int node,
int pipe, int window)
{
//return specified
const eq::NodeVector& nv = eqConfig->getNodes();
const eq::PipeVector& pv = nv[node]->getPipes();
const eq::WindowVector& wv = pv[pipe]->getWindows();
eqAGL_CTX = ((eq::AGLWindow *)(wv[window]->getOSWindow()))-
>getAGLContext();
return true;
}
But the above code returns an error on the "nv[node]->getPipes();"
line in the vector.h STL file.
/**
* Returns a read-only (constant) iterator that points to the
* first element in the %vector. Iteration is done in ordinary
* element order.
*/
const_iterator
begin() const
{ return const_iterator (this->_M_impl._M_start); }
and gives me a EXC_BAD_ACCESS which I think is an incorrect pointer to
memory... I've tried turning on NSZombieEnabled but it gives me
pretty much the same thing.
(gdb) print this
(const __gnu_norm::vector<eq::Node*,std::allocator<eq::Node*> > *
const) 0x194
(gdb) print this->_M_impl
Cannot access memory at address 0x194
Is there a better way of getting the AGLContext object out of
Equalizer? I'm working with how eqHello creates things, and I noticed
that configVisitor goes about it a bit differently.
-Stephen
_______________________________________________
eq-dev mailing list
eq-...@equalizergraphics.com
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
Stefan Eilemann
<stephen...@gmail.com> wrote:
> I'm sure this is a case of 'wrong thinking' on my part, and a general
> lack of understanding of C++ STL:
>
> bool getContext(eq::Config* eqConfig, AGLContext eqAGL_CTX, int node,
> int pipe, int window)
> {
> //return specified
> const eq::NodeVector& nv = eqConfig->getNodes();
> const eq::PipeVector& pv = nv[node]->getPipes();
> const eq::WindowVector& wv = pv[pipe]->getWindows();
> and gives me a EXC_BAD_ACCESS which I think is an incorrect pointer to
> memory...
It looks to me that node is out-of-bounds, and you dereference a 0
pointer. Check that node is not bigger or equal to nv.size().
> Is there a better way of getting the AGLContext object out of
> Equalizer? I'm working with how eqHello creates things, and I noticed
> that configVisitor goes about it a bit differently.
Where are you doing this? Why do you need the AGLContext there? In
general, it is quite dangerous to play around with GL context's in
places and threads, unless you're sure of what you are doing. Normally
it's less painful to move this stuff, e.g., to Window::configInitGL.
The ConfigVisitor/accept follows the Visitor pattern. Google can
explain it better then me.
HTH,
Stefan.
Stephen Furlani
On Jan 28, 11:43 am, Stefan Eilemann <eilem...@gmail.com> wrote:
> On Thu, Jan 28, 2010 at 3:49 PM, Stephen Furlani
>
> <stephen.furl...@gmail.com> wrote:
> > I'm sure this is a case of 'wrong thinking' on my part, and a general
> > lack of understanding of C++ STL:
>
> > bool getContext(eq::Config* eqConfig, AGLContext eqAGL_CTX, int node,
> > int pipe, int window)
> > {
> > //return specified
> > const eq::NodeVector& nv = eqConfig->getNodes();
> > const eq::PipeVector& pv = nv[node]->getPipes();
> > const eq::WindowVector& wv = pv[pipe]->getWindows();
> [...]
> > and gives me a EXC_BAD_ACCESS which I think is an incorrect pointer to
> > memory...
>
> It looks to me that node is out-of-bounds, and you dereference a 0
> pointer. Check that node is not bigger or equal to nv.size().
>
I'm passing node = 0.
I looked more deeply into it and come to find out, eqConfig was 0x0.
I fixed that, but the problem happens intermittently and I think it
has to do with Objective-C++'s gc. It doesn't throw any errors when I
run it in eqHello.cpp
> > Is there a better way of getting the AGLContext object out of
> > Equalizer? I'm working with how eqHello creates things, and I noticed
> > that configVisitor goes about it a bit differently.
>
> Where are you doing this? Why do you need the AGLContext there? In
> general, it is quite dangerous to play around with GL context's in
> places and threads, unless you're sure of what you are doing. Normally
> it's less painful to move this stuff, e.g., to Window::configInitGL.
>
> The ConfigVisitor/accept follows the Visitor pattern. Google can
> explain it better then me.
>
> HTH,
>
> Stefan.
>
Gah, I suppose this is what I get for not being a CS major.
I'm trying to get the CGLContextObj in the NSOpenGLView to point to
the CGLContextObj created by Equalizer (in the AGLWindow). I'm doing
it in the "main" section of the software...
It's a horrible idea, I know, but it was a shortcut instead of re-
writing 56 calls to [self getCGLContext] (in one class, out of 12
classes). I need the cgl_ctx out of equalizer anyway, so I thought
I'd kill 2 birds with one stone. (You'd think for a program whose
sole purpose is to render textures on rectangles would have
encapsulated the rendering portion of their software, but no.)
regardless, here's a snippit of code:
CGLContextObj cgl_ctx = [[NSOpenGLContext currentContext]
CGLContextObj];
glBegin (drawType); // draw either tri strips of line strips (so this
will drw either two tris or 3 lines)
glTexCoord2f (startXTexCoord, startYTexCoord); // draw upper left in
world coordinates
glVertex3d (startXDraw, startYDraw, 0.0);
glTexCoord2f (endXTexCoord, startYTexCoord); // draw lower left in
world coordinates
glVertex3d (endXDraw, startYDraw, 0.0);
glTexCoord2f (startXTexCoord, endYTexCoord); // draw upper right in
world coordinates
glVertex3d (startXDraw, endYDraw, 0.0);
glTexCoord2f (endXTexCoord, endYTexCoord); // draw lower right in
world coordinates
glVertex3d (endXDraw, endYDraw, 0.0);
glEnd();
Where the current context is set by mouse movement in a different
method (many methods, actually)
if( [[self window] isVisible] && [[self window] isKeyWindow])
{
[drawLock lock];
[[self openGLContext] makeCurrentContext];
where self is a NSOpenGLView, which contains a NSOpenGLContext. And I
can create an NSOpenGLContext by passing it a CGLContext in the Mac OS
X SDK 10.6. There are other functions like:
drawRect:(Rect) aRect withContext:(NSOpenGLContext)
which will draw in the window, but if clicked or dragged, it won't
refresh in the window (since those functions default to [self
openGLContext]).
I'd really rather not have to re-write the entire rendering/GUI/
database portions of the software right now... but it looks like I
won't have that luxury.
-Stephen
Stefan Eilemann
On 28. Jan 2010, at 21:56, Stephen Furlani wrote:
> I'm trying to get the CGLContextObj in the NSOpenGLView to point to
> the CGLContextObj created by Equalizer (in the AGLWindow). I'm doing
> it in the "main" section of the software...
>
> It's a horrible idea, I know, but it was a shortcut instead of re-
> writing 56 calls to [self getCGLContext] (in one class, out of 12
> classes). I need the cgl_ctx out of equalizer anyway, so I thought
> I'd kill 2 birds with one stone. (You'd think for a program whose
> sole purpose is to render textures on rectangles would have
> encapsulated the rendering portion of their software, but no.)
The difficulty with this approach is that you have to be very careful on how you handle your OpenGL context. The main issues are described in [1], which should bring you up to speed regarding the does and don'ts of OpenGL and multi-threading.
The easiest really is to do all your GL stuff in Equalizer from Channel::frameDraw. If it helps to have your application window in the main thread (and other Eq-windows in other threads), have a look at non-threaded pipes. They are not recommended though, since there are a couple of performance issues with scalable rendering modes.
> I'd really rather not have to re-write the entire rendering/GUI/
> database portions of the software right now... but it looks like I
> won't have that luxury.
In my experience this often is the faster (or only) way, because otherwise you'll be in a lot of pain figuring out all the bugs and errors in your approach.
Cheers,
Stefan.
[1] http://www.equalizergraphics.com/documentation/parallelOpenGLFAQ.html