[PD] [GEM] Bug? and strange behaviour

[Daniel Heckenberg]

Thanks IOhannes,

On the question of "procedural" gem list generation in double buffer mode:
I've recreated the patch using the [render_trigger] object to avoid the
viewport movement and other problems, so there's no immediate time pressure
from me.  I think it would be nice for single buffer and double buffer modes
to behave more consistently in the long term tho.

> > 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)

The viewport shifts when the (double buffered) viewport is banged... I've
attached a sample patch to demonstrate.

> > 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 ???

hmm.  not sure.  i'll leave that one to you ;-)

> > 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)

I did try to use a [pix_rgba] to convert the data before I used [pix_data]
to sample the pixels and it seemed to make no difference.  In fact, I've
cooked up a little patch to demonstrate (either my lack of understanding, or
some problem).