in reply to Inline::C *back* into Perl

Came up with a good idea while driving the car home this afternoon listening to ABB's Live At Fillmore East and some Joe Satriani. (Ah, driving, rain and long jam music...both great inspiration...)

There is no reason why I can't write a C graphics engine and interface the OpenGL program to any program (including Perl) over named-pipes, sockets, or equivalent. 

app  ---> commands over pipe  --> gfxEngine
     <---  events over pipe   <---
(where the app can be written in *any* language)

[download]
</code>

This system would be really cool as I would have a graphics engine that is 100% cross-language (if not cross-platform) -- in theory, it might even be able to write OpenGL programs in bash.

This seems better than the Inline approach (though Inline rocks) since I could pretty much develop a solution usable from any application, standarding on IPC protocols rather than language constructs. The performance tradeoff of using IPC rather than system calls should be neglible, and this would allow me to develop any number of utility functions in C for speed improvements.

Also, this seems like it might have a bit more community interest as well -- rather than just another way to talk to OpenGL.

Best of all, I'd have a cross-language graphics engine usuable immediately in all languages I ran across with...even future ones.

I'll still have to hammer out the protocols and so on, but this is definitely doable and I'm going to give it a shot.

Replies are listed 'Best First'.
Re: Re: Inline::C *back* into Perl
by flyingmoose (Priest) on Feb 15, 2004 at 22:17 UTC
    Alas, I'm still making this too hard. The engine could take command input as STDIN and give events as STDOUT, thus allowing me to avoid pipes altogether and use Expect.pm for the main driving Perl code.
[reply]
      You consider that making it easy?

      Here are a few issues to think through.

      1. Any decent GUI program needs to handle interrupts well. It was doing X, the user decides not to and interrupts it. The API that you are describing offers no good way to pass interrupts along.
      2. The system that you describe doesn't seem to have a lot of debugging hooks when things go wrong.
      3. A huge problem with Expect is that unusual, unexpected or unanticipated input causes programs to diverge. When the GUI and internal program diverge on what they think is being displayed, you can readily get into deadlocks.
      4. What you are describing sounds like a lot of overhead at all ends.
      If you want a text-based cross-language approach to GUI developlment, I would suggest using httpd instead. No, it is not perfect. But it does a good job of addressing most of the above problems and furthermore has the virtue of already being built.
[reply]

        Actually, yes, I consider this very easy. I'm not trying to brag, but this part isn't complicated as long as I can beat probable performance problems. There are design challenges, but they are not intractible.

        HTML

        The day you see 3D games and simulations written in HTML, is the day I award Tilly the Turing Award. Nah, man, you missed the whole point of why OpenGL was important :)

        Interrupts
        Are you familar with the GLUT main loop? Interrupts can easily be processed in "C" code and handed back to the consumer as commands over the pipe. This includes motion events, keyboard events, etc. Just because the API supported something when it was pure "C" doesn't mean it can't support this over an IPC boundary. We are just extending methods to work over such a boundary.
        Debugging hooks
        Well, OpenGL itself doesn't have a lot of debugging hooks either. Essentially, the most common bug is the well known "BlackScreenOfDeath", where your camera points off into space and there is nothing you can do to figure it out. I'm proposing a packet-level (essentially) system to interface to OpenGL over named pipes. That's all. Sending OpenGL commands out of order will be the problem of the caller, though debugging facilities are certaintly being coded in. Since both sides will have debug modes that echo all commands printed to the pipes to the console, I can see the exchange between the two sides fairly clearly.

        So, as alluded to earlier, I decided on the named pipe approach not Expect... Expect looks to be a decent module, but if I use two named pipes, I get greater portability across multiple languages. Performance is still a concern, but if I use display lists, I think I can get decent performance regardless of the calling language. I already have a very clean OO Perl interface which I am currently using to debug the named-pipe system and the event handlers. Parsing, since I am keeping the protocol clean, will be kept to a minimum.

        I have some rough documentation here, it's still not linked from the main page of my web site: Engine. My theory as to whether it would be possible to drive an OpenGL program from Bash is a little theoretical, I at least want to try it before claiming it is possible on my home page. I definitely will be able to code up some OpenGL support (sans-C-bindings) for many languages that normally cannot do 3D graphics.

        Anyhow, check out the link, I'll probably some more coded up later this week to where I can show some code -- if I'm not doing my taxes, that is :)

        again, doc link: here -- it's very rough. Be kind to it!

[reply]

In Section Seekers of Perl Wisdom