GEM-dev May 2003

gem-dev@lists.iem.at

8 participants
4 discussions

Re: GEM stability
by IOhannes zmoelnig 23 Jun '03

23 Jun '03

Daniel Heckenberg wrote: > Hi all, > > GEM isn't very stable on Windows at the moment - I'm noticing a number of oh, maybe i should reboot into "dos" more often ;-) > I'm wondering whether other platforms are suffering any of these problems or i have never noticed any problems under linux. although i had had problems under mac, when the cpu usage went very high after some time (without doing much) > whether anyone is actively tracking down similar/related problems? sorry (for you): no, at least not me > PS There was talk of a major point release for GEM some time soon. When > will that be and what steps are required to get there? actually this is the question i tried to ask. i have no date in mind (as we are no software-company, we are not that bound to release-dates), but the sooner, the better. i tried to outline what has to be done: 1. stability (fits to this thread...) on all platforms 2. feature-freeze: i don't think i will have the dv-in working soon under linux (and i need some help with the class-concept for addressing two different driver-architectures) furthermore, i don't think that the new release will feature any other outputs ("gemwin"s like dv-out). this is fine for a next release. i think, basically that's it. mfg.asd.r IOhannes

9 13

pix_rds added
by tigital 17 May '03

17 May '03

hiya, ...just added pix_rds, which is a port of the effectTV random dot stereogram code...which brings me to a question: how should we best deal with "utility" type functions? I've been porting from several different effects packages, and some of them use similar code for colorspace changes, or matrix math, or whatever...I noticed a problem with namespace clashes when I loaded GEM, PDP, PDP2GEM, and PIDIP, because PIDIP and GEM have similar ports of effects from effectTV... ...seems to me the only way to do this would be to encapsulate all functions within the pix_"object" class, but this leads to a lot of redundancy (which really isn't bad, I guess)...any ideas? l8r, jamie

1 0

Re: [GEM] update && Re: [PD-dev] [GEM] update
by IOhannes zmoelnig 16 May '03

16 May '03

gÃ¼nter wrote: > I have taken a look at the new film classes, and I have to say that I > am not fully convinced by the design. > If every platform has to go through this, it might be good to give > it a little bit of thought. > The cleanest solution would be to have the decoder (film) classes > register themselves with the system if they are linked in, and not > call their constructors from the pix_filmNEW. > (This can be done for example by instantiating a global class in each > filmXXX implementation, where the constructor registers itself) > This would save the #ifdefs that are currently in the filmXXX > classes. this is true. however, i have never before done such thing and so i have not "wasted" too much thought on it. mfg.asd.r IOhannes

1 0

version numbering
by IOhannes zmoelnig 16 May '03

16 May '03

just a tiny little thread about the version of the new release (not very important) gem-0.88 would be the "normal" version number however, as chris has pointed out, there were a lot changes and maybe 0.88 would be to small a change from 0.87 however, since 0.88 (or 0.90) isn't that far from 0.99 any more, which is (normally) the pre-version of 1.0, i would suggest just an extension to 3 digits as 0.888 1.) this would give us some room 2.) the 3 digits are symbolic for the 3 major platforms, Gem is running on. 3.) it is just a thought mfg.as.dr IOhannes

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

GEM-dev May 2003