Re: opengl and gephex
Georg Seidel <[email protected]> Sun, 19 Jun 2005 15:14:02 +0200
| Newsgroups | gmane.comp.video.gephex.devel |
|---|---|
| Message-ID | <[email protected]> |
>>There are some detailed mails from Georg around that sum up important >>design discussions. I consider most of them quite official. :) > > > thanks for the tip. for future reference, i've added some archive links which > seemed relevant. probably have missed a bunch, though. cool, thanks for doing so. > keywords: gephex-0.5 design / gephex-0.5 architecture > > http://lists.gephex.org/pipermail/gephex-devel/2004-January/000010.html well, these were first thoughts, in the meantime we decided to use scons [1] as our build system. So far it seems a good choice. > http://lists.gephex.org/pipermail/gephex-devel/2004-February/000040.html This was fun to play with and implement, but as it turned out we threw away all the interface definition language in favour of a pure C++ interface (see message 235). However, it is not decided yet whether we will have a simple plugin compiler (pluc) which creates wrapper code and initial code skeletons from unit and type spec files. The current pluc is broken, but would not need too much work to be reactivated. So maybe the following post is still relevant in parts: http://article.gmane.org/gmane.comp.video.gephex.devel/49 > http://lists.gephex.org/pipermail/gephex-devel/2004-May/000070.html We sticked with scheme, plt scheme to be more specific [2]. > http://lists.gephex.org/pipermail/gephex-devel/2004-August/000108.html This still reflects current design, and is simplified by having C++ link superclass which can implement timestamp handling. > http://lists.gephex.org/pipermail/gephex-devel/2004-November/000216.html The followup is also relevant: http://lists.gephex.org/pipermail/gephex-devel/2004-November/000217.html Together both emails introduce the "lazy-if" mechanism in gephex-0.5, which can be used to implement the more specific optimizations of gephex-0.4 (in-place processing, strong-dependencies). > http://lists.gephex.org/pipermail/gephex-devel/2004-November/000235.html > http://lists.gephex.org/pipermail/gephex-devel/2004-November/000247.html In this email martin talks about a more uniform serialisation for links (although this is now obsoleted by the use of OSC?) http://lists.gephex.org/pipermail/gephex-devel/2004-November/000269.html > http://lists.gephex.org/pipermail/gephex-devel/2005-February/000415.html > http://lists.gephex.org/pipermail/gephex-devel/2005-March/000505.html > http://lists.gephex.org/pipermail/gephex-devel/2005-April/000611.html There is (at least) one more new thing which has been posted to gephex-devel: a change in the format units and link types use to report meta-data(like number and type of ports, description, ...): http://lists.gephex.org/pipermail/gephex-devel/2005-April/000612.html For the interface see http://tinyurl.com/d2swl (Current version in arch might be newer). Here is an email of martin regarding video types in 0.5: http://article.gmane.org/gmane.comp.video.gephex.devel/697 (btw, gmane offers a more comfortable archive because it does not cut threads into months...) Here is one more little design piece regarding the C++ link and unit interfaces, which talks about enhancing the gephex-0.5 type system to support subtyping: http://article.gmane.org/gmane.comp.video.gephex.devel/279 This is about a new GUI concept (philipp: the screenshot is broken, can you upload it again?): http://article.gmane.org/gmane.comp.video.gephex.devel/152 One more try on image data types: http://article.gmane.org/gmane.comp.video.gephex.devel/116 There is also another unsolved issue: the format used to communicate video data between video servers, gephex and video outputs (which will be different processes in gephex-0.5). An old proposal: http://article.gmane.org/gmane.comp.video.gephex.devel/38 Sorry for the somewhat confusing email, I just went through the ml archive backwards in time and included everything I assumed relevant. It would be nice to update the features site and put this list of postings there (grouped by issue) to make it easier for people to track current 0.5 design and progress. Regards, Georg [1] http://www.scons.org/ [2] http://www.plt-scheme.org/