Hi !
sorry about all this fuzz, but i'm hardly online now and this makes discussion a bit hard: anyhow, let's try to explain:
tigital wrote:
hello,
...I'm really not sure what or why IOhannes is doing some of these changes? So far, they have led to crashes and instability on the Mac OS X port. Thanks. I am frustrated, because things that worked no longer function correctly! What makes it worse is that these changes are done without any announcement or warning, unless you watch the cvs logs daily...and even then, the logs are not specific to changes in a file, and do not give any insight to the scope of the changes...
ok. 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
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
...the first problem came when IOhannes decided to rewrite the processImage() system: thankfully, he tried to hide most of this within #ifdef NEW_DUAL_PIX, but there was no discussion as to the thought behind this...
sorry, see above.
...then he filed a rewrite of rendering:
deleted pix_fx the pix_fx functionality is now in GemPixObj this functionality is: save the image-state before it is processed and reconstruct it in the postrender function so we can change size/format and even bend the data-pointer and objects "before" will not notice (and crash)
...this is the cause of my crashes...previously, I could switch out movies on the fly when doing dual processing; now we get segfaults when there is no "old_data"...and this change was supposed to fix a crash? haha
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.
...I don't see how Mac OS X support for GEM can continue without a little discussion before unilaterally making changes to cvs that affect all platforms...
i am very glad that you did the macOS-X port, and i do want (both of) you to continue
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.
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...)
MISC: i'm sorry, but i'm sure i have forgotten a lot of things right now...
mfg.asdr.fasd IOhannes
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....
PPS: maybe i am ironic sometimes in this mail without explicitely saying so with all those smileys (i don't like them)....
l8r, jamie
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev