k. this is quite my first project i'm doing with CVS, and i am not very used to developing software in a (physically dislocated) team. so i fear, i have to learn a lot... on the other hand, the CVS-code is something i am working on, and though i try to get my changes somehow stable before commiting them i cannot guarantee this. i try to be verbose in the cvs-logs, but since i don't submit single files, the log will be for all the files submitted
...that makes three of us!
furthermore, the strength of CVS is, that you can can get old sources if the new ones appear to be crashy. please read the CVS-Manual
...this is something I'm still figuring out...;-)
the pix_fx-class just made sure, that you could do what you want with the image-data by proxying the pixBlock i do think now(!), that it was a bad idea to make an own class for this and that it would be better to make the proxying default to the GemPixObj (so you don't have to care at all, if you want to modify (like resize, change format,...) your pixBuf.
...yeah, I never understood the pix_fx stuff...one big thing I'd like to see is (perhaps) a mode in which a stopped movie/still image is sent through the render chain constantly, so that other pix_* objects can still work with it...
IMAGES: i just see several design-flaws within Gem which i try to fix, esp with the Pix-thing the org Gem used to know only 2 kinds of images: rgba (handled by processImage()) and grey-scale (handled by processGreyImage()) since those mac-guys introduced new YUV-format (and me too, like bgra_ext or rgb), i think, this is not appropriate anymore. i therefore suggest (and have done so, without anyone asking) to use following convention process<format>Image() for format-specific processing (like processRGBAImage() or processYUVImage()) processImage() for non-format-specific processing (if you have a function that doesn't care for what format you use) by default, the format-specific functions call (if not overridden by the child-class) the non-format-specific processImage(), which (by default) outputs an error
a similar change will be for the GemPixDualObj proposal: there will be fucntions for any combination of 2 images, like processRGBA_RGBA() or processYUV_Grey() By default, they call the non-format-specific processDualImage() The processLeftGrey() (and however they are called) are deprecated !
YUV: again i would like to stress: please do not make [yuv_*] objects, but make [pix_*] objects with functions for YUV. The processImage() will then bail out, when images other than YUV want to be processed.
...I really side with chris on this: there is too much of a difference between yuv and rgba to necessitate them being in the same object...true, they are both pixel types, and true, we can convert between the two, but many operations on one would be impossible or at least non-trivial to do for the other; controls would also be totally different and not very interchangeable...
TV: ah, the stupid TV-class. I'm still not sure about it (tending to think that it was a bad idea) the intension is, to make clear, that this objects work only with a series of images (aka: a film). Thus the [pix_aging] is a pix-object (because it will produce something "valid" on single images, although it is designed for a series of images), the [tv_biquad] doesn't make sense with only one picture.
GLUT: i'm very sure, that GLUT is not needed for glm (i haven't really looked at the source-code when i used it then...), we should remove it then (as Günter said). f**k the teapot (it was just for fun...)
...I don't think this is needed either: and glm compiles fine without it on OS X...
PS: well, if you can't compile Gem with the new CVS, i took me some hours too, when the macOS-X code was commited....
...sorry, I didn't know about that: what went wrong? I could only assume that things were ok because I either didn't hear anything or OS X people had no problems...
PPS: maybe i am ironic sometimes in this mail without explicitely saying so with all those smileys (i don't like them)....
...irony is very difficult to interpret in email...!
In any event, let's keep the communication going!
tanx, jamie