I have tried to compile the latest version 3.8.0.9861167 alpha and as in 
the official version that I compiled I still have the problem that it 
does not show the image while it is generated. While compiling it shows 
the following message,

Built-in features:
   I/O restrictions:          enabled
   X Window display:          disabled
   Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
   Unsupported image formats: openexr

Compilation settings:
   Build architecture:  x86_64-pc-linux-gnu
   Built/Optimized for: x86_64-pc-linux-gnu (using -march=native)
   Compiler vendor:     gnu
   Compiler version:    g++ 7
   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings 
-fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math 
-march=native -pthread
   Libraries:           -ltiff -ljpeg -lpng -lz -lrt -lm -lboost_thread 
-pthread  -lboost_system



Note that in the Built-in features the X Windows display is disabled.

I have followed the detailed instructions in
https://github.com/POV-Ray/povray/blob/master/unix/README.md
and I think that the dependencies listed do not include the necessary X 
server or XCygwin or X11 or XDisplay or whatever it is called.

Can someone tell me what is needed to complete the installation?

Thank you very much
B. Gimeno

Post a reply to this message

hi,

BGimeno <bru### [at] gmailcom> wrote:
> I have tried to compile the latest version 3.8.0.9861167 alpha and as in
> the official version that I compiled I still have the problem that it
> does not show the image while it is generated. While compiling it shows
> the following message,
>
> Built-in features:
>    I/O restrictions:          enabled
>    X Window display:          disabled
>    Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
>    Unsupported image formats: openexr
>
> Note that in the Built-in features the X Windows display is disabled.
>

on my machine it reads "X Window display:  enabled (using SDL)",
so it looks like that library (libSDL*.so) is not found/used when building.
hth.


regards, jr.

Post a reply to this message

Am 01.10.2018 um 16:38 schrieb jr:

>> Note that in the Built-in features the X Windows display is disabled.
> 
> on my machine it reads "X Window display:  enabled (using SDL)",
> so it looks like that library (libSDL*.so) is not found/used when building.
> hth.

