[PD] [GEM] Bug? and strange behaviour

[IOhannes zmoelnig]

Daniel Heckenberg wrote:
> Hi,
> 
>
> 
> I have, however, come across a couple of things that seem to be a little
> strange:
> 
> 1) Trying to use DV codec compressed AVIs causes PD to crash.  Through the
> wonders of open source, I've tracked this problem down to a NULL return from
> AVIStreamGetFrameOpen(m_streamVid,NULL) in pix_filmNT :: realOpen() from
> pix_filmNT.cpp
> 
thanks for the bug-report, i will check and fix it. (btw: yes this is a 
very cute and rigth way to do it)


> Unfortunately there are some other peculiarities:
> b) the view position moves from the default to 0 0 0
this i cannot reproduce, what does it mean ? when does it change ?
from below i can see, that you are using the "view" message. the default 
viewing position is at "0 0 4" (or -4, i don't remember)

> c) it is not possible to change the viewing position (As far as i can tell)
> using the view message to the gemwin at any stage of the render/flip cycle
i have looked at the code, and i see what you mean.
i think, i will pull the behaviour of "bang" towards "render" rather 
than "swap-buffers".
does this break anything ???


> d) the pixel or texture format seems to get confused... i'm using pix_data
> to pull colours to give to my objects and i need to reverse the order of the
> triple in order to get the right colours to appear.
this might depend on your data.
from your DV-bugs i guess, that you are working with movies.
lot's of movies are stored in BGR-format.
i decided to not change the format directly in the [pix_film]-objects 
because of performance issues.
obviously the pix_data does not know about this and interpretes your 
images are RGB. you can either reverse the triples by hand (as you do it 
know) or use [pix_rgba] to convert it automatically.
i guess you will need only few pixels of the image, so maybe the 
doing-by-hand is way faster (i do not know, whether your patch is 
consumptive or not)


> It seems that I'm not using GEM in the way it may have been intended, 
so who does ??

> but I
> think it would be very useful (and I imagine not difficult) to have the
> system support this kind of thing.  I suspect it's just a matter of
> rearranging the rendering code a little but I've not yet delved that far
> into the code.
sure. i will have a deep breath and think of it

do you need your changes very soon???

mfg.ads.dr
IOhannes


> 
> Daniel
> 
> 
>