nelsnelson / gource

Automatically exported from code.google.com/p/gource
0 stars 0 forks source link

Only white images by PPM export #46

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. ./gource -s 0.2 $GITDIR --stop-position 0.01 --output-framerate 30 
--output-ppm-stream stream.ppm
2. Open stream.ppm in file reader or image viewer and see only
invalid/empty frames.

What is the expected output? What do you see instead?
Instead of the rendered images the frames are only white (all image bytes
0xFF). Concatenating with ffmpeg produces only grey video.

What version of the product are you using? On what operating system?
Gource 0.24 on Fedora 12, 64-bit

Please provide any additional information below.
Maybe it has to do with the graphics hardware (e.g. missing OpenGL features
for texture rendering)? I'm using an ATI Radeon Mobility X1400.

The screen output looks good.

Original issue reported on code.google.com by niemueller on 21 Feb 2010 at 9:46

GoogleCodeExporter commented 8 years ago
Very strange. When this happens, is the screen white too?

Original comment by acaudw...@gmail.com on 22 Feb 2010 at 2:58

GoogleCodeExporter commented 8 years ago
Nope, although insanely slow (and seems to miss updates if you pull another 
window in
front) it shows the start of the sequence just fine.

Original comment by niemueller on 22 Feb 2010 at 8:42

GoogleCodeExporter commented 8 years ago
It sounds like glReadPixels() is returning all white for some reason, like its
pointing at the wrong buffer, somehow.

Could you try and replace the glReadPixels call in src/ppm.cpp with:

glReadBuffer(GL_BACK);
glPixelStorei(GL_PACK_ALIGNMENT, 1);
glReadPixels(0, 0, display.width, display.height,
        GL_RGB, GL_UNSIGNED_BYTE, next_pixel_ptr);

And see if that helps.

Original comment by acaudw...@gmail.com on 22 Feb 2010 at 10:04

GoogleCodeExporter commented 8 years ago
Nope, that didn't do it. Still the same result. I have re-verified and after the
initial ASCII header there are only 0xFF values.

Original comment by niemueller on 22 Feb 2010 at 10:51

GoogleCodeExporter commented 8 years ago
I guess another thing would be to check if glReadPixels is in fact setting 
values to
0xFF (ie next_pixel_ptr[0] == 0xFF after call but not initially or something 
like
that) and if glReadPixels() is setting an error so that glGetError() returns a 
non
zero value.

It could also be that 'char' arrays (pixel1, pixel2, pixels_shared_ptr and
next_pixel_ptr) need to be changed to be 'unsigned char'.

Original comment by acaudw...@gmail.com on 23 Feb 2010 at 9:19

GoogleCodeExporter commented 8 years ago
Can you provide some patch to try? I have also tried the (new) Fedora package, 
no
success either. I have asked the package for more info, e.g. if the problem 
appears
also on his box and on 32-bit 
(https://bugzilla.redhat.com/show_bug.cgi?id=567559).

Original comment by niemueller on 23 Feb 2010 at 9:34

GoogleCodeExporter commented 8 years ago
Ok I wrote a patch to try:

This test patch changes char to unsigned char and will print some debugging to 
STDERR
each time we call glReadPixels().

This will tell us (hopefully):

- was an error set by glReadPixels(), and what was it.
- did glReadPixels() modify the input array or leave it the same.
- did glReadPixels() modify the input array to 0xFF.

Original comment by acaudw...@gmail.com on 23 Feb 2010 at 10:29

Attachments:

GoogleCodeExporter commented 8 years ago
Tried it. Still the same result, prints the following on the screen:

glReadPixels(0, 0, 1024, 768, 6407, 5121, next_pixel_ptr)
next_pixel_ptr[0] == 0xFF (changed to 0xFF)

Anything else you want me to try?
Maybe you can also try it with the F-12 x86_64 Live CD from
http://download.fedoraproject.org/pub/fedora/linux/releases/12/Live/x86_64/Fedor
a-12-x86_64-Live.iso
on your system?

Original comment by niemueller on 23 Feb 2010 at 12:10

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
I've got the same issue on a WinXP box.
BUT: when runned without --output-framerate the program window is just white.

Case 1) gource.exe some_log_file

Everything is just fine.

Case 2) gource.exe some_log_file --output-ppm-stream some_file 
--output-framerate 25

I can see the animation in the program window, but it runs much much slower 
than in
case 1, and it seems to be displaying a single white frame for a fraction of 
second
every second or so.

The stream is all white frames.

Case 3) gource.exe some_log_file --output-ppm-stream some_file

The program window is all white.

Original comment by tomasz...@gmail.com on 23 Feb 2010 at 2:16

GoogleCodeExporter commented 8 years ago
Can you try commenting out these 3 lines in FrameExporter::dump():

display.renderToTexture(screentex, display.width, display.height, GL_RGBA);
display.fullScreenQuad(true);

...

display.fullScreenQuad(false);

If this fixes it, you will see upside down images in the ppm file.

Also if this doesn't work, could you try version 0.23 from the Downloads 
section as I
made a lot of changes between 0.23 and 0.24 and it may be one of those.

Cheers

Original comment by acaudw...@gmail.com on 23 Feb 2010 at 8:54

GoogleCodeExporter commented 8 years ago
It's upside down but otherwise it contains the expected output! So how do we 
get it
flipped without loosing content again?

Original comment by niemueller on 24 Feb 2010 at 1:48

GoogleCodeExporter commented 8 years ago
Great, I wasn't sure if we were going to figure this out.

Can you apply this patch to the original source. It does the flip in software 
now.

Original comment by acaudw...@gmail.com on 24 Feb 2010 at 3:28

Attachments:

GoogleCodeExporter commented 8 years ago
The patch works just fine. Thank you! Will you put out a new release? Would 
make the
life much easier for packagers.

Original comment by niemueller on 27 Feb 2010 at 8:03

GoogleCodeExporter commented 8 years ago
Now in 0.25

Original comment by acaudw...@gmail.com on 1 Mar 2010 at 1:22