From what I see in the Unix build scripts, it seems that POV-Ray can't
(or doesn't want to) use SDL without X.

Post a reply to this message

El 01/10/18 a las 17:04, clipka escribió:
> Am 01.10.2018 um 16:38 schrieb jr:
> 
>>> Note that in the Built-in features the X Windows display is disabled.
>>
>> on my machine it reads "X Window display:  enabled (using SDL)",
>> so it looks like that library (libSDL*.so) is not found/used when building.
>> hth.
> 
>  From what I see in the Unix build scripts, it seems that POV-Ray can't
> (or doesn't want to) use SDL without X.
> 

So
"sudo apt-get install libsdl2-dev"
in my case solved this question.
If this resolved the issue in my case maybe it should be included in the 
list of dependencies.
Thank you very much
Regards

B. Gimeno

Post a reply to this message

Am 01.10.2018 um 17:51 schrieb BGimeno:
> El 01/10/18 a las 17:04, clipka escribió:
>> Am 01.10.2018 um 16:38 schrieb jr:
>>
>>>> Note that in the Built-in features the X Windows display is disabled.
>>>
>>> on my machine it reads "X Window display:  enabled (using SDL)",
>>> so it looks like that library (libSDL*.so) is not found/used when
>>> building.
>>> hth.
>>
>>  From what I see in the Unix build scripts, it seems that POV-Ray can't
>> (or doesn't want to) use SDL without X.
>>
> 
> So
> "sudo apt-get install libsdl2-dev"
> in my case solved this question.
> If this resolved the issue in my case maybe it should be included in the
> list of dependencies.

Did you have `libsdl-dev` installed before?

Because that one is explicitly mentioned in `unix/README.md` as /the/
extra prerequisite to enable the render preview display.

To the best of my knowledge, if `libsdl-dev` is installed, you shouldn't
need `libsdl2-dev`, because that's just a newer generation of the library.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 01.10.2018 um 16:38 schrieb jr:
> >> Note that in the Built-in features the X Windows display is disabled.
> > on my machine it reads "X Window display:  enabled (using SDL)",
> > so it looks like that library (libSDL*.so) is not found/used when building.
> From what I see in the Unix build scripts, it seems that POV-Ray can't
> (or doesn't want to) use SDL without X.

one way of looking at it.  :-)

I think POV-Ray does not "do" X at all, the last version (I have access to)
which does is 3.6.1.  from 3.7.x it uses the SDL instead.  a real pity because
if POV-Ray output to an actual X window, knocking up front-ends a la 'qtpovray'
would be  doable in a(ny) number of (scripting) languages, with a single
supporting command line switch (cf 'xterm -into $id').

(also, why SDL in the first place?  all the joystick and audio etc facilities,
unused.  yet, no preview without)


BGimeno:
> "sudo apt-get install libsdl2-dev"
> in my case solved this question.

not all Linux distributions go to lengths to disenfranchise their users.  ;-)


regards, jr.

Post a reply to this message

Am 01.10.2018 um 18:36 schrieb jr:

> I think POV-Ray does not "do" X at all, the last version (I have access to)
> which does is 3.6.1.  from 3.7.x it uses the SDL instead.  a real pity because
> if POV-Ray output to an actual X window, knocking up front-ends a la 'qtpovray'
> would be  doable in a(ny) number of (scripting) languages, with a single
> supporting command line switch (cf 'xterm -into $id').
> 
> (also, why SDL in the first place?  all the joystick and audio etc facilities,
> unused.  yet, no preview without)

I'm pretty sure it was primarily a matter of maintainability. And with
SDL being able to drive Xlib, my naive assumption as a Windows jockey is
that it /should/ still work.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 01.10.2018 um 18:36 schrieb jr:
> > I think POV-Ray does not "do" X at all, the last version (I have access to)
> > which does is 3.6.1.  from 3.7.x it uses the SDL instead.  a real pity because
> > if POV-Ray output to an actual X window, knocking up front-ends a la 'qtpovray'
> > would be  doable in a(ny) number of (scripting) languages, with a single
> > supporting command line switch (cf 'xterm -into $id').
> > (also, why SDL in the first place?  all the joystick and audio etc facilities,
> > unused.  yet, no preview without)
>
> I'm pretty sure it was primarily a matter of maintainability. And with
> SDL being able to drive Xlib, my naive assumption as a Windows jockey is
> that it /should/ still work.

I did have a look at the API (some time ago, not long after installing 3.7), as
I recall there is no way of telling SDL to use a given window (id).

using Xlib (or lower) directly would have the added benefit of the built-in
network transparency.


regards, jr.

Post a reply to this message

Le 01/10/2018 à 20:29, jr a écrit :
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> Am 01.10.2018 um 18:36 schrieb jr:
>>> I think POV-Ray does not "do" X at all, the last version (I have access to)
>>> which does is 3.6.1.  from 3.7.x it uses the SDL instead.  a real pity because
>>> if POV-Ray output to an actual X window, knocking up front-ends a la 'qtpovray'
>>> would be  doable in a(ny) number of (scripting) languages, with a single
>>> supporting command line switch (cf 'xterm -into $id').
>>> (also, why SDL in the first place?  all the joystick and audio etc facilities,
>>> unused.  yet, no preview without)
>>
>> I'm pretty sure it was primarily a matter of maintainability. And with
>> SDL being able to drive Xlib, my naive assumption as a Windows jockey is
>> that it /should/ still work.
> 
> I did have a look at the API (some time ago, not long after installing 3.7), as
> I recall there is no way of telling SDL to use a given window (id).
> 

what about SDL_CreateWindowFrom() ? (just googling libsdl)

The main issue with SDL so far in povray is the lack of title for the 
render window.

I need to investigate SDL_SetWindowTitle()

https://wiki.libsdl.org/SDL_SetWindowTitle


> using Xlib (or lower) directly would have the added benefit of the built-in
> network transparency.

Oh, the dependancy on Xlib is even worse, and Xlib programming is painful.

Also, there is the Wayland menace (no more network, but windows does not 
either, so who care... me !)

Post a reply to this message

Le 02/10/2018 à 13:11, Le Forgeron a écrit :
> Le 01/10/2018 à 20:29, jr a écrit :
>> hi,
>>
>> clipka <ano### [at] anonymousorg> wrote:
>>> Am 01.10.2018 um 18:36 schrieb jr:
>>>> I think POV-Ray does not "do" X at all, the last version (I have
>>>> access to)
>>>> which does is 3.6.1.  from 3.7.x it uses the SDL instead.  a real
>>>> pity because
>>>> if POV-Ray output to an actual X window, knocking up front-ends a la
>>>> 'qtpovray'
>>>> would be  doable in a(ny) number of (scripting) languages, with a
>>>> single
>>>> supporting command line switch (cf 'xterm -into $id').
>>>> (also, why SDL in the first place?  all the joystick and audio etc
>>>> facilities,
>>>> unused.  yet, no preview without)
>>>
>>> I'm pretty sure it was primarily a matter of maintainability. And with
>>> SDL being able to drive Xlib, my naive assumption as a Windows jockey is
>>> that it /should/ still work.
>>
>> I did have a look at the API (some time ago, not long after installing
>> 3.7), as
>> I recall there is no way of telling SDL to use a given window (id).
>>
> 
> what about SDL_CreateWindowFrom() ? (just googling libsdl)
> 
> The main issue with SDL so far in povray is the lack of title for the
> render window.
> 
> I need to investigate SDL_SetWindowTitle()
> 
> https://wiki.libsdl.org/SDL_SetWindowTitle
> 
> 

Ok, SDL2 has a migration guide and it will not be a five minutes patch
for Povray.

https://wiki.libsdl.org/MigrationGuide?highlight=%28SDL_WM_SetCaption%29

Most calls made in Povray have been updated to new functions, so there
might be a bit of change in logic too, and a need for detecting libsdl2
along with libsdl1.2 (none, either or both might be present)

Post a reply to this message

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 02/10/2018 à 13:11, Le Forgeron a écrit :
> > Le 01/10/2018 à 20:29, jr a écrit :
> >> clipka <ano### [at] anonymousorg> wrote:
> >>>> (also, why SDL in the first place?  all the joystick and audio etc
> >>>> facilities,
> >>>> unused.  yet, no preview without)
> >>> I'm pretty sure it was primarily a matter of maintainability. And with
> >>> SDL being able to drive Xlib, my naive assumption as a Windows jockey is
> >>> that it /should/ still work.
> >> I did have a look at the API (some time ago, not long after installing
> >> 3.7), as
> >> I recall there is no way of telling SDL to use a given window (id).
> > what about SDL_CreateWindowFrom() ? (just googling libsdl)

SDL2 only, not before.

> Ok, SDL2 has a migration guide and it will not be a five minutes patch
> for Povray.
> https://wiki.libsdl.org/MigrationGuide?highlight=%28SDL_WM_SetCaption%29
>
> Most calls made in Povray have been updated to new functions, so there
> might be a bit of change in logic too, and a need for detecting libsdl2
> along with libsdl1.2 (none, either or both might be present)

frankly, I'm not convinced it's worth the dependency.  previous versions had a
"proper" X window[*], and I do not understand how abandoning that made
"maintainability" easier.  all I see is a (big) library aimed at games
developers, none of its provisions used, except for the creation of a single
window.  </rant>


[*] why can that (Xlib) code not simply be ported?


regards, jr.

Post a reply to this message

On 10/02/2018 02:27 PM, jr wrote:

> 
> frankly, I'm not convinced it's worth the dependency.  previous versions had a
> "proper" X window[*], and I do not understand how abandoning that made
> "maintainability" easier.  all I see is a (big) library aimed at games
> developers, none of its provisions used, except for the creation of a single
> window.  </rant>

We could make povray beep and shake the mouse when it's done.


-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message

Le 02/10/2018 à 20:27, jr a écrit :
> hi,
> frankly, I'm not convinced it's worth the dependency.  previous versions had a
> "proper" X window[*], and I do not understand how abandoning that made
> "maintainability" easier.  all I see is a (big) library aimed at games
> developers, none of its provisions used, except for the creation of a single
> window.  </rant>
> 
> 
> [*] why can that (Xlib) code not simply be ported?
> 
> 

Because handling at Xlib level means dealing with every possible
colour-depth and colour-system, nearly by hand.

There is B&W display, Palette display, True-color display, and most with
multiple depths for colour (ever seen a colour encoded on 1 byte (3 bits
for Red, Green, 2 for blue... well I did in a previous life)... or size
of palette (which can be system wide or application wide), fixed palette
or user-updatable palette...

the D option used to have a lot of option, it was a nightmare that SDL
is handling now.


And if I remember correctly, the dependencies on X are a bit painful too
 (11R6, 11R7 and now modules are released individually, there was R7.0,
R7.1, R7.2, ... to R7.6 in december 2012, last full at R7.7)

You can handle the X11 you have on your system, but for a distribution,
it is painful to support all of them.

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> On 10/02/2018 02:27 PM, jr wrote:
> > all I see is a (big) library aimed at games
> > developers, none of its provisions used, except for the creation of a single
> > window.  </rant>
>
> We could make povray beep and shake the mouse when it's done.

yes!  lol.


regards, jr.

Post a reply to this message

hi,

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 02/10/2018 à 20:27, jr a écrit :
> > [*] why can that (Xlib) code not simply be ported?
> Because handling at Xlib level means dealing with every possible
> colour-depth and colour-system, nearly by hand.
> ...
> You can handle the X11 you have on your system, but for a distribution,
> it is painful to support all of them.

thanks for the background.

fwiw, I've downloaded/installed SDL2 (gone are the man pages.  </sigh>), so
if/when the "not a 5 minute" conversion job is done I'd be happy to test.

to make this (command-line option to embed POV-Ray in given window) an official
feature request, what need I do?


regards, jr.

Post a reply to this message

Le 03/10/2018 à 00:16, jr a écrit :

> to make this (command-line option to embed POV-Ray in given window) an official
> feature request, what need I do?
> 
> 
You could open an issue on github official povray page, with a
meaningful and short title and a good description.



> regards, jr.
> 
>

Post a reply to this message

On 10/02/2018 11:53 AM, Le_Forgeron wrote:
> Le 02/10/2018 à 13:11, Le Forgeron a écrit :
>> Le 01/10/2018 à 20:29, jr a écrit :
>>> hi,
>>>
>>> clipka <ano### [at] anonymousorg> wrote:
>>>> Am 01.10.2018 um 18:36 schrieb jr:
>>>>> I think POV-Ray does not "do" X at all, the last version (I have
>>>>> access to)
>>>>> which does is 3.6.1.  from 3.7.x it uses the SDL instead.  a real
>>>>> pity because
>>>>> if POV-Ray output to an actual X window, knocking up front-ends a la
>>>>> 'qtpovray'
>>>>> would be  doable in a(ny) number of (scripting) languages, with a
>>>>> single
>>>>> supporting command line switch (cf 'xterm -into $id').
>>>>> (also, why SDL in the first place?  all the joystick and audio etc
>>>>> facilities,
>>>>> unused.  yet, no preview without)
>>>>
>>>> I'm pretty sure it was primarily a matter of maintainability. And with
>>>> SDL being able to drive Xlib, my naive assumption as a Windows jockey is
>>>> that it /should/ still work.
>>>
>>> I did have a look at the API (some time ago, not long after installing
>>> 3.7), as
>>> I recall there is no way of telling SDL to use a given window (id).
>>>
>>
>> what about SDL_CreateWindowFrom() ? (just googling libsdl)
>>
>> The main issue with SDL so far in povray is the lack of title for the
>> render window.
>>
>> I need to investigate SDL_SetWindowTitle()
>>
>> https://wiki.libsdl.org/SDL_SetWindowTitle
>>
>>
> 
> Ok, SDL2 has a migration guide and it will not be a five minutes patch
> for Povray.
> 
> https://wiki.libsdl.org/MigrationGuide?highlight=%28SDL_WM_SetCaption%29
> 
> Most calls made in Povray have been updated to new functions, so there
> might be a bit of change in logic too, and a
needhttps://github.com/POV-Ray/povray/issues/345 for detecting libsdl2
> along with libsdl1.2 (none, either or both might be present)
> 

Just a note another user already has a branch of POV-Ray running with 
SDL2. See the closed issue:

https://github.com/POV-Ray/povray/issues/345

and specifically the comments at the bottom for some details.


-------- Additional rambling
Prior to learning of the above implementation, I tried to get an SDL2 
option, still with SDL1.2 still as the default, compiling and running 
but failed. I wasn't going for a straight map though, but rather an 
update to newer functions both due the migration recommendations and 
also was trying to push today's *nix image window scaling completely 
into SDL2. To advertising anyway - such SDL2 scaling can be done so as 
to use available GPUs on a system over the CPU.

I also had in mind some beeping and stuff(1)... :-)

Aside: For a quick idea of the underlying complexity SDL1.2/2 today 
handles, issue the command:

sdl2-config --static-libs

Related: The POV-Ray static linking with SDL2 is something I could not 
get working (Ubuntu 16.04) because a few of the software package owners 
of SDL2 dependencies have decided providing static libraries is bad for 
security (truth there, but...). There are options to statically link 
what you can and dynamically the rest - but I couldn't get that working 
quickly either.

Bill P.

(1) - Mouse, pad or keyboard input to POV-Ray configured so as to run in 
an interactive loop isn't all that crazy an idea as a way to enable 
simple modeling capabilities that would be as portable as is 
POV-Ray/SDL2.

Post a reply to this message

Le 03/10/2018 à 20:19, William F Pokorny a écrit :

> 
> Just a note another user already has a branch of POV-Ray running with
> SDL2. See the closed issue:
> 
> https://github.com/POV-Ray/povray/issues/345
> 
> and specifically the comments at the bottom for some details.
> 
> 

Thanks, I was able to find a branch with the SDL2 calls, and even
compiled, but there must be some black magic in running SDL2 because I'm
unable to get a window to show when doing "make check"

Post a reply to this message

On 10/04/2018 01:11 PM, Le_Forgeron wrote:
> Le 03/10/2018 à 20:19, William F Pokorny a écrit :
> 
>>
>> Just a note another user already has a branch of POV-Ray running with
>> SDL2. See the closed issue:
>>
>> https://github.com/POV-Ray/povray/issues/345
>>
>> and specifically the comments at the bottom for some details.
>>
>>
> 
> Thanks, I was able to find a branch with the SDL2 calls, and even
> compiled, but there must be some black magic in running SDL2 because I'm
> unable to get a window to show when doing "make check"
>

Ah, it's never easy as I learn every time I think it will be... :-)

I'd not before tried a compile myself. Doing that just now I'm seeing 
the same thing with the lpub3d-raytracer-cui. Even running other scene 
files against the built code explicitly. Ubuntu 18.04.

Hmm, a shot in the dark but let me try clang. No go.

Unsure what the black magic might be and no time to dig at the moment. I 
don't think email via github works these days. I'll post a quick comment 
to the closed issue about getting the SDL2 window to work.

Bill P.

Post a reply to this message

Le 05/10/2018 à 14:11, William F Pokorny a écrit :
> On 10/04/2018 01:11 PM, Le_Forgeron wrote:
>> Le 03/10/2018 à 20:19, William F Pokorny a écrit :
>>
>>>
>>> Just a note another user already has a branch of POV-Ray running with
>>> SDL2. See the closed issue:
>>>
>>> https://github.com/POV-Ray/povray/issues/345
>>>
>>> and specifically the comments at the bottom for some details.
>>>
>>>
>>
>> Thanks, I was able to find a branch with the SDL2 calls, and even
>> compiled, but there must be some black magic in running SDL2 because I'm
>> unable to get a window to show when doing "make check"
>>
> 
> Ah, it's never easy as I learn every time I think it will be... :-)
> 
> I'd not before tried a compile myself. Doing that just now I'm seeing 
> the same thing with the lpub3d-raytracer-cui. Even running other scene 
> files against the built code explicitly. Ubuntu 18.04.
> 
> Hmm, a shot in the dark but let me try clang. No go.
> 
> Unsure what the black magic might be and no time to dig at the moment. I 
> don't think email via github works these days. I'll post a quick comment 
> to the closed issue about getting the SDL2 window to work.
> 

Relax, last night (after midnight) was a bit of good, I should have a 
working prototype with SDL2 soon (I got the window to show, and even to 
update, but I had to resort to tutorial for that, and the original logic 
of the code seems at large)

I also had a look at X11 code of 3.1 and it seems the SDL code (1.2 & 2) 
get a lot of inherited complexity from the old render pattern (3.1: one 
pixel at a time, on the same line, then next line): for instance the 
"optimisation" of rectangle to update is totally wrong now (rectangle is 
never reset, so the whole picture is updated every block, but it is even 
more complex, If I get it correctly, the update of pixels is done by a 
thread and the update of the window is done by another thread (good: the 
update of the window can be slow, so better do it in the front end thread).

It was nice to see the title bar with the "paused" text when rendering 
"make check".

On the sad news, I tried animation and it crashed (but there is comment 
already in official sdl 1.2 disp_sdl.cpp about that kind).

Post a reply to this message

Am 02.10.2018 um 20:27 schrieb jr:

> frankly, I'm not convinced it's worth the dependency.  previous versions had a
> "proper" X window[*], and I do not understand how abandoning that made
> "maintainability" easier.  all I see is a (big) library aimed at games
> developers, none of its provisions used, except for the creation of a single
> window.  </rant>
> 
> 
> [*] why can that (Xlib) code not simply be ported?

I'm not an expert on this - neither do I have experience in working with
Xlib or SDL, nor do I know the historic background - but I assume it's
as simple as this:

(1) The code interfacing with Xlib was difficult to maintain.

(2) Something cropped up that made maintenance virtually inevitable.


My bet for (2) is on the transition from the single-threaded POV-Ray
v3.6 to the multi-threaded POV-Ray v3.7, either directly or via the
architectural changes required.

An alternative candidate reason would be a newly discovered severe bug
or limitation; or an existing moderately severe bug or limitation that
had been deemed impossible to fix with Xlib, but had been accepted due
to a lack of alternative before the advent of SDL.

Post a reply to this message

On 10/05/2018 10:28 AM, Le Forgeron wrote:
> Le 05/10/2018 à 14:11, William F Pokorny a écrit :
>> On 10/04/2018 01:11 PM, Le_Forgeron wrote:
>>> Le 03/10/2018 à 20:19, William F Pokorny a écrit :
>>>
....
>>
>> Unsure what the black magic might be and no time to dig at the moment. 
>> I don't think email via github works these days. I'll post a quick 
>> comment to the closed issue about getting the SDL2 window to work.
>>
> 
> Relax, last night (after midnight) was a bit of good, I should have a 
> working prototype with SDL2 soon (I got the window to show, and even to 
> update, but I had to resort to tutorial for that, and the original logic 
> of the code seems at large)
> 
> I also had a look at X11 code of 3.1 and it seems the SDL code (1.2 & 2) 
> get a lot of inherited complexity from the old render pattern (3.1: one 
> pixel at a time, on the same line, then next line): for instance the 
> "optimisation" of rectangle to update is totally wrong now (rectangle is 
> never reset, so the whole picture is updated every block, but it is even 
> more complex, If I get it correctly, the update of pixels is done by a 
> thread and the update of the window is done by another thread (good: the 
> update of the window can be slow, so better do it in the front end thread).
> 
> It was nice to see the title bar with the "paused" text when rendering 
> "make check".
> 
> On the sad news, I tried animation and it crashed (but there is comment 
> already in official sdl 1.2 disp_sdl.cpp about that kind).

Glad to hear you are making progress.

---
We have too this lockup issue I stumbled across while looking at an 
earlier one:

https://github.com/POV-Ray/povray/issues/142

Not SDL1.2/2 really I guess, but suppose related some to pausing and how 
the code is set up. Looks like I should have posted a follow up to that 
issue in that I didn't have success in creating version of code that 
locked up more routinely. I put my effort to fix it on the shelf for 
later.

So many of my grand POV-Ray ideas fall to the reality I'm still lousy at 
C++, autotools, et al - even after significant study. :-( Ten year rule 
to really get good at anything I guess. Good news is I have only 7 or 8 
years to go...

Sadly, I'm now too old for this route to quick C++ proficiency:

https://abstrusegoose.com/249

Bill P.

Post a reply to this message

Le 06/10/2018 à 12:04, William F Pokorny a écrit :

> Glad to hear you are making progress.
> 

And at the current state, I learn that libsdl (1.2 and 2) is not thread
friendly, it wants (nah, requires) that the thread that make the display
and pull event to be the MAIN thread (and not another child, even if
alone to make the calls)...

But it's working with libsdl2. As a kludge so far.


> ---
> We have too this lockup issue I stumbled across while looking at an
> earlier one:
> 
> https://github.com/POV-Ray/povray/issues/142
> 
> Not SDL1.2/2 really I guess, but suppose related some to pausing and how
> the code is set up. Looks like I should have posted a follow up to that
> issue in that I didn't have success in creating version of code that
> locked up more routinely. I put my effort to fix it on the shelf for later.

Well hidden in libsdl2 forum, the constraint on thread for video and
event (the internal pump is only run by main thread, no pump, no event
to get out).

> 
> So many of my grand POV-Ray ideas fall to the reality I'm still lousy at
> C++, autotools, et al - even after significant study. :-( Ten year rule
> to really get good at anything I guess. Good news is I have only 7 or 8
> years to go...

People spend 3 years in school and think they can program... until they
find a real job and it shows them they do not know yet how to program.

> 
> Sadly, I'm now too old for this route to quick C++ proficiency:
> 
> https://abstrusegoose.com/249

Which C++ ? 03, 11, 14, 17 and I believe 20 is already on the road.

> 
> Bill P.

Post a reply to this message

Le 05/10/2018 à 20:43, clipka a écrit :
> Am 02.10.2018 um 20:27 schrieb jr:
> 
>> frankly, I'm not convinced it's worth the dependency.  previous versions had a
>> "proper" X window[*], and I do not understand how abandoning that made
>> "maintainability" easier.  all I see is a (big) library aimed at games
>> developers, none of its provisions used, except for the creation of a single
>> window.  </rant>
>>
>>
>> [*] why can that (Xlib) code not simply be ported?
> 
> I'm not an expert on this - neither do I have experience in working with
> Xlib or SDL, nor do I know the historic background - but I assume it's
> as simple as this:
> 
> (1) The code interfacing with Xlib was difficult to maintain.
> 
> (2) Something cropped up that made maintenance virtually inevitable.
> 
> 
> My bet for (2) is on the transition from the single-threaded POV-Ray
> v3.6 to the multi-threaded POV-Ray v3.7, either directly or via the
> architectural changes required.

Looking at history, the SDL was introduced in povray to replace both X11 
and SVGA console driver. (that svga was a pain to use, but it was made 
to have a povray similar to the MS-DOS version).

it occurred between 3.5 and 3.6 (between 2003 & 2004)

> 
> An alternative candidate reason would be a newly discovered severe bug
> or limitation; or an existing moderately severe bug or limitation that
> had been deemed impossible to fix with Xlib, but had been accepted due
> to a lack of alternative before the advent of SDL.
> 

I guess it was just simpler to delegate the whole issue of X11 & SVGA to 
a single code and library.

Post a reply to this message

Le 08/10/2018 à 13:23, Le Forgeron a écrit :
> 
> Looking at history, the SDL was introduced in povray to replace both X11 
> and SVGA console driver. (that svga was a pain to use, but it was made 
> to have a povray similar to the MS-DOS version).
> 
> it occurred between 3.5 and 3.6 (between 2003 & 2004)

Nah, it occured in 3.7, 3.6 is still using svga & X11.

Always check before posting...

Post a reply to this message

hi,

Le Forgeron <jgr### [at] freefr> wrote:
> Le 05/10/2018 à 20:43, clipka a écrit :
> > Am 02.10.2018 um 20:27 schrieb jr:
> >
> >> frankly, I'm not convinced it's worth the dependency.  previous versions had a
> >> "proper" X window[*], and I do not understand how abandoning that made
> >> "maintainability" easier.  all I see is a (big) library aimed at games
> >> developers, none of its provisions used, except for the creation of a single
> >> window.  </rant>
> >> [*] why can that (Xlib) code not simply be ported?
> > I'm not an expert on this - neither do I have experience in working with
> > Xlib or SDL, nor do I know the historic background - but I assume it's
> > as simple as this:
> >
> > (1) The code interfacing with Xlib was difficult to maintain.
> >
> > (2) Something cropped up that made maintenance virtually inevitable.
> >
> >
> > My bet for (2) is on the transition from the single-threaded POV-Ray
> > v3.6 to the multi-threaded POV-Ray v3.7, either directly or via the
> > architectural changes required.
>
> Looking at history, the SDL was introduced in povray to replace both X11
> and SVGA console driver. (that svga was a pain to use, but it was made
> to have a povray similar to the MS-DOS version).
>
> it occurred between 3.5 and 3.6 (between 2003 & 2004)
>
> >
> > An alternative candidate reason would be a newly discovered severe bug
> > or limitation; or an existing moderately severe bug or limitation that
> > had been deemed impossible to fix with Xlib, but had been accepted due
> > to a lack of alternative before the advent of SDL.
> >
>
> I guess it was just simpler to delegate the whole issue of X11 & SVGA to
> a single code and library.

given the threads issue you mentioned, maybe a different library altogether?  I
think Tk would "fit the bill" in many respects.


regards. jr.

Post a reply to this message

Am 08.10.2018 um 21:33 schrieb jr:
>> I guess it was just simpler to delegate the whole issue of X11 & SVGA to
>> a single code and library.
> 
> given the threads issue you mentioned, maybe a different library altogether?  I
> think Tk would "fit the bill" in many respects.

Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
an abomination, a Frankensteinian monstrosity.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 08.10.2018 um 21:33 schrieb jr:
> >> I guess it was just simpler to delegate the whole issue of X11 & SVGA to
> >> a single code and library.
> > given the threads issue you mentioned, maybe a different library altogether?  > >
I think Tk would "fit the bill" i
n many respects.
>
> Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
> an abomination, a Frankensteinian monstrosity.

lol.  (that sounds almost like .. allergic)

well I can't "speak" C++ so really cannot comment.  as component in a C program
though, Tcl (and Tk) are pretty straightforward wrt using.  there are of course
"problems", like (n)curses and Tcl wrangling over who controls the std* streams,
otoh, Tk (with Tcl, Perl, whatever) runs on all platforms.  (I'd love to know
though what makes it "monsterous").


regards, jr.

Post a reply to this message

On 10/08/2018 04:00 PM, clipka wrote:

> 
> Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
> an abomination, a Frankensteinian monstrosity.
> 

Oh it can't be any worse than X11. (I can't believe such a thing could
come out of MIT. I thought those were smart people?  'X' reeks of
designed by a committee of budgies.)


The Qt thing is pretty slick.  Maybe I should make an edition that is
straight command line plus preview window.

-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> On 10/08/2018 04:00 PM, clipka wrote:
>
> >
> > Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
> > an abomination, a Frankensteinian monstrosity.
> >
>
> Oh it can't be any worse than X11. (I can't believe such a thing could
> come out of MIT. I thought those were smart people?  'X' reeks of
> designed by a committee of budgies.)

fwiw, from a user perspective X11 is hard to beat.  I /like/ being able to run a
program on machine A and getting the i/o forwarded to machine B, without needing
VNC or RDP or whatnot.


> The Qt thing is pretty slick.  Maybe I should make an edition that is
> straight command line plus preview window.

with "-into" option a la Xterm?


regards, jr.

Post a reply to this message

Le 06/10/2018 à 19:39, Le_Forgeron a écrit :
> Le 06/10/2018 à 12:04, William F Pokorny a écrit :
> 
>> Glad to hear you are making progress.
>>
> 
> And at the current state, I learn that libsdl (1.2 and 2) is not thread
> friendly, it wants (nah, requires) that the thread that make the display
> and pull event to be the MAIN thread (and not another child, even if
> alone to make the calls)...
> 
> But it's working with libsdl2. As a kludge so far.
> 

Now integrating... and the more I know libsdl & libsdl2, the more I hate
them.

I was hoping to have both kind of display available, when both are
installed, and selecting the one which is present when one only is
there, even allowing the user to select explicitly amongst SDL, SDL2, or
text.

They made incompatible API, on purpose they said... so it might have
been possible.

But :
* their include files define the same macro and define, but do not use
the same protection mechanism (that part, I can handle more or less, not
elegant, but doable)
* they kept some identical function interface, including SDL_Init() !!
which means the first linked library initialize its internal structure
and blocks the initialization for the second library, and without
initialized structure, other calls crash.

So back to the blue-print, to make a choice between SDL2 and SDL when
both are present... and maybe restoring the raw X11 port, updated for
the new rendering mode of block, that one could be safe to live in
parallel with SDL(1/2). [should I nickname SDL Ranma ? maybe, as you can
only have one at the same time, but at least Ranma 1/2 is a funny anime,
and I like Ranma, not SDL)


Given the added value of SDL2 vs SDL (the title of the window is set and
updated on pause with SDL2), the hierarchy seems obvious when both are
available.
(yet, have to allow --without-..  to allow user to force the choice)

See you next week.

Post a reply to this message

Am 08.10.2018 um 22:16 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> Am 08.10.2018 um 21:33 schrieb jr:
>>>> I guess it was just simpler to delegate the whole issue of X11 & SVGA to
>>>> a single code and library.
>>> given the threads issue you mentioned, maybe a different library altogether?  > >
I think Tk would "fit the bill" i
> n many respects.
>>
>> Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
>> an abomination, a Frankensteinian monstrosity.
> 
> lol.  (that sounds almost like .. allergic)
> 
> well I can't "speak" C++ so really cannot comment.  as component in a C program
> though, Tcl (and Tk) are pretty straightforward wrt using.  there are of course
> "problems", like (n)curses and Tcl wrangling over who controls the std* streams,
> otoh, Tk (with Tcl, Perl, whatever) runs on all platforms.  (I'd love to know
> though what makes it "monsterous").

The C++/Tk authors boast that their library pretty much preserves the
syntax familiar from Tcl/Tk.

The Tcl syntax is /very/ different from common C/C++, and to achieve
this feat they used some features of the C++ language in manners that
would make every sane C++ programmer's skin crawl.


C++/Tk is, in every sense, a joke takem too far.


I didn't even know C bindings for Tk existed; maybe they are more
faithful to the target language.


I'm not sure how Tcl as a component in a C program would look like.
After all, last time I checked, Tcl is a language, not a library.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 08.10.2018 um 22:16 schrieb jr:
> >> I think Tk would "fit the bill" in many respects.
> >> Don't come anywhere /near/ the POV-Ray code with C++/Tk!  ...
> > I'd love to know though what makes it "monsterous").

> The C++/Tk authors boast that their library pretty much preserves the
> syntax familiar from Tcl/Tk.

this is the first time I have seen "C++/Tk" juxtaposed.

afaik, the only thing (Tcl/)Tk and C++ have in common is the (approximate) year
of when development began; Tcl turned 30 last year.

> The Tcl syntax is /very/ different from common C/C++, and to achieve
> this feat they used some features of the C++ language in manners that
> would make every sane C++ programmer's skin crawl.

and it does not make sense (to me, at any rate).  the whole "idea" is either of
two deployment scenarios:
a) you have some kind of interpreter/shell and provide applications as scripts,
perhaps supported by custom shared libs.
b) you integrate one or more interpreters in your own, usually C, code, and
provide part(s) of the application functionality as scripts (built-ins or user
supplied, whatever).

there's literally no point[*] in the exercise you described.

[*] again, just me.

> C++/Tk is, in every sense, a joke takem too far.

it does sound a little .. perverted.

> I didn't even know C bindings for Tk existed; maybe they are more
> faithful to the target language.

it's how it (Tcl) started.  as a C library to provide a "tool control language",
to drive other command-line apps.  Tk was (so I read) an effort to build on
Apple's HyperCard concept(s) but constrained by need to be modular.

the introduction to the first edition of the "Tcl and the Tk Toolkit" book by
*the man* John Ousterhout (Addison-Wesley Publ.) makes excellent reading.

alternatively, reading
https://en.wikipedia.org/wiki/Tcl#Interfacing_with_other_languages
followed by
https://en.wikipedia.org/wiki/Tcl#Syntax_and_fundamental_semantics
gives an ok outline.

> I'm not sure how Tcl as a component in a C program would look like.
> After all, last time I checked, Tcl is a language, not a library.

a really sharp language lawyer might argue it isn't even a language - as such,
more a set of (12) rules for parsing + substituting strings (EIAS =="everything
is a string").  Tcl has no reserved "keywords", any and all commands can be
renamed (or deleted).

(as an analogy, think of each Tcl command as a separate "program", each taking
one or more argument "words" and returning one result (perhaps empty))

as component of a C (or other compiled) application, it provides access to
scripting via one or more interpreters you create; and has "goodies"
(conveniences?), like easy hash tables etc.


regards, jr.

Post a reply to this message

Am 13.10.2018 um 19:01 schrieb jr:

>> The Tcl syntax is /very/ different from common C/C++, and to achieve
>> this feat they used some features of the C++ language in manners that
>> would make every sane C++ programmer's skin crawl.
> 
> and it does not make sense (to me, at any rate).  the whole "idea" is either of
> two deployment scenarios:
> a) you have some kind of interpreter/shell and provide applications as scripts,
> perhaps supported by custom shared libs.
> b) you integrate one or more interpreters in your own, usually C, code, and
> provide part(s) of the application functionality as scripts (built-ins or user
> supplied, whatever).

Well, interfacing C++ to Tk (the library providing the GUI widgets)
isn't so stupid. Might be an easy way to create a portable GUI. (Though
I guess more modern frameworks like Qt make it even easier.)

