[GEM-dev] 0.90 and pix_video under Linux

[IOhannes m zmoelnig]

Mirko Petrovich wrote:
 > Hi all,
 > I'm enjoying gem 0.90 but I'm having some problems with pix_video under
 > Linux.
 > Alpha blending doesn't work with pix_video using [alpha] and
 > [colorRGB]in the renderchain (it worked in 0.888-cvs).Should I use
 > [pix_alpha] instead ?

hmm. i just tried and it certainly works for me.
does it produce any result (e.g.: image dimming but no transparency) ?
do you - by chance - have the render order mixed up somehow ?

using [pix_alpha] is basically a not so good idea (even though you might 
get the same results) because the transparency is done on the CPU 
instead of the GPU.

 > Mixing pix_video with pix_buffer_read flips the resulting image. Setting
 > m_image.image.upsidedown=false in videoV4L.cpp and using [pix_video]
 > with [pix_flip] solves this problem (ugly workaround).
indeed ugly.
we have done some performances with [pix_buffer]+[pix_video] (but the 
only image-source has been the [pix_video], so all the images had a 
consistent upside-down-orientation) and it worked perfectly.
i would suggest using [pix_*] objects as little as possible, because all 
the calcs are done on the CPU instead of the GPU (which is optimized) - 
[note: chris says something else in his last emails about SIMD: he is 
right, but a lot of pix_objects are not SIMD-optimized yet (to be 
honest: on win/lin almost no code is MMX/SSE2-enabled)
so using [rotate 0 1 0 180] is basically a better idea than using 
[pix_flip].
but this will not work, when mixing 2 images with different orientation.
i guess you are using another source for feeding the [pix_buffer].
if you can fill the buffer off-line (on start-up) try using the 
[pix_flip] in there, so that heavy calcs (ok: the calcs are not that 
heavy) are not done during performance.

the upsidedown-flag is there for good reasons:
the problem is, that certain libraries (eg: vide4linux) return the image 
in a non-openGL-orientation (the problem is on the openGL-side rather 
than on the libs-side);
i can think of 2 ways to fix this BUG:
a) convert all incoming images to the internal orientation (like a 
built-in [pix_flip]) -> bad, because a lot of unneeded operations have 
to be done
b) rewrite the pix-mixers so they handle de-orientated images correctly

 > Also I'm looking for a way too zoom a pix but pix_zoom never worked 
for me.
 > I'm using RH8 2.4.21 and TNT2 with nvidia drivers.
indeed [pix_zoom] is not really working, and i think it needs a complete 
rewrite.
you can use [pix_coordinates] to stretch a certain texture.
and you can use [pix_crop] to get a sub-image.
and (if you want to zoom in a videoIN-image) you could do some tricks 
with offset/dimen-messages to the [pix_video]-object


mfg.a.rd
IOhannes