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