Shoehorning the Tcl syntax into C++, now that's pure madness of
Lovecraftian proportions, as we apparently both agree.

But it's fascinating that they get away without a parser. Presumably,
stuff like

    button(".b") -text("Say Hello") -command(hello);
    pack(".b") -padx(20) -pady(6);

works because they co-opt the arithmetic operator `-` for a totally
different purpose that has nothing to do with arithmetics at all.

>> I didn't even know C bindings for Tk existed; maybe they are more
>> faithful to the target language.
> 
> it's how it (Tcl) started.  as a C library to provide a "tool control language",
> to drive other command-line apps.  Tk was (so I read) an effort to build on
> Apple's HyperCard concept(s) but constrained by need to be modular.

Don't confuse the two. Tcl is an iterpreted language. Tk is a library
originally written for Tcl.

When I say C bindings for Tk, I mean a direct interface from C to the Tk
library, without having to use the Tcl interpreter as an intermediate layer.


>> I'm not sure how Tcl as a component in a C program would look like.
>> After all, last time I checked, Tcl is a language, not a library.
> 
> a really sharp language lawyer might argue it isn't even a language - as such,
> more a set of (12) rules for parsing + substituting strings (EIAS =="everything
> is a string").  Tcl has no reserved "keywords", any and all commands can be
> renamed (or deleted).
> 
> (as an analogy, think of each Tcl command as a separate "program", each taking
> one or more argument "words" and returning one result (perhaps empty))

That's what I always do. To me, Tcl is a shell-ish scripting language.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Well, interfacing C++ to Tk (the library providing the GUI widgets)
> isn't so stupid. Might be an easy way to create a portable GUI. (Though
> I guess more modern frameworks like Qt make it even easier.)
>
> Shoehorning the Tcl syntax into C++, now that's pure madness of
> Lovecraftian proportions, as we apparently both agree.
>
> But it's fascinating that they get away without a parser. Presumably,
> stuff like
>
>     button(".b") -text("Say Hello") -command(hello);
>     pack(".b") -padx(20) -pady(6);
>
> works because they co-opt the arithmetic operator `-` for a totally
> different purpose that has nothing to do with arithmetics at all.

