Re: problem with displayCallback and Double buffering

"Marc A. Ziegert" <[email protected]>
Newsgroups gmane.comp.lang.haskell.hopengl
Message-ID <[email protected]>
wow. thanks.
i think, i have to compile again...
and read about all the configurations first.

- marc


Am Mittwoch, 5. November 2003 01:04 schrieb Wolfgang Thaller:
> 
> On 05.11.2003, at 00:34, Marc A. Ziegert wrote:
> 
> > i've installed ghc-6.3.20031102 (still the "-lGL" <--> "-lGLU" bug in 
> > package.conf).
> > that version works now, thanks.
> >
> > now i want to use ghci, especially with
> > forkIO mainLoop
> > , but that does not seem to work anymore. is that a forkIO bug?
> 
> Hmm... did you build ghc with the --enable-threaded-rts flag? If so, 
> you should be using forkOS instead of forkIO; forkIO creates a 
> lightweight thread, but most OpenGL implementations require a 
> (heavyweight) OS thread to run reliably. With GHC 6.3 
> --enable-threaded-rts, this means you can call GLUT/OpenGL from the 
> main thread, from threads created using forkOS, and from foreign 
> exported functions, but not from threads created using forkIO.
> 
> If you're not using --enable-threaded-rts, then you could encounter a 
> different problem: GHCi only gets a chance to run while the GLUT 
> mainLoop is inside a callback, and while GHCi is waiting for input 
> using readline, the GLUT mainLoop will be blocked. Things might work if 
> you build GHC without readline support and install an idle callback 
> into the GLUT event loop.
> 
> In both cases, keep in mind that all the OpenGL drawing has to be done 
> from the thread that GLUT is running in. You can use MVars to 
> communicate with that thread from the GHCi prompt, but doing OpenGL 
> drawing from the GHCi prompt while a GLUT mainLoop is running in the 
> background will never work reliably.
> 
> Grüße,
> 
> Wolfgang
> 
> _______________________________________________
> HOpenGL mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/hopengl
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.