[PD-dev] [GEM] new postrender crashes OS X
tigital at mac.com
Tue Dec 17 15:22:47 CET 2002
>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...
>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
>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 !
>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...
>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
>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!
More information about the Pd-dev