replace the parentheses with whitespace and you have two complete (well-formed,
I'd say) commands.  still, weird.


> >> I didn't even know C bindings for Tk existed; maybe they are more
> >> faithful to the target language.
> >
> > it's how it (Tcl) started.  as a C library to provide a "tool control language",
> > to drive other command-line apps.  Tk was (so I read) an effort to build on
> > Apple's HyperCard concept(s) but constrained by need to be modular.
>
> Don't confuse the two. Tcl is an iterpreted language.

s/is/was/  :-)

byte-compiles.  quite a number of years now.


> Tk is a library
> originally written for Tcl.

yes.


> When I say C bindings for Tk, I mean a direct interface from C to the Tk
> library, without having to use the Tcl interpreter as an intermediate layer.

have not done this myself but expect it to be a straightforward as using Tcl.
(after all, developed by the same people)


> >> I'm not sure how Tcl as a component in a C program would look like.
> >> After all, last time I checked, Tcl is a language, not a library.
> >
> > a really sharp language lawyer might argue it isn't even a language - as such,
> > more a set of (12) rules for parsing + substituting strings (EIAS =="everything
> > is a string").  Tcl has no reserved "keywords", any and all commands can be
> > renamed (or deleted).
> >
> > (as an analogy, think of each Tcl command as a separate "program", each taking
> > one or more argument "words" and returning one result (perhaps empty))
>
> That's what I always do. To me, Tcl is a shell-ish scripting language.

nor an uncommon view, I guess.   the simple syntax certainly leads some to
equate that with simple language.


regards, jr.

Post a reply to this message

typos + poor wording.  </sigh>

"jr" <cre### [at] gmailcom> wrote:
> > When I say C bindings for Tk, I mean a direct interface from C to the Tk
> > library, without having to use the Tcl interpreter as an intermediate layer.
>
> have not done this myself but expect it to be a straightforward as using Tcl.
> (after all, developed by the same people)

as straightforward as.  meant when linking to (Tcl) library, note that a subset
of functions (like memory allocator) can be used without an interpreter.


> > That's what I always do. To me, Tcl is a shell-ish scripting language.
>
> nor an uncommon view, I guess.   the simple syntax certainly leads some to
> equate that with simple language.

not, not nor.  :-)


