 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] free fr> 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
|
|
| |
| |
|
|
|
|
| |
|
|
