[PD-dev] [GEM] new postrender crashes OS X

[IOhannes zmoelnig]

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 at iem.kug.ac.at
> http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
>