regards, jr.

Post a reply to this message

Le 10/10/2018 à 22:35, Le_Forgeron a écrit :
> See you next week.
> 

Some progress, even if I'm not yet very happy:

https://github.com/LeForgeron/povray/tree/unix/display-window

There is LibSDL2 port (exclusive for linkage with LibSDL1.2), as well as
a basic X11 (without alpha, as alpha is not handle by X11 core).

The same binary can be used to choose the X11 or libsdl via command
switch -y (2 for X11, 3 & 4 for libsdl, 1 for text), when more than one
is detected. (-y is also --preview )

X11 has an icon,  something lost in SDL port.

I got some inspiration (a lot ?) from 3.1 and 3.6, but I'm not yet sure
it is a good idea to disable the destroy window (well, intercept it, but
it get ignored). More tests to do.

The X11 display is from DISPLAY variable, so far so fine. But not yet
able to get inserted in existing window.

There was a lot of luxury in 3.6, and I just went for a basic true color
display. I have also doubt about exposure events, as there is a backing
store. (Just glad to have know that iconification dismissed backing
store, so Map event must be handled when restoring from iconic)

On animation, the previous image is kept but darkened as new background.

Post a reply to this message

Attachments:
Download 'povx11.png' (130 KB)

Preview of image 'povx11.png'

