[HOpenGL] Hello HOpenGL

Thu May 19 23:45:44 CEST 2011

Hi,

Nice to hear that there is to be some 'native' support for matrices and that
the documentation is updated. Though I've some comments too.

Firstly, I would prefer the move to another namespace for the deprecated
functionality, not only because it will be supported/used for quite some
time. It is also useful to be able to make a gentle transistion to 'non
deprecated code'. I think the amount of work is quite doable as quite a few
of the modules are in essence deprecated in total, the opengl specs 3.1 and
after would make this work quite a bit easier as they exclude the deprecated
functions. I think there is also a version of the spec where the deprecated
functions are marked in the sideline.

Secondly, the way you're depicting the OpenGL-raw library seems to be as a
library to make the opengl functions easier to use. Though this seems to me
as what the current OpenGL library is doing, wrapping all the objects in
nice new/data types and changing the functions in order to make them more
usable. So what is in your proposal to be difference between the proposed
OpenGL-Raw-Nice and the current OpenGL. Because if it were minimal it would
be quite a reason to add a 'layer' around what is currently OpenGL.

For the dependency on OpenGL itself, might it be an idea that as in the
current package everything is exported and you can only use the functions
available on your machine? I don't know much about OpenGL extensions but
might there not be a way to specify that there are two 'equivalent'
functions, one in the higher OpenGL version and one in a extension. On
invoking trying to invoke such function it would pick the appropriate
option, and thus it would prevent making a hard deprecation on a specific
version of OpenGL.

Furthermore It might be an idea to make part of the OpenGL library
'generatable', that is that the source code is generated from some sort of
specification file. That would for example make creating those functions for
getting limits (e.g. max texture units) quite a bit easier. There is quite
somethings more I would like to change in the library to make it nicer (at
least in my opinion), but that would make this email too long, and you've
probably also quite a lot of ideas your self.

I'm currently busy with implementing some OpenGL 3.0 functionalities, some
are already done. But work i progressing slowly as I'm using quite some time
for school and other activities.

Lars

P.S. I think the framebuffer ticket (#7,
https://github.com/haskell-opengl/OpenGL/issues/7) on github should be
reopened as I can't find them in the source code.

On Thu, May 19, 2011 at 2:02 PM, Balazs Komuves <bkomuves at gmail.com> wrote:

>
>
> On Thu, May 19, 2011 at 1:32 PM, Jason Dagit <dagitj at gmail.com> wrote:
>
>>
>> On May 19, 2011 5:02 AM, "Balazs Komuves" <bkomuves at gmail.com> wrote:
>> >
>> >
>> > Hi,
>> >
>> > I see you plan a complete rewrite, and removing the deprecated
>> functionality.
>> > In this case I suggest to make a new package instead of a new version of
>> the old
>> > OpenGL package, since it will actually be a very different package,
>> presumably
>> > with different APIs, etc (and I don't think Sven actually agreed to
>> replace it, since
>> > we cannot seem to reach him).
>>
>> I have to keep my reply short because I'm traveling, but two comments.
>>
>> Sven is no longer the maintainer, so we don't have to think too hard about
>> what he would do. We can make all the necessary decisions ourselves.
>>
>
> Well, they way this change happened is arguably not completely
> transparent...
>
> Anyway, there are objective reasons to make a different package: Apart from
> those I mentioned
> in my last email, we actually have hands-on experience what happens when a
> big rewrite
> happens the way you suggest, namely the parsec package, which still causes
> serious pains
> years later. We have parsec v2.x, parsec v3.x, parsec1, parsec2 and parsec3
> on Hackage;
> that's five versions in four packages with different maintainers, all
> because of one wrong decision.
> And arguably parsec2 vs. parsec3 is a much smaller change than what you
> plan.
>
> Furthermore, let's suppose the completely realistic situation one would
> like to use both the
> old and the new versions of the OpenGL package. This is next-to-impossible
> when it is the
> same package (and painful in any case), since other libraries you want to
> use but depend
> on OpenGL have to be recompiled each time. I again have hands-on experience
> with this,
> as I maintain a private branch the (very) old (before OpenGLRaw) OpenGL
> binding since I use
> frame buffer objects and other functionality not in the official package.
> Arguably, this is an
> issue of Cabal, but I have no high hopes for Cabal to solve this in the
> near future, and anyway,
> we should make life more painful just because.
>
> I believe each of these reasons is enough *in alone* to motivate a separate
> package, and
> together they form a very strong argument; and I hope you take this into
> account in a
> rational manner, notwithstanding what PVP allows or not. Face it, you plan
> to make a
> completely new package. It doesn't make sense to sell it as a new version
> of a different
> package.
>
> Whether we should rename it later to "OpenGL" and rename the old one to
> "OpenGL-old"
> or something like that is a separate question which can be dealt with when
> it becomes a problem.
>
> Balazs
>
>
>> By following the hackage package version policy, we should be free to make
>> major modifications to the existing API. If the gsoc work becomes the new
>> version the opengl library, then it will be version 3.x or later. You should
>> be able to author your package dependencies accordingly. We should be sure
>> to release any bug fixes that we can for the current version as we find
>> them.
>>
>> Basically, lets free ourselves to make changes, and them figure out how to
>> do so in a polite way.
>>
>> That is my opinion anyway :)
>>
>> Your feedback is welcome of course.
>>
>> >
>> > Furthermore, "deprecated" (2.0) functionality will be most probably
>> supported indefinitely
>> > in the future. At least NVidia (~half of the market) stated that they
>> will fully support it; and
>> > there is a HUGE amount of existing software out there depending on the
>> deprecated OpenGL
>> > functionality, which makes it economically irrational not to support it.
>> >
>> > Another reason is that only new hardware supports OpenGL 3.0. For
>> example I own
>> > two computers, a laptop and a desktop, and neither hardware support
>> OpenGL 3.0
>> > (it is actually not possible to buy a video card compatible with my
>> motherboard which
>> > supports 3.0...)
>> >
>> > Lastly, for a new user and also for quick hacks, the glBegin/glEnd route
>> is much easier.
>> >
>> > Apart from this, since I care a lot about Haskell OpenGL support, I
>> volunteer to
>> > review your work (read: give you my subjective but detailed opinion and
>> suggestions).
>> > You can reach me at this email address if you are interested in
>> discussing stuff.
>> >
>> > Balazs
>> >
>> > ps. I have a low dimensional linear algebra library which should have
>> all the functionality
>> > (and some more) needed to do graphics with OpenGL even in the
>> post-3.0-era:
>> >
>> > http://hackage.haskell.org/package/vect
>> > http://hackage.haskell.org/package/vect-opengl
>> > http://code.haskell.org/~bkomuves/projects/vect/
>> > (the development branch has some quaternions, too)
>> >
>> > I'm open to suggestions regarding the organization and API of this
>> library.
>> >
>> >
>> > 2011/5/19 Alexander Göransson <alexander.goransson at gmail.com>
>> >>
>> >> Hi!
>> >>
>> >> I'm the person who will be working on the libraries this summer. I've
>> been very busy with school lately (and still am), but I've written a blog
>> post with some thoughts on the project:
>> >> http://unsafeperformpastorn.blogspot.com/
>> >>
>> >> I will keep posting stuff there, on a weekly basis, throughout the
>> summer.
>> >>
>> >>  // Alexander
>> >>
>> >> _______________________________________________
>> >> HOpenGL mailing list
>> >> HOpenGL at haskell.org
>> >> http://www.haskell.org/mailman/listinfo/hopengl
>> >>
>> >
>> >
>> > _______________________________________________
>> > HOpenGL mailing list
>> > HOpenGL at haskell.org
>> > http://www.haskell.org/mailman/listinfo/hopengl
>> >
>>
>
>
> _______________________________________________
> HOpenGL mailing list
> HOpenGL at haskell.org
> http://www.haskell.org/mailman/listinfo/hopengl
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/hopengl/attachments/20110519/37c632eb/attachment-0001.htm>