Re: Important changes to OpenGLRaw
Jason Dagit <[email protected]> Fri, 26 Oct 2012 13:11:52 -0700
| Newsgroups | gmane.comp.lang.haskell.hopengl |
|---|---|
| Message-ID | <CAJ-DSyx1a_EET4WBaBifcm5kmAVKXK8-Ff86BObuAjy68j_8+g@mail.gmail.com> |
--===============7963359794678273157== Content-Type: multipart/alternative; boundary=bcaec54ee1f8432b9f04ccfbee37 --bcaec54ee1f8432b9f04ccfbee37 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 26, 2012 at 1:02 PM, Dan Haraj <[email protected]> wrote: > I like this change. The issues you brought up have been relevant to me. A > long while ago I had a severe performance bug because of coercions between > GL float types and C float types that went away when I replaced them with > unsafeCoercions. > Great. > > Glancing at the source for Raw, does this mean that include/CTypes.h is no > longer required? > Good point. The easiest thing is to try removing it and see if anything requires it. We're using travis-ci to build all the OpenGL packages now which helps with this sort of testing. Thanks, Jason > > On Fri, Oct 26, 2012 at 1:25 AM, Jason Dagit <[email protected]> wrote: > >> Hello, >> >> At some point in the past, OpenGLRaw was converted to use newtype >> wrappers for the GLfoo types, such as GLenum. I think this makes a certain >> amount of sense. It's certainly makes type safety easier. There have also >> been significant downsides to this: >> >> * The CPP macros to make these definitions are borrowed verbatim from >> GHC sources and required updates with new GHC releases in order to stay >> compatible. Although, it hasn't been a problem yet, it's conceivable this >> will conflict with supporting different versions of GHC at some point. >> * Optimization rules have to be written against these newtypes and >> forgetting them can lead to significant performance degradation or extra >> verbosity for people using the bindings. >> * You have to reach pretty deep into GHC to make it possible for the >> newtypes to work in the unboxed vectors provided by the vector package. >> This is again, another missed opportunity for high performance code. >> >> If you look at the current HEAD of the master branch for the OpenGLRaw >> code on github: https://github.com/haskell-opengl/OpenGLRaw >> >> You will see some changes including: >> * All of the newtypes mentioned above have been changed to type aliases >> * Version bumped to 1.3.x >> * TypesInternal module has gone away >> >> Thanks for these changes goes to Trevor Elliott. >> >> If you think this move to type aliases is an error, please let me know >> (on list or personal email is fine). I'd like to do a push to Hackage >> sometime soon, but I want to give people a chance to comment first. By this >> time next week, I would like to post a new release, unless someone has an >> objection. >> >> There is another wonderful set of changes you will find in HEAD. I >> received patches from "ozelis" to add support for the NVidia path rendering >> extension. Very cool! >> >> Thanks! >> Jason >> >> _______________________________________________ >> HOpenGL mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/hopengl >> >> > > _______________________________________________ > HOpenGL mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/hopengl > > --bcaec54ee1f8432b9f04ccfbee37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Fri, Oct 26, 2012 at 1:02 PM, Dan Har= aj <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a>></span> wrote:<br><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex"> <div>I like this change. The issues you brought up have been relevant to me= . A long while ago I had a severe performance bug because of coercions betw= een GL float types and C float types that went away when I replaced them wi= th unsafeCoercions.<br> </div></blockquote><div><br></div><div>Great.</div><div>=A0</div><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"><div> </div><div><br></div><div>Glancing at the source for Raw, does this mean th= at include/CTypes.h is no longer required?</div></blockquote><div><br></div= ><div>Good point. The easiest thing is to try removing it and see if anythi= ng requires it. We're using travis-ci to build all the OpenGL packages = now which helps with this sort of testing.</div> <div><br></div><div>Thanks,</div><div>Jason</div><div><br></div><div>=A0</d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"><br><div class=3D"gmail_quote"><div><div = class=3D"h5"> On Fri, Oct 26, 2012 at 1:25 AM, Jason Dagit <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>></sp= an> wrote:<br> </div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">Hello,<di= v><br></div><div>At some point in the past, OpenGLRaw was converted to use = newtype wrappers for the GLfoo types, such as GLenum. I think this makes a = certain amount of sense. It's certainly makes type safety easier. =A0Th= ere have also been significant downsides to this:</div> <div><br></div><div>=A0 * The CPP macros to make these definitions are borr= owed verbatim from GHC sources and required updates with new GHC releases i= n order to stay compatible. Although, it hasn't been a problem yet, it&= #39;s conceivable this will conflict with supporting different versions of = GHC at some point.</div> <div>=A0 * Optimization rules have to be written against these newtypes and= forgetting them can lead to significant performance=A0degradation=A0or ext= ra verbosity for people using the bindings.</div><div>=A0 * You have to rea= ch pretty deep into GHC to make it possible for the newtypes to work in the= unboxed vectors provided by the vector package. This is again, another mis= sed opportunity for high performance code.</div> <div><br></div><div>If you look at the current HEAD of the master branch fo= r the OpenGLRaw code on github:=A0<a href=3D"https://github.com/haskell-ope= ngl/OpenGLRaw" target=3D"_blank">https://github.com/haskell-opengl/OpenGLRa= w</a></div> <div><br> </div><div>You will see some changes including:</div><div>=A0 * All of the = newtypes mentioned above have been changed to type aliases</div><div>=A0 * = Version bumped to 1.3.x</div><div>=A0 * TypesInternal module has gone away<= /div> <div><br></div><div>Thanks for these changes goes to Trevor Elliott.</div><= div><br></div><div>If you think this move to type aliases is an error, plea= se let me know (on list or personal email is fine).=A0I'd like to do a = push to Hackage sometime soon, but I want to give people a chance to commen= t first. By this time next week, I would like to post a new release, unless= someone has an objection.</div> <div><br></div><div>There is another wonderful set of changes you will find= in HEAD. I received patches from "ozelis" to add support for the= NVidia path rendering extension. Very cool!</div><div><br></div><div> Thanks!</div><span><font color=3D"#888888"> <div>Jason</div> </font></span><br></div></div>_____________________________________________= __<br> HOpenGL mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= g</a><br> <a href=3D"http://www.haskell.org/mailman/listinfo/hopengl" target=3D"_blan= k">http://www.haskell.org/mailman/listinfo/hopengl</a><br> <br></blockquote></div><br> <br>_______________________________________________<br> HOpenGL mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"http://www.haskell.org/mailman/listinfo/hopengl" target=3D"_blan= k">http://www.haskell.org/mailman/listinfo/hopengl</a><br> <br></blockquote></div><br> --bcaec54ee1f8432b9f04ccfbee37-- --===============7963359794678273157== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ HOpenGL mailing list [email protected] http://www.haskell.org/mailman/listinfo/hopengl --===============7963359794678273157==--