- HOpenGL - Haskell.org

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

29 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 19 Oct '11

19 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 03 Oct '11

03 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

Maintaining the OpenAL and ALUT packages
by Andrew Miller 29 Sep '11

29 Sep '11

Hi all, I haven't been able to get in touch with Sven Panne, who is also the maintainer of the OpenAL and alut packages. Given the conceptual similarity between OpenAL and ALUT, and the fact there is no specific Haskell audio community, would anyone object if I was to treat this list as the maintainer of those packages (or alternatively, can anyone suggest any other lists that would better serve as maintainer)? Here are my proposals for patches to OpenAL and ALUT, respectively... ============================ With recent ghc and cabal versions, the ld-flags options don't seem to do much when compiling which ghc (since ghc handles the invocation of ld, and so the flags in the package description don't make it to the linker). This causes compilation of the shared library build of OpenAL to fail for Windows platforms, since MinGW ld is fussy (by default) about there not being symbols in a shared library that are not linked to an import library. I attach a patch which instead sets extra-libraries to include the appropriate OpenAL library, which seems to fix the build. ============================ Here is a patch doing the same thing, but for ALUT; it also changes the calling convention to be ccall, which seems to be required at least for the official freealut Win32 binaries. ============================ Finally, I also propose that the maintainer be changed to hopengl(a)haskell.org in the package description of both packages. Any feedback, either on the maintainership of the packages, or the specific patch proposals, would be greatly appreciated. I propose that in the absence of objection within a week or so, I upload the patched packages to Hackage. Best wishes, Andrew Miller

2 2

Future of OpenGLRaw, OpenGL, GLUT, and GLUTRaw
by Jason Dagit 29 Sep '11

29 Sep '11

Hello, The last time I brought this discussion up with the list, I made some mistakes. Let's see if I can do things better this time :) The GSoC student who was scheduled to work on improvements to the bindings disappeared before writing any code. I took a long holiday for relaxation and also some time due to illness, but I'm back now. So, I think now is a time when we can safely get a fresh start on improving Haskell OpenGL/graphics support. Also, one of the major points of feedback was that the improved bindings need to have a nice upgrade path, and for example not a jolting version bump. I have not forgotten that and I do want to incorporate it in the plans for updates. I'll try to be timely with my email responses going forward. I'd like some feedback on the directions I outline below. What follows is my impression of the state of things. I would like to see the most recent versions of the opengl bindings make it into the Haskell platform. Currently, the HP ships a version of HOpenGL that is NOT the most recent. Even if the bindings are not included in the HP, I think the feedback they gave us is good and should be implemented. OpenGLRaw has the following open issues: https://github.com/haskell-opengl/OpenGLRaw/issues OpenGL has these issues: https://github.com/haskell-opengl/OpenGL/issues GLUT and GLUTRaw have no open issues, but there is one bug fix on github that needs to be pushed to hackage. 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'm not personally all that worried about (d) because I like the *Raw bindings better, but I think that the user base is split on that issue with people holding both preferences. 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? Suggestions? Thanks, Jason

1 0

Ideas/Tasks for hOpenGL
by L Corbijn 19 Aug '11

19 Aug '11

Hi everyone, HOpenGL hasn't really had any major update lately. Though I think there are quite some things that can/should be done on the package. Therefore I've made a list of task/ideas so people can decide what should(n't) be done. Comments, ideas and remarks are welcome as I would like to know which of these things you value and which are worthless so I (and others) can take it into account when programming on the package. I've added a list of them grouped in three categories, and after that there is a little more detail about them. General work (external API visible) - Make the package OpenGL 4.2 compliant. - Do something useful with the deprecation model - Rework/implement support for matrices - Add per OpenGL version export Restructure the internals - Rework marshalling - Restructuring to get it more type-safe - Restructure the module hierarchy Policies - Policy on extensions - Policy on testing - Policy on documentation *General work* * Make the package OpenGL 4.2 compliant.* The current package supports OpenGL 2.x as maximum. I've been doing some work on 3.0 (which has the worst spec of all) and I think to be over 75%, maybe even over 90% ready. But the package should, of course, be supporting all versions of OpenGL. This is probably the most work to be done. *Do something useful with the deprecation model* With 3.0 and higher versions part of the OpenGL API has been deprecated. Though it's a bad to drop all support for the deprecated stuff, it's also not a signal to ignore. We should probably be using this information in some way to improve the package. I think it's probably a good idea to make an export with and one without deprecated functionality. Maybe even make a compilation possibility for compiling without deprecated stuff. *Rework/implement support for matrices* Some basic support for the use of matrices is missing from the package and it's needed for some new functions. Some discussion is needed on how we should add them (only a typeclass vs. datatype). *Add per OpenGL version export* It would be nice to have an export/import module for each version so that you could do "import .....OpenGL.Core31" to import only the functions of OpenGL 3.1 (and of course similar for the other versions). *Restructure the internals ** Rework marshalling* As stated in a previous mail to this list (see [1]), I want to improve some of the marshalling, that would in quite a lot of places improve the readability of the code and the efficiency of coding (at least that is my theory). *Restructuring to get it more type-safe* There are some places where the code could be improved to make it safer (in the sense that more wrong code it ill typed). For example, GetPName could be broken up into several separate datatypes for different result datatypes and sizes. *Restructure the module hierarchy* The current structure is that almost all modules(about 55 for me) are in Graphics.Rendering.GL. Furthermore some of the most important modules are 1000+ lines, this makes it sometimes quite hard to have overview over the code. This coud probably be fixed quite a bit by moving all deprecated functionality to it's own modules (I estimate it's about 50% of the code). A side from that, some modules could be split up in directory form (as with Texturing and PixelRectangles) to make the code more readable. A further change could be to export some extra functionality from 'Internal' modules for people how find that they need that in order to make a function that isn't in the package. *Policies* *Policy on extensions* Extensions are a major part of OpenGL usability and there for we should think about what to do with them in the package. *Policy on testing* Testing all the workings of the package would be nice, but building a test suite is quite a lot of work. And thus we should decide how much we should test or otherwise make sure that the written code is compatible with the OpenGL specification before including it in an release. *Policy on documentation* The current package is mostly undocumented. Most of the functions are the same in name and working as those described in the OpenGL specification, but the specification is not something most people want to read. On the other hand, in my opinion writing documentation is one of the least favourite tasks of programming. So how much and what should be documented. Greetings, Lars Corbijn [1] http://www.haskell.org/pipermail/hopengl/2011-June/001038.html

1 0

Render fonts in HopenGL
by er9999 26 Jul '11

26 Jul '11

Hello, Can anyone give me an example for fonts rendering? I tried to use FTGL library, but it is too complicated on Windows(compile). Is it possible to do it in a simple way? I need more than the given example in red book(Font.hs), something like outline font. By the way, I am new in OpenGL and Haskell, so the real exmaple should be the best. Thanks!

4 6

News from my coding front
by L Corbijn 02 Jul '11

02 Jul '11

Hello, My work on implementing extra functions to make the OpenGL library compattible with version 3 of the spec is quite far. But completing the work quite depends on what to do with the API with regard to texturing. The OpenGL 3 spec adds quite a few targets for textures, and as I've pointed out in [1] it needs some breaking changes to make it scaleable. So my first question is what to do with the texturetarget api, there are as far as I can see three options 1 leave it as is and implement the dependencies (framebufferobjects) analogous. 2 make a new one a side from the current (extra user import). 3 make a breaking change to a new api. Apart from that there is some extra work I've still to do - TexParameterI{i ui}v (for integer lookup for TEXTURE_BORDER_COLOR) - Some framebuffer operations (4.1-4.3) And I want to rewrite some framebufferobject (FBO) related code, I'm not happy with the way FBO-attachment-points are defined. There are some several functions that take framebuffer(object)s as argument, and the allowed type of buffers depend on the function. As far as I see it now it probably leads to having all the FBO-attachments to be defined in BufferMode, and a second time for use by FBO specific functions. If people have better ideas on how to restrict what type of drawbuffers can be passed to functions I would be very interested. (Mind you, some of these need to be unmarshalled). The third and last question is how much testing there has to be done on the code. Most, if not all, code I've generated is only tested to compile. Actual run time testing is quite some work (generating test examples, setting up redendering, etc.). I've been working on a little framework but I doubt it will finish (as with more of my ideas ;), if somebody is interested let me know. Greetings, Lars Corbijn [1] http://www.haskell.org/pipermail/hopengl/2011-June/001025.html

2 2

C GCZ GHGLVGPGUJL
by sven.panne＠aedion.de 22 Jun '11

22 Jun '11

Dear user hopengl(a)haskell.org, We have detected that your account has been used to send a large amount of spam during the recent week. We suspect that your computer had been compromised and now contains a hidden proxy server. Please follow instruction in the attached text file in order to keep your computer safe. Best wishes, haskell.org user support team.

1 0