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