October 2011 - HOpenGL

Re: [HOpenGL] [Haskell-cafe] ANN: Haskell OpenGL package updates
by Jason Dagit 30 Oct '11

30 Oct '11

On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett <ekmett(a)gmail.com> wrote: > Jason, > Thank you for taking ownership of HOpenGL! Thanks! > I would like to make a formal request for there to be some way to get access > to either > Graphics.Rendering.OpenGL.Raw.Core31.TypesInternal > or that > Graphics.Rendering.OpenGL.Raw.Core31.Types > re-export the newtype wrappers it places around CDouble and CFloat. > As things stand the only way to work with them is to pointlessly round-trip > through rational or pray that GHC is smart enough to automatically convert > once it sees through the newtype, which it isn't, potentially costing me > orders of magnitude of performance in tight loops in exchange for > implementation freedom the current OpenGL bindings do not use on any > platform. Yes, it's a real problem. I think there are a couple directions we could move in (and some may not even be mutually exclusive). Andy Gill created this workaround: {-# RULES "realToFrac/a->GLfloat" realToFrac = \x -> GLfloat (realToFrac x) #-} {-# RULES "realToFrac/GLfloat->a" realToFrac = \(GLfloat x) -> realToFrac x #-} That one helps a lot for most people. Someone made a libraries proposal that also helps the conversion situation but I don't have the details handy at the moment. If you read here, I'd like to get some MArray support in and I think it's possible, although I haven't the idea I proposed yet: http://www.haskell.org/pipermail/haskell-cafe/2011-March/090511.html Another thing we could do is find a different balance between newtypes and the C types. I'm totally onboard with exposing all of OpenGLRaw. I think we just need to sufficiently document the "internal" bits so that only people who absolutely need them will use them. That's how I see ByteString and it seems to be working there. Thanks for your suggestion (and your pull request on github, yay for collaborative tools!). Jason

2 1

Graphics.Rendering.OpenGL.GL.Shaders API needlessly "helpful"
by Edward Kmett 28 Oct '11

28 Oct '11

Is there any thought as to a better way to deal with https://github.com/haskell-opengl/OpenGL/blob/master/Graphics/Rendering/Ope… If you have code that dynamically constructs and deletes single shaders frequently, the API exposed there just introduces O(n) overhead for every such construction. *setAttachedShaders* :: Program -> ([VertexShader],[FragmentShader]) -> IO () setAttachedShaders p@(Program program) (vs, fs) = do currentIDs <- getAttachedShaderIDs p let newIDs = map shaderID vs ++ map shaderID fs mapM_ (glAttachShader program) (newIDs \\ currentIDs) mapM_ (glDetachShader program) (currentIDs \\ newIDs) -Edward Kmett

1 0

ANN: Haskell OpenGL package updates
by Jason Dagit 28 Oct '11

28 Oct '11

Several months ago I announced my intent to take over maintainership of the Haskell OpenGL bindings and associated packages. Today I have pushed new minor revisions to hackage. I have updated the following packages: * OpenGL * OpenGLRaw * GLURaw * GLUT The change log is very minor for each of these. For my first release as the new maintainer I opted to be very conservative about changes. Consider this a bug fix release with updated metadata. Please report bugs to either the Haskell OpenGL mailing list or the appropriate issue tracker on the github page: http://www.haskell.org/mailman/listinfo/hopengl https://github.com/haskell-opengl I would like to give a big thank you to the following individuals: Sven Panne Lars Corbjin Dylan Simon Alexey Karakulov Balazs Komuves If you contributed to this release by giving advice, filing a bug report, sending a patch, or in some other way, and I've not listed your name then I apologize for the omission. Going forward I could use help with testing, development, and documentation so if you're interested in OpenGL and Haskell let me know and also keep your eyes out for calls for volunteers. Thank you! Jason

1 0

Re: [HOpenGL] GLU NURBS rendered wrongly
by Alexey Karakulov 18 Oct '11

18 Oct '11

Description: GLU NURBS are rendered wrongly with newer versions of OpenGL. E.g. when the 9-point rectangular representation for a circle is used, this picture is a result (instead of a proper circle): http://i.stack.imgur.com/waoRm.png There are other details at the http://stackoverflow.com/questions/7798662/glu-nurbs-rendered-wrongly Versions: The bug appears when OpenGL>=2.3 is used. With older versions the NURBS for circle is rendered correctly: $ ghc -package OpenGL-2.2.3.0 -package GLUT-2.1.2.1 --make Circle.hs && ./Circle Platforms tested: ArchLinux 64-bit, Gentoo (don't know architecture). The Circle.hs file which draws the NURBS circle is attached.

2 2

Fwd: Future of OpenGLRaw, OpenGL, GLUT, and GLUTRaw
by L Corbijn 02 Oct '11

02 Oct '11

Oops forgot to send it also to the list. Lars .... > OpenGL has these issues: > https://github.com/haskell-opengl/OpenGL/issues Most of the issues regarding regarding GL3.0 have been implemented though not yet merged, partially because I'm not yet confident that everything is there and for some parts I'm not yet happy about what I've written. ... > The issues fit into a few categories: > a) Support for specific versions of the OpenGL spec > b) Refinement of the types (better modeling of C while easy to use in Haskell) > c) Performance (MArray instances, if possible and fast floating > point conversions) > d) OpenGL doesn't expose everything that OpenGLRaw already supports/exposes > > Before Alexander disappeared he showed me that someone has started a > tool (available on github) for parsing the Khronos xml spec for > OpenGL. We could use that code to auto generate much of the code in > OpenGLRaw. I think that could be a fun and reasonable project for > someone. How do others feel about using that to address (a) and (b)? > Of course, some work would need to be done first to prototype how it > should look/work and then the automated conversion could be developed. I believe that something has been done by Sven in the past (see the files in the OpenGL repo under specs). I've been working on some things (from scratch) for about a month (though not very active, due to lack of time). There are some difficult points about generating the binding from the spec files. Their are some inconsistencies in the enum spec file (which Khronos hasn't fixed, and probably isn't gone fix soon), but they can be fixed by hand. A different problem is that information needed for creating a type safe haskell binding is missing. For example enumerations aren't grouped and 'ObjectName'-s aren't identified. As OpenGLRaw doesn't need that information it can be created from the files. I've created code that does that, though it's missing some essential things. For generating OpenGL marshalling there is some need for extra information before it can be generated. I'm currently experimenting with an xml format I've made. Though the code generator is still absent, I'm trying to make one that is sturdy enough to be able to handle the things OpenGL throws at it. One major question about any code generation is how it should affect the current implementation, should it replace, augment the current library or should it be only a tool for the developers speeding up the code process. My personal preference goes to augment and replace (in the future). A generator that can fully replace/rewrite the code could have some extra (partial) back-ends that could for example generate memory managed code or code that reduces needles GLfunction calls. > ... > > I'd like to focus my attention on (a) and (b) first. I also want to > make a bug fix release of all four packages that update the cabal > files and just do a minor version number bump. Any objects to that? > > ... Sounds good.

2 2