search

POV-Ray / povray

The Persistence of Vision Raytracer: http://www.povray.org/
GNU Affero General Public License v3.0
1.35k stars 282 forks source link

Master clobbers the screen's video configuration on rendering #380

Closed JohnCC330 closed 4 years ago

JohnCC330 commented 5 years ago

Summary

When running 3.8.0, with command povray image.pov, colors of entire screen are affected (not only in the povray window). This maybe a driver issue: Making a screenshot saves the correct colors. This did not occur in 3.7 simple 20190906_132724a

Environment

release 


### Compiler/Linker Output

<!-- Copy any compiler/linker errors and other relevant messages between the tilde lines: -->

No errors


<!-- Non-Build Problems Only ------------------------------------------------------------------- -->
### Steps to Reproduce

<!-- Describe the steps you took that led to the issue: -->
 1. povray simple.pov

### Expected Behavior

Display of the rendered image.

### Actual Behavior

Scene is rendered (I suspect correctly), and can be seen with +P enabled, but 
the entire screen's color mapping is now wrong, and I can't reset it without 
restarting X.

### Scene

<!-- Copy a minimal sample scene between the tilde lines: -->
Copied the scene which created the image in the screenshot. As it doesn't
seem a rendering problem, probably _any_ scene would cause the same issue

config_log.gz

include "colors"

light_source { <4, 2, 3>, White }

camera { location <0, 0, 0> look_at <5, 0, 0> }

sphere { <5, 1.5, 0>, 1 finish { reflection 0.4 } pigment { color Red } }

plane { x, 9 pigment { color Gray10 } }

cone { <0, -1, 0>, 1, <0, 1, 0>, 0.5 pigment { color Green } scale 0.3 translate <4, 1, 1> }

box { <1, 1, 1>, <-1, -1, -1> pigment { color Yellow } finish { reflection 1 } rotate <30, 120, 0> translate <5, 0, 0> }



Attached: Original image (rendered by povray 3.7) and (camera) picture taken from screen with the povray-master version.
wfpokorny commented 5 years ago

Weird problem. I see nothing obvious in what you posted, but have some questions & thoughts.

https://github.com/LeForgeron/povray/tree/hgpovray38

or my nearly identical version. (I did some x11 edits ahead of his doing them in his version, but probably they are the same effectively)

https://github.com/wfpokorny/povray/tree/update/JG_sdl2

If one of these v38 based versions work OK, this too would suggest something with SDL1.2 and the version of slackware you are running. If not, ...

JohnCC330 commented 5 years ago

On Fri, 06 Sep 2019 16:27:07 -0700 wfpokorny notifications@github.com wrote:

Weird problem. I see nothing obvious in what you posted, but have some questions & thoughts.

  • Is there a reason you are specifying a prefix and libdir on the configure? Not that I really think this the issue, but I also think you should be able to let them default.

Slackware 64-bit uses a rather un-standard /usr/lib64 path for the libraries. /usr/lib is the default for 32-bit libraries. They shouldn't mix.

  • I think using slackware64-current puts you on the bleeding edge for that distribution. Do older stable versions have this issue? Does this version of Slackware ship with an updated SDL1.2?

Yes. The only reason I changed to the newer version of POVray is that I had a strange conflict with the libpng15 library. So I removed libpng15 entirely and recompiled with png16.

SDL is also 1.2.

  • After a successful make, instead of installing are you able to do the test render with 'make check'? If so, does it also change the screen's colors?

Just checked... Yes, colors are modified.

  • If you render with -d (no SDL 1.2 display) do things work OK? If so, I'd start to suspect your version of SDL1.2. If your screen still gets mangled, could you try a configure with the additional argument: CXXFLAGS="-fstack-protector-strong" and another compile 'make -j2' and then 'make check'.

-D (which I suspect you meant) finishes the render completely and generates the .PNG correctly.

  • Your configure output (FYI it and other perhaps would be more readable as attached text files) has a bunch of incompatible messages from the gnu linker (ld). This is not normal, but given you do link guess something compatible is later found...

Yes. I'm suspecting /usr/lib is hardcoded somewhere, or the link search path get's modified. It should never look in /usr/lib (or /usr/local/lib)

I'll try to do the rest of the suggestions later.

Thanks for the reply - will report with the rest.

John

JohnCC330 commented 5 years ago

Sorry for the delay, I've had to correct partials at the uni. I found some time to test the other versions:

There are also a couple of branches about with support for SDL2.0 mostly done by @LeForgeron and he has a version of this as part of his hgpovray38 version.

https://github.com/LeForgeron/povray/tree/hgpovray38

This version does not compile:

...
usr/include/boost/math/common_factor.hpp:16:60: note: #pragma message: This header is deprecated. Use <boost/integer/common_factor.hpp> instead.
 BOOST_HEADER_DEPRECATED("<boost/integer/common_factor.hpp>");
                                                            ^
backend/scene/view.cpp: In member function ‘void pov::ViewData::getBlockXY(unsigned int, unsigned int&, unsigned int&)’:
backend/scene/view.cpp:244:53: error: expected primary-expression before ‘long’
                  unsigned long perimeter = std::abs<long>(south-north)*2+std::abs<long>(east-west)*2;
                                                     ^~~~
