Re: eXene and openGL

brian <briand-/[email protected]>
Newsgroups gmane.comp.lang.sml.smlnj
Message-ID <[email protected]>
On Jan 3, 2007, at 7:06 AM, John Reppy wrote:

> EXene is now being supported and developed by Ally Stoughton and his
> students,
> so they may be able to help you get the examples working.
>

Expect more questions to the list about getting examples working.  :-)

> I'm not particularly optimistic about supporting OpenGL in EXene.
> While it would
> be possible to implement the GLX wire protocol [Historical note: when
> I was actively
> working on eXene in the 90's, the protocol was not documented, but
> SGI eventually
> released it] in eXene, there are significant performance
> disadvantages to using
> that protocol.  For real-time rendering, you want a DRI-style
> implementation, but
> I don't know how to support such an approach in eXene.
>

I'm not really clear on the X/glX/GL relationship especially once you  
throw in DRI, which is why I needed an opinion from someone more  
knowledgeable.

> For a while, I've thought that the low-level parts of eXene ought to
> be rewritten
> to sit on top of a C shim (XCB is an obvious choice).  Doing so
> should make it easier
> to connect to more modern X extensions, such as the render extension
> and GLX.
>

XCB looks like a great idea.  It would certainly simplify the FFI  
portion of things, and would probably be more robust.  I'll look into  
it.  Worst-case, there is no reason the eXene X interface couldn't  
simply be replaced directly with low-level Xlib calls through nlffi.

Here's what prompted the question.  I'm using Vesa's excellent demo  
of X/glx/openGL using nlffi.  I started to look at glut, and I think  
that I even posted a question about callbacks some time ago.  So no  
callbacks, no glut (well maybe, see below).  However to make using  
the openGL interface useful there really needs to be an event  
handling mechanism.  Well it turns out that's really a very large  
part of the whole package isn't it ?  Once you have robust even  
handling adding the drawing functionality really isn't much of a  
problem.  Whenever I'm writing X/graphics sorts of things, the  
graphics are the least of my worries, it's all that window expose/ 
mouse button stuff that drives me nuts.

Looking at the openglut implementation, I don't see the code as being  
particularly difficult to write.  So my first thought was basically  
to implement _portions_ of openglut in SML, i.e. I wasn't about to  
start implementing all of the widget drawing/handling.  Looking at  
all of the UI interface in GLUT I started thinking that this looked  
like a job for eXene.

So as I started to go down that path I realized it may more sense to  
maybe create an eXene/GLUT-like wrapper and take advantage of the  
eXene interface model which I really like, at least in theory :-)
Really I think it even makes sense to migrate the graphics so that it  
is using openGL only even for just 2D stuff.  Basically X would just  
be there for device, i.e. interface, handling.

> An alternative approach is to build a GUI library on top of GLUT (or
> SDL).  I've been
> working on this project using mlton, since SML/NJ doesn't have
> callback support, but
> I'm hoping that we'll get the necessary hooks in SML/NJ soon.
>
Yes - it has also occurred to me to use SDL as the underlying  
graphics library.  That has numerous advantages, such as multimedia  
support.  As you said the lack of callback is a bit of a stickler.   
Personally I think supporting something like SDL is much more useful  
than GLUT.

Of course the whole point of something like exene is to get out of  
the callback business and make UI writing more civilized.

However it occurs to me that with some sort of C shim and appropriate  
use of pipes/fifos/etc...  you could actually build callbacks in to  
use with something like SDL.  It would surely be ugly.  You'd have to  
build the callback in C, install it, and then the callback could talk  
on a pipe/fifo/whatever of some sort to let it's SML counterpart know  
when it was time to get something done.  Ugly ? Yes.  Would it  
work ?  I certainly think so.

So summary-wise.

eXene to openGL would be nice.
to do that requires a "low level" interface to X/XCB/SDL or some  
other interface

I'm going to take another look at SDL - i did that I while back but  
can't remember what I found.  And XCB looks like a great possiblity.

Thanks for your thoughts.

Brian



> 	- John
>
> On Jan 3, 2007, at 6:40 AM, brian wrote:
>
>> So as I slog through X code to make openGL useful it occurs to me
>> that using eXene with openGL tied in would be a really nice way to
>> go. eXene3D :-)
>>
>> There are a couple of problems:
>>
>> 1 I still can't get eXene examples to work.
>>
>> 2 Is there a gotcha in terms of the X interface which eXene uses and
>> openGL ? eXene uses the socket level interface and I'm not sure what
>> that implies for use with openGL.  Wthout thinking too hard, I don't
>> think it implies anything.  I simply invoke glX calls using the
>> display, window, etc.. I get from the eXene interface.
>>
>> Solving 1 is just a matter of time and persistence on my part.
>>
>> Understanding 2 is much more important.  Since I'll probably have to
>> do considerable work for 1, I don't want to get to the end of the
>> path and find out that there will be some problem connecting eXene/
>> openGL.
>>
>> At first I thought that the use of threading might be a problem, but
>> since they are "user level" threads, doesn't seem like that should be
>> an issue.
>>
>> Any opinions ?
>>
>>
>> Brian
>>
>>
>> --------------------------------------------------------------------- 
>> -
>> ---
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Smlnj-list mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/smlnj-list
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Smlnj-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/smlnj-list


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.