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