backend/scene/view.cpp:252:43: error: expected primary-expression before ‘long’
                      perimeter = std::abs<long>(south-north)*2+std::abs<long>(east-west)*2;

or my nearly identical version. (I did some x11 edits ahead of his doing them in his version, but probably they are the same effectively)

https://github.com/wfpokorny/povray/tree/update/JG_sdl2

This version does compile, but produces the same problem as before (i.e. the colors get mixed up)

If you've not tried it, a fresh compile of 3.7-stable off github through a 'make check' render might be interesting. It was not clear to me whether you had similarly recompiled 3.7 or just run what you had installed?

Yes, I re-downloaded the -stable version and re-compiled. Several times in fact.

I'll try to find the original (old) 3.7.0 which used to work, and retry that version.

wfpokorny commented 4 years ago

Some more thinking aloud given what I think I've heard you say:

I don't know what else to do here except keep experimenting. Suppose you've checked the usual slackware support forums for similar, recent issues?

Edit: Sep 17 06:00:16 EDT 2019 Fixed typo with a version number at top. See strike-through.

wfpokorny commented 4 years ago

OK. @LeForgeron 's DISPLAY issues are #156 and #157 and related to DISPLAY not being set at all or set to a window which does not exist. The failure symptoms are different and in your case I have to believe your DISPLAY is set correctly given what you see.

LeForgeron commented 4 years ago

you can fix/change view.cpp with the following

view_patch.txt

I do not know why you do not have std::abs, but actually it will be better with the explict type and std::labs .

This part of view.cpp is only to handle the rendering pattern as a spiral.

LeForgeron commented 4 years ago

From my investigation on x11/SDL/SDL2 : povray (master) will try to use SDL if available, otherwise it goes to X11. And the X11 code is a nightmare (because the X library have constraint on the thread which performs the operation).

On hgpovray38, the order of choices is SDL2, then SDL, and whatever X11 can be selected manually. (SDL2 and SDL are not usable by a single binary, you cannot ask for both).

I tried many variations on X11, including using mutex & other tricks, to finally give up (IIRC, the master version of disp_x11 is stupid, there is plenty of optimisation to transfer only the update block, but it ends transfering the whole pixmap each time because the optimisation was hard-coded in the time of rendering one pixel at a time of 3.1, and this is plain wrong today)

A basic program is fine, and sometime a render is fine too, but I also got corrupted preview.

About the change of colours for whole screen, the disp_x11 tried to handle many screen mode (including static_display, and palettes): in the current world of true colors everywhere, it is overly complicated. If your display only support a global palette, it is kind of expected that this palette get updated for the render windows.

wfpokorny commented 4 years ago

@JohnCC330, @LeForgeron 's comments about the x11 display reminded me there was some command I used long ago to dump x11 settings. Web search tells me that command is xdpyinfo. Might be interesting to see what you see running xdpyinfo. I see 24 planes (DirectColor) or 32 planes (TrueColor) everywhere.

JohnCC330 commented 4 years ago

@wfpokorny xdpyinfo reports a large numer of configurations available (270!), also 24 plane DirectColor and 32 plane Truecolor. Maybe some of these configurations are problematic?

xdpy.txt.gz

JohnCC330 commented 4 years ago

With all the mentions of SDL and SDL2, I searched for simple demo programs for both. Behold - both test programs cause the color issues. For SDL I compiled & ran sdltest. For SDL2 I ran the Hello World example

The latter needs some coaxing to get it to build. Si I suspect that the issue is between SDL and the video, and not Povray? I'll try to find out more...

wfpokorny commented 4 years ago

Running small SDL1.2, SDL2 demos a good idea and yes SDL* certainly a trigger - and a simpler debug path for whatever is happening. Using my JG_SDL2 branch (or a patched hgpovray38), you can try POV-Ray with x11 thanks to @LeForgeron: povray --preview x11 +d +p the.pov

Suppose I'd say if it works without the color shift, it makes stronger the case it is just SDL triggering. If still a color shift, well, the demos of SDL probably still a better debug path. The SDL folks will be much better debuggers (certainly than me) for this sort of thing as it's more central to what they do.

I looked over your xdpy.txt and compared it to mine. Your running a newer version. I have three extensions you don't. You are runnming many more x11 things than me - 270 vs 70. One thing different is the name of your display is :6.0 where mine is :0 ($DISPLAY). The position after the colon is the display number and I am surprised it's not 0 for you like me unless your machine is seeing multiple logins or something. Used to be I knew the X11 stuff a little better, but the knowledge has drifted away with the years.

JohnCC330 commented 4 years ago

Solved! Even though all other programs worked fine (except for the SDL* demos) my system (with the AMDGPU) apparently needs two kernel modules (amdgpu and radeon) to work and support AMD's GPUs. For some reason, the radeon kernel module was blacklisted and thus did not load. I couldn't believe that none of the other programs complained or failed.

Thanks for all suggestions! All archived for future adventures ;)