On 10/16/2018 05:54 PM, Le_Forgeron wrote:

> 
> On animation, the previous image is kept but darkened as new background.
> 

I like that.

That is an interesting render pattern in your sample image.  Which is that?

-- 
dik
Rendered 1024 of 921600 pixels (0%)

Post a reply to this message

Le 18/10/2018 à 00:01, dick balaska a écrit :
> On 10/16/2018 05:54 PM, Le_Forgeron wrote:
> 
>>
>> On animation, the previous image is kept but darkened as new background.
>>
> 
> I like that.
> 
> That is an interesting render pattern in your sample image.  Which is that?
> 

Render_Block_Size=16
Render_Block_Step=3
Render_Pattern=4

with 12 threads, and 256 as height & width.

Post a reply to this message

On 10/16/18 5:54 PM, Le_Forgeron wrote:
> Le 10/10/2018 à 22:35, Le_Forgeron a écrit :
...
> 
> There is LibSDL2 port (exclusive for linkage with LibSDL1.2), as well as
> a basic X11 (without alpha, as alpha is not handle by X11 core).
> 
> The same binary can be used to choose the X11 or libsdl via command
> switch -y (2 for X11, 3 & 4 for libsdl, 1 for text), when more than one
> is detected. (-y is also --preview )
> 
...
> 

Playing some with your current hgpovray38 (45eb09ed7) with the thought 
of creating a re-based branch of your windowing changes I can merge into 
my version of POV-Ray.

Issue 1)
I can get an x11 window and a sdl2 window, but not an sdl window though 
it looks like 'make' created and linked x11, sdl and sdl2. The options 
which seemed to work were -y | --preview [x11 | sdl | text]. Is your 
intention not to enable 'sdl1.2' if sdl2 is present or all 4 options as 
it seemed to me you were saying above?

Issue 2)
I'm also attaching an image from the x11 option. I three times got 
something like it where one block didn't update. On the first two 
POV-Ray core dumped on closing the window/program exit. On the last - 
for the attached image - POV-Ray closed the display (used +p) on 
detecting but the POV-Ray process itself didn't exit. Wasn't burning any 
CPU, it was just hung and I had to use the kill command from the command 
line.

If I get some time next week I'll see if I can a debug compile to hang, 
crash or both for more informatino. I had no trouble with SDL2 windows.
Ubunut 18.04 - same set up as you as far as I know.

Aside: Ignore the image's *_segfault.png suffix. I named it thinking 
POV-Ray would crash on exit as had the previous two cases, but then it 
hung instead.

Issue 3)
The x11 option is opening the preview on the screen where the command is 
issued. The sdl2 option seems to always be opening on the primary 
screen. Not dug any here though so perhaps something my screen dual 
screen set up. The current 3.8 master follows your x11 preview screen 
behavior in opening on the screen where the command was issued.

Bill P.

Post a reply to this message

Attachments:
Download 'x11_segfault.png' (53 KB)

Preview of image 'x11_segfault.png'

On 2/2/19 12:16 PM, William F Pokorny wrote:
> On 10/16/18 5:54 PM, Le_Forgeron wrote:
> ...
> 
> Playing some with your current hgpovray38 (45eb09ed7) with the thought 
...
> Issue 2)
> I'm also attaching an image from the x11 option. I three times got 
> something like it where one block didn't update. On the first two 
> POV-Ray core dumped on closing the window/program exit. On the last - 
> for the attached image - POV-Ray closed the display (used +p) on 
> detecting but the POV-Ray process itself didn't exit. Wasn't burning any 
> CPU, it was just hung and I had to use the kill command from the command 
> line.
> 
> If I get some time next week I'll see if I can a debug compile to hang, 
> crash or both for more informatino. I had no trouble with SDL2 windows.
> Ubunut 18.04 - same set up as you as far as I know.
> 

Not a compile with debugging, but had another hang at the very end with 
+p. I used cntl-c this time to try and exit the hung process. Got 
messages a little different though not sure if of much more use:

==== [Paused... Press p to resume] ====================================
Press p, q, enter or press button 1 over displayed image to continue...

POV-Ray finished

^Cterminate called after throwing an instance of 
'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error>

 >'
   what():  boost: mutex lock failed in pthread_mutex_lock: Invalid argument
/home/pokorny/bin/pJG: line 21: 26191 Aborted (core dumped)
/run/shm/tmpDir/tmpUser/MyJG/bin/povray $@

> 
> 

Reminded again of :

https://github.com/POV-Ray/povray/issues/142

though I've not seen any hangs in your code as yet with sdl2 previews - 
just x11 thus far.

