POV-Ray : Newsgroups : povray.unix : X Windows display: disabled Server Time
29 Mar 2024 01:47:24 EDT (-0400)
  X Windows display: disabled (Message 34 to 43 of 48)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 5 Messages >>>
From: clipka
Subject: Re: X Windows display: disabled
Date: 13 Oct 2018 15:19:11
Message: <5bc2452f$1@news.povray.org>
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

From: jr
Subject: Re: X Windows display: disabled
Date: 13 Oct 2018 19:30:01
Message: <web.5bc27eec6c2a6a24b0d4fc1e0@news.povray.org>
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

From: jr
Subject: Re: X Windows display: disabled
Date: 14 Oct 2018 00:45:01
Message: <web.5bc2c8616c2a6a24b0d4fc1e0@news.povray.org>
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

From: Le Forgeron
Subject: Re: X Windows display: disabled
Date: 16 Oct 2018 17:54:13
Message: <5bc65e05@news.povray.org>
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'
povx11.png


 

From: dick balaska
Subject: Re: X Windows display: disabled
Date: 17 Oct 2018 18:01:35
Message: <5bc7b13f$1@news.povray.org>
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

From: Le Forgeron
Subject: Re: X Windows display: disabled
Date: 18 Oct 2018 12:38:18
Message: <5bc8b6fa$1@news.povray.org>
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

From: William F Pokorny
Subject: Re: X Windows display: disabled
Date: 2 Feb 2019 12:16:34
Message: <5c55d072$1@news.povray.org>
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'
x11_segfault.png


 

From: William F Pokorny
Subject: Re: X Windows display: disabled
Date: 2 Feb 2019 23:57:26
Message: <5c5674b6$1@news.povray.org>
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

From: Le Forgeron
Subject: Re: X Windows display: disabled
Date: 5 Feb 2019 15:55:09
Message: <5c59f82d@news.povray.org>
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

From: William F Pokorny
Subject: Re: X Windows display: disabled
Date: 7 Feb 2019 10:14:48
Message: <5c5c4b68$1@news.povray.org>
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

<<< Previous 10 Messages Goto Latest 10 Messages Next 5 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.