unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Guile OpenGL bindings
@ 2013-02-01 12:16 Andy Wingo
  2013-02-01 13:02 ` Javier Sancho
  2013-02-02  7:10 ` Aleix Conchillo Flaqué
  0 siblings, 2 replies; 7+ messages in thread
From: Andy Wingo @ 2013-02-01 12:16 UTC (permalink / raw)
  To: Javier Sancho; +Cc: guile-user

Hi Javier,

Have you had time to think about GL bindings for Guile?  I had been
meaning to do something about it for a long time, and finally got around
to a first hack last week.  Daniel and I are working in this repo:

  https://gitorious.org/guile-figl

The idea is to use the FFI to make a low-level, complete interface, and
then as needed to make higher-level more Scheme-like wrappers.  I also
really wanted documentation, so I munged the upstream docbook into
texinfo and wrote that out into docstrings and .texi files.  The binding
isn't working yet, but maybe soon.  I'd like to avoid C if I can.

Daniel has an FFI-based GLUT wrapper that he is merging in that repo as
well.  Are you interested in joining efforts?  I can add you to the
gitorious project if you like.

Cheers,

Andy
-- 
http://wingolog.org/



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guile OpenGL bindings
  2013-02-01 12:16 Guile OpenGL bindings Andy Wingo
@ 2013-02-01 13:02 ` Javier Sancho
  2013-02-01 13:29   ` Daniel Hartwig
  2013-02-02  7:10 ` Aleix Conchillo Flaqué
  1 sibling, 1 reply; 7+ messages in thread
From: Javier Sancho @ 2013-02-01 13:02 UTC (permalink / raw)
  To: Andy Wingo; +Cc: guile-user

Andy Wingo wrote:
> Hi Javier,

Hi.

> Have you had time to think about GL bindings for Guile?

Not much. I've been a little busy with my first child :-)
Just this week I'm back to thinking about it.

> The idea is to use the FFI to make a low-level, complete interface, and
> then as needed to make higher-level more Scheme-like wrappers.  I also
> really wanted documentation, so I munged the upstream docbook into
> texinfo and wrote that out into docstrings and .texi files.  The binding
> isn't working yet, but maybe soon.  I'd like to avoid C if I can.

Aleix Conchillo is also working with OpenGL and encountered a problem
with glutInit and char**. You can see it at
http://lists.gnu.org/archive/html/guile-devel/2012-07/msg00074.html
Someone mentioned performance issues when using FFI, too.

> Daniel has an FFI-based GLUT wrapper that he is merging in that repo as
> well.  Are you interested in joining efforts?  I can add you to the
> gitorious project if you like.

Well, I can't promise anything, but yes, I'm very interested in this project.

This weekend I'll try to hack a little.

Cheers.

--
Javier Sancho Fernández - http://www.jsancho.org/
Associate Member of the Free Software Foundation - http://www.fsf.org/
Contra el DRM - http://www.defectivebydesign.org/what_is_drm



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guile OpenGL bindings
  2013-02-01 13:02 ` Javier Sancho
@ 2013-02-01 13:29   ` Daniel Hartwig
  2013-02-01 15:10     ` Mark H Weaver
  2013-02-01 20:56     ` vimml
  0 siblings, 2 replies; 7+ messages in thread
From: Daniel Hartwig @ 2013-02-01 13:29 UTC (permalink / raw)
  To: Javier Sancho, guile-user

On 1 February 2013 21:02, Javier Sancho <jsf@jsancho.org> wrote:
> Aleix Conchillo is also working with OpenGL and encountered a problem
> with glutInit and char**. You can see it at
> http://lists.gnu.org/archive/html/guile-devel/2012-07/msg00074.html

Mark's suggestion is spot on, even points out one issue with memory
that I have missed.

It seems that Aleix later moved to a C binding, though I am confident
this can be avoided (c.f. cl-opengl).  Anyway, this function is
working fine in the bindings I have prepared (sans the memory issue).

GLUT bindings cover all functions, but missing constants.  These to
follow shortly.

Andy's work on the sxml side has the GL bindings *almost* running as
well.  I'll look to finish those in the next few days if someone
doesn't beat me to it.

> Someone mentioned performance issues when using FFI, too.

For modern GL programming without glBegin/End, Vertex/Color/Normal,
etc. the performance impact of FFI should be negligable.  There are
few GL calls compared to the volume of data that is passed.

The real critical part will be how the user manipulates their vertex
data, if this is done frequently on the scheme side.  Mapping (typed)
bytevectors, or srfi-4 to gl arrays will help with that, and avoiding
the implicit type conversions that some other bindings perform.

> Well, I can't promise anything, but yes, I'm very interested in this project.

Nice.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guile OpenGL bindings
  2013-02-01 13:29   ` Daniel Hartwig
@ 2013-02-01 15:10     ` Mark H Weaver
  2013-02-01 20:56     ` vimml
  1 sibling, 0 replies; 7+ messages in thread
From: Mark H Weaver @ 2013-02-01 15:10 UTC (permalink / raw)
  To: Daniel Hartwig; +Cc: guile-user

Javier Sancho <jsf@jsancho.org> writes:
> Someone mentioned performance issues when using FFI, too.

That was me, and I regret emphasizing that.  In a couple of years, when
Guile has native compilation, it is likely that the FFI will be as fast
as C wrappers, maybe even a bit faster.

Anyway, as Knuth wrote, "We should forget about small efficiencies, say
about 97% of the time: premature optimization is the root of all evil",
and he was absolutely right.  Countless projects have been ruined by
premature optimization.

It's far more important to write the cleanest, simplest code that will
get the job done.  Only after determining the hotspots (by profiling)
should you optimize those bits.

Plus, as Daniel Hartwig <mandyke@gmail.com> wrote:

> For modern GL programming without glBegin/End, Vertex/Color/Normal,
> etc. the performance impact of FFI should be negligable.  There are
> few GL calls compared to the volume of data that is passed.
>
> The real critical part will be how the user manipulates their vertex
> data, if this is done frequently on the scheme side.  Mapping (typed)
> bytevectors, or srfi-4 to gl arrays will help with that, and avoiding
> the implicit type conversions that some other bindings perform.

   Regards,
     Mark



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guile OpenGL bindings
  2013-02-01 13:29   ` Daniel Hartwig
  2013-02-01 15:10     ` Mark H Weaver
@ 2013-02-01 20:56     ` vimml
  2013-02-01 23:54       ` Daniel Hartwig
  1 sibling, 1 reply; 7+ messages in thread
From: vimml @ 2013-02-01 20:56 UTC (permalink / raw)
  To: guile-user

Hej,

this all sounds really cool :-)

I hacked a little bit of code to generate C bindings for what is specified in
the glcorearb.h file. I also wrote a small script to extract the gl constants
and define them as scheme variables.
This is all *really* hacky stuff, but if somebody wants to have a lookt at it...

On 21:29 Fri 01 Feb     , Daniel Hartwig wrote:
> The real critical part will be how the user manipulates their vertex
> data, if this is done frequently on the scheme side.  Mapping (typed)
> bytevectors, or srfi-4 to gl arrays will help with that, and avoiding
> the implicit type conversions that some other bindings perform.
I did use r6rs bytevectors (bytevector-ieeee-single-native-ref...) to plow
through my data and it was rather sluggish. It's quite possible that I did
someting terribly wrong, but I went back to do the crunching in C...

On 13:16 Fri 01 Feb     , Andy Wingo wrote:
>   https://gitorious.org/guile-figl
Looking forward to have a look at your code :-)

Happy Hacking,
	Kai :)



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guile OpenGL bindings
  2013-02-01 20:56     ` vimml
@ 2013-02-01 23:54       ` Daniel Hartwig
  0 siblings, 0 replies; 7+ messages in thread
From: Daniel Hartwig @ 2013-02-01 23:54 UTC (permalink / raw)
  To: guile-user

On 2 February 2013 04:56,  <vimml@selgrad.org> wrote:
> I hacked a little bit of code to generate C bindings for what is specified in
> the glcorearb.h file. I also wrote a small script to extract the gl constants
> and define them as scheme variables.
> This is all *really* hacky stuff, but if somebody wants to have a lookt at it...

For reference, the canonical source of that information is in a set of
spec files <http://www.opengl.org/registry/#specfiles>.



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Guile OpenGL bindings
  2013-02-01 12:16 Guile OpenGL bindings Andy Wingo
  2013-02-01 13:02 ` Javier Sancho
@ 2013-02-02  7:10 ` Aleix Conchillo Flaqué
  1 sibling, 0 replies; 7+ messages in thread
From: Aleix Conchillo Flaqué @ 2013-02-02  7:10 UTC (permalink / raw)
  To: Andy Wingo; +Cc: guile-user

On Fri, Feb 1, 2013 at 4:16 AM, Andy Wingo <wingo@pobox.com> wrote:
> Hi Javier,
>
> Have you had time to think about GL bindings for Guile?  I had been
> meaning to do something about it for a long time, and finally got around
> to a first hack last week.  Daniel and I are working in this repo:
>
>   https://gitorious.org/guile-figl
>
[snip]

These are really good news! Thanks Daniel and Andy!

I stopped working on guile-gl a while ago. I moved from FFI to C
bindings after some messages on the mailing list as Javier pointed.
But after this email I will definitely not retake the work. It doesn't
make a lot of sense to duplicate efforts, specially if the people that
take the effort have more experience.

So, great news!

Aleix



^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2013-02-02  7:10 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-01 12:16 Guile OpenGL bindings Andy Wingo
2013-02-01 13:02 ` Javier Sancho
2013-02-01 13:29   ` Daniel Hartwig
2013-02-01 15:10     ` Mark H Weaver
2013-02-01 20:56     ` vimml
2013-02-01 23:54       ` Daniel Hartwig
2013-02-02  7:10 ` Aleix Conchillo Flaqué

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).