---
The usual exit - where no blocks left 'un-displayed?' - and a cntl-c is 
used instead of (p, q, enter or mouse 1) at the end normally shows:

==== [Paused... Press p to resume] ====================================
Press p, q, enter or press button 1 over displayed image to continue...^C
povray: received signal SIGINT: Interrupt; requested render cancel


POV-Ray finished

---
On the windows opening only on certain screens have found in further 
playing the sdl2 and x11 options will both use my second screen if the 
width is such that it fits on screen 1 but not screen 0. In other words, 
both options seem to look for a screen size where the preview image will 
fit if the first screen looked at isn't large enough.

Bill P.

Post a reply to this message

Le 02/02/2019 à 18:16, William F Pokorny a écrit :
> On 10/16/18 5:54 PM, Le_Forgeron wrote:
>> Le 10/10/2018 à 22:35, Le_Forgeron a écrit :
> ...
>>
>> There is LibSDL2 port (exclusive for linkage with LibSDL1.2), as well as
>> a basic X11 (without alpha, as alpha is not handle by X11 core).
>>
>> The same binary can be used to choose the X11 or libsdl via command
>> switch -y (2 for X11, 3 & 4 for libsdl, 1 for text), when more than one
>> is detected. (-y is also --preview )
>>
> ...
>>
> 
> Playing some with your current hgpovray38 (45eb09ed7) with the thought
> of creating a re-based branch of your windowing changes I can merge into
> my version of POV-Ray.
> 
> Issue 1)
> I can get an x11 window and a sdl2 window, but not an sdl window though
> it looks like 'make' created and linked x11, sdl and sdl2. The options
> which seemed to work were -y | --preview [x11 | sdl | text]. Is your
> intention not to enable 'sdl1.2' if sdl2 is present or all 4 options as
> it seemed to me you were saying above?

It is not my intent. It was not my intent.
It is the direct consequence of libsdl being what they are.
They moved from 1.2 to 2.0, breaking backward compatibility of API, yet
keeping some identical signature (function name & parameter type) and
that has consequences : the initialization must be the one from the
library you intent to use, but having the same name, the linker might
pick either (i.e. the other one... ) so you cannot declare linkage for
both libraries (shared) at the same time.
I said linkage... well, guess who reuse the same name, in the same
workspace, with different values between both versions ?
You cannot even compile correctly if you get include from both libraries
in the same source. (they kept the SAME include-defence name, even when
the file are different... no mix of version at compilation time either)

hence, the detection during configure.
-X11 is the base (and you can have Xcursor if you dare as an option, but
it must be explicit), needed by both libsdl 1.2 and libsdl 2.0
(also if you have Xpm support, you get color icons, otherwise b&w old ones)
- if libsdl2.0 is there, it get selected, otherwise fallback to
libsdl1.2 if present.

> 
> Issue 2)
> I'm also attaching an image from the x11 option. I three times got
> something like it where one block didn't update. On the first two
> POV-Ray core dumped on closing the window/program exit. On the last -
> for the attached image - POV-Ray closed the display (used +p) on
> detecting but the POV-Ray process itself didn't exit. Wasn't burning any
> CPU, it was just hung and I had to use the kill command from the command
> line.

Yep, I have also such kind of issues on X11 window, and despite having
focused on updating only the updated block, there might be some deeper
problem in current code (I oversimplified the old X11 code of povray,
dropping all the palette stuff and the double image buffering, and I'm
not sure I even merged late correction to scaled down window).

Lately, I even try to reinstall the setjmp/longjmp system, but it was a
worst idea. Handling X11 Destroy is still a problem (hit the close
button while rendering... and hope! Not a satisfying state)

> 
> If I get some time next week I'll see if I can a debug compile to hang,
> crash or both for more informatino. I had no trouble with SDL2 windows.
> Ubunut 18.04 - same set up as you as far as I know.

Yes SDL2 is working fine, but THERE IS NO ICON ! ("it's not SDL2
problem" to read a ppm to make the RGBImage to use as icon, painful
mentality, when they have sound engines around)

Me ranting ? Maybe.
> 
> Aside: Ignore the image's *_segfault.png suffix. I named it thinking
> POV-Ray would crash on exit as had the previous two cases, but then it
> hung instead.
> 
> Issue 3)
> The x11 option is opening the preview on the screen where the command is
> issued. The sdl2 option seems to always be opening on the primary
> screen. Not dug any here though so perhaps something my screen dual
> screen set up. The current 3.8 master follows your x11 preview screen
> behavior in opening on the screen where the command was issued.

The opening on primary of SDL2 is not my design.
If you feel good at it, go and propose your changes.

X11 is more liberal, and the opening is delegated to the window manager
on the display. On dual-screen, it usually stays near the active cursor,
but you can set your preference to change it (in the limit of the window
manager capabilities): there is CLASS name and usual stuff for user
preference.

My problem(s) so far with X11 are:
- I'm not confident on multithreaded update of window
- the handling of the event queues, in both directions, at the end of
life (on empty scene to render, it might be some race condition and it
is painful to understand)
- destruction & reallocation of resources by two programs (i.e. two
consecutive run) seems to hit on the same pointers/window id/... which
can become messy when the first one ends with a broken pipe and
unprocessed events. (such as getting a creation of the second processed
before the deletion of the first .... which collides and fuck the second
process at random)
(remember the window id are a shared resource in the X11 screen, which
can be referred by whatever processes know them)

On the good side of X11, it's far easier to redirect over modern ssh.

> 
> Bill P.
> 
> 
Jérôme.

Post a reply to this message

On 2/5/19 3:55 PM, Le_Forgeron wrote:
> Le 02/02/2019 à 18:16, William F Pokorny a écrit :
...

Thanks for the detailed background.

> 
> The opening on primary of SDL2 is not my design.
> If you feel good at it, go and propose your changes.
> 

Understand and I don't feel good at it, but might hack at some point.

> X11 is more liberal, and the opening is delegated to the window manager
> on the display. On dual-screen, it usually stays near the active cursor,
> but you can set your preference to change it (in the limit of the window
> manager capabilities): there is CLASS name and usual stuff for user
> preference.

Good to know.

> 
> My problem(s) so far with X11 are:
> - I'm not confident on multithreaded update of window
> - the handling of the event queues, in both directions, at the end of
> life (on empty scene to render, it might be some race condition and it
> is painful to understand)
> - destruction & reallocation of resources by two programs (i.e. two
> consecutive run) seems to hit on the same pointers/window id/... which
> can become messy when the first one ends with a broken pipe and
> unprocessed events. (such as getting a creation of the second processed
> before the deletion of the first .... which collides and fuck the second
> process at random)
> (remember the window id are a shared resource in the X11 screen, which
> can be referred by whatever processes know them)
> 
> On the good side of X11, it's far easier to redirect over modern ssh.
> 
...
> Jérôme.
> 

OK. Thinking, for now, I'll try to create a branch from your work for my 
working version of POV-Ray. Day to day using just the defaulted SDL2 
routinely. I can that way at least look for buggy or interesting 
behavior related to SDL2. Plus, I might be able to try one or more of 
the experiments I had in mind off your SDL2 update given I failed to get 
an SDL2 version working on my own.

Bill P.

Post a reply to this message

BGimeno <bru### [at] gmailcom> wrote:
> I have tried to compile the latest version 3.8.0.9861167 alpha and as in
> the official version that I compiled I still have the problem that it
> does not show the image while it is generated. While compiling it shows
> the following message,
>
> Built-in features:
>    I/O restrictions:          enabled
>    X Window display:          disabled
>    Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
>    Unsupported image formats: openexr
>
> Compilation settings:
>    Build architecture:  x86_64-pc-linux-gnu
>    Built/Optimized for: x86_64-pc-linux-gnu (using -march=native)
>    Compiler vendor:     gnu
>    Compiler version:    g++ 7
>    Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
> -fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math
> -march=native -pthread
>    Libraries:           -ltiff -ljpeg -lpng -lz -lrt -lm -lboost_thread
> -pthread  -lboost_system
>
>
>
> Note that in the Built-in features the X Windows display is disabled.
>
> I have followed the detailed instructions in
> https://github.com/POV-Ray/povray/blob/master/unix/README.md
> and I think that the dependencies listed do not include the necessary X
> server or XCygwin or X11 or XDisplay or whatever it is called.
>
> Can someone tell me what is needed to complete the installation?
>
> Thank you very much
> B. Gimeno

Sorry to necro this thread but ...

Is this issue being addressed in the current 3.8 branch? I'm compiling
povray-3.8.0-alpha.10064268 on a Ubuntu-based distro after being advised it's
the most stable of the development versions. However, as others have posted
using either SDL1.2 or 2.0 throws errors in the compilation phase. I could
simply bash-script up a solution to invoke something like LXImage when the
render completes but having it "built in" is so convenient. :)

Just curious where this is at. I have some time now, retired and under
"lockdown" from the pandemic, to spend some time working on this problem.
However, if the 3.8 branch is no longer being actively developed (perhaps in
favor of 4.x?), or the SDL problem is addressed in another development version,
I'd like to know.

Any response is appreciated. Cheers.

Post a reply to this message

hi,

"Jeff Houck" <jho### [at] northrimnet> wrote:
> ...
> Sorry to necro this thread but ...
>
> Is this issue being addressed in the current 3.8 branch? I'm compiling
> povray-3.8.0-alpha.10064268 on a Ubuntu-based distro after being advised it's
> the most stable of the development versions. However, as others have posted
> using either SDL1.2 or 2.0 throws errors in the compilation phase.
> ...
> Any response is appreciated. Cheers.

re latest alpha compilation errors, was discussed here:

<http://news.povray.org/povray.beta-test/thread/%3C5c6b6863%241%40news.povray.org%3E/>

(I've posted a patch there too, hopefully making the BASH scripting unnecessary)


regards, jr.

Post a reply to this message

"Jeff Houck" <jho### [at] northrimnet> wrote:
> BGimeno <bru### [at] gmailcom> wrote:
> > I have tried to compile the latest version 3.8.0.9861167 alpha and as in
> > the official version that I compiled I still have the problem that it
> > does not show the image while it is generated. While compiling it shows
> > the following message,
> >
> > Built-in features:
> >    I/O restrictions:          enabled
> >    X Window display:          disabled
> >    Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
> >    Unsupported image formats: openexr
> >
> > Compilation settings:
> >    Build architecture:  x86_64-pc-linux-gnu
> >    Built/Optimized for: x86_64-pc-linux-gnu (using -march=native)
> >    Compiler vendor:     gnu
> >    Compiler version:    g++ 7
> >    Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
> > -fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math
> > -march=native -pthread
> >    Libraries:           -ltiff -ljpeg -lpng -lz -lrt -lm -lboost_thread
> > -pthread  -lboost_system
> >
> >
> >
> > Note that in the Built-in features the X Windows display is disabled.
> >
> > I have followed the detailed instructions in
> > https://github.com/POV-Ray/povray/blob/master/unix/README.md
> > and I think that the dependencies listed do not include the necessary X
> > server or XCygwin or X11 or XDisplay or whatever it is called.
> >
> > Can someone tell me what is needed to complete the installation?
> >
> > Thank you very much
> > B. Gimeno
>
> Sorry to necro this thread but ...
>
> Is this issue being addressed in the current 3.8 branch? I'm compiling
> povray-3.8.0-alpha.10064268 on a Ubuntu-based distro after being advised it's
> the most stable of the development versions. However, as others have posted
> using either SDL1.2 or 2.0 throws errors in the compilation phase. I could
> simply bash-script up a solution to invoke something like LXImage when the
> render completes but having it "built in" is so convenient. :)
>
> Just curious where this is at. I have some time now, retired and under
> "lockdown" from the pandemic, to spend some time working on this problem.
> However, if the 3.8 branch is no longer being actively developed (perhaps in
> favor of 4.x?), or the SDL problem is addressed in another development version,
> I'd like to know.
>
> Any response is appreciated. Cheers.

FIXED

Well, it was fairly simple to fix when using SDL1.2. I added:

using namespace std:

to povray-3.8.0-alpha.10064268/unix/disp_sdl.cpp:

    using namespace std;
    using namespace vfe;
    using namespace vfePlatform;

and it all compiles and works fine. I spent most of my time doing C programming
and not C++ so the namespace solution didn't jump out at me at first.

I'll leave changing over to SDL2 for later. It appears I'd have to mess about
with the m4 files ... ;)

Cheers.

Post a reply to this message

Le 27/03/2020 à 19:01, Jeff Houck a écrit :
> "Jeff Houck" <jho### [at] northrimnet> wrote:
>> BGimeno <bru### [at] gmailcom> wrote:
>>> I have tried to compile the latest version 3.8.0.9861167 alpha and as in
>>> the official version that I compiled I still have the problem that it
>>> does not show the image while it is generated. While compiling it shows
>>> the following message,
>>>
>>> Built-in features:
>>>    I/O restrictions:          enabled
>>>    X Window display:          disabled
>>>    Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
>>>    Unsupported image formats: openexr
>>>
>>> Compilation settings:
>>>    Build architecture:  x86_64-pc-linux-gnu
>>>    Built/Optimized for: x86_64-pc-linux-gnu (using -march=native)
>>>    Compiler vendor:     gnu
>>>    Compiler version:    g++ 7
>>>    Compiler flags:      -pipe -Wno-multichar -Wno-write-strings
>>> -fno-enforce-eh-specs -Wno-non-template-friend -s -O3 -ffast-math
>>> -march=native -pthread
>>>    Libraries:           -ltiff -ljpeg -lpng -lz -lrt -lm -lboost_thread
>>> -pthread  -lboost_system
>>>
>>>
>>>
>>> Note that in the Built-in features the X Windows display is disabled.
>>>
>>> I have followed the detailed instructions in
>>> https://github.com/POV-Ray/povray/blob/master/unix/README.md
>>> and I think that the dependencies listed do not include the necessary X
>>> server or XCygwin or X11 or XDisplay or whatever it is called.
>>>
>>> Can someone tell me what is needed to complete the installation?
>>>
>>> Thank you very much
>>> B. Gimeno
>>
>> Sorry to necro this thread but ...
>>
>> Is this issue being addressed in the current 3.8 branch? I'm compiling
>> povray-3.8.0-alpha.10064268 on a Ubuntu-based distro after being advised it's
>> the most stable of the development versions. However, as others have posted
>> using either SDL1.2 or 2.0 throws errors in the compilation phase. I could
>> simply bash-script up a solution to invoke something like LXImage when the
>> render completes but having it "built in" is so convenient. :)
>>
>> Just curious where this is at. I have some time now, retired and under
>> "lockdown" from the pandemic, to spend some time working on this problem.
>> However, if the 3.8 branch is no longer being actively developed (perhaps in
>> favor of 4.x?), or the SDL problem is addressed in another development version,
>> I'd like to know.
>>
>> Any response is appreciated. Cheers.
> 
> FIXED
> 
> Well, it was fairly simple to fix when using SDL1.2. I added:
> 
> using namespace std:
> 
> to povray-3.8.0-alpha.10064268/unix/disp_sdl.cpp:
> 
>     using namespace std;
>     using namespace vfe;
>     using namespace vfePlatform;
> 
> and it all compiles and works fine. I spent most of my time doing C programming
> and not C++ so the namespace solution didn't jump out at me at first.
> 
> I'll leave changing over to SDL2 for later. It appears I'd have to mess about
> with the m4 files ... ;)
> 
> Cheers.
> 
> 
My 0.02c : Please have a look at hgpovray38 fork, where SDL2 is
available. Hope this can help a bit.

https://github.com/LeForgeron/povray

Sadly, linking to support both SDL1.2 and SDL2 is not possible.

Post a reply to this message

> My 0.02c : Please have a look at hgpovray38 fork, where SDL2 is
> available. Hope this can help a bit.
>
> https://github.com/LeForgeron/povray
>
> Sadly, linking to support both SDL1.2 and SDL2 is not possible.

Thank you for the link. I'll be sure to take a look at it. :)

Cheers.

Post a reply to this message