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">&lt;<a href=3D"mailto:[email protected]" target=3D"_b=
lank">[email protected]</a>&gt;</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&#39;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">&lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</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&#39;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&#39;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&#39;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 &quot;ozelis&quot; 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==--