On 7/11/20 11:04 AM, jr wrote:
>> I've not done any animations with the x11 display. I'll try it
>> myself later today. I'd make a moderate bet from your output it's again
>> the architectural problem of x11/sdl* not being at the top thread-wise,
>> so to speak.
> thanks. wish I knew/understood more about the code, 'disp_x11.*' etc. naively,
> after the initialisation, just bracketing the worker thread's call to update the
> window (a buffer-to-buffer move, I assume?) with calls to 'XLockDisplay' +
> companion should do, no?
:-) I suspect you know more than me. I'm no expert with X11, having only
surfaced hacked now and again on code using X11. At a high level, if we
have all the locking / unlocking in place to prevent thread safety
issues while asking x11 to do stuff and visa versa, things would work.
What I'm testing is what the nice, verbose error message from X
suggested - XInitThreads. This seems to add lock / unlocks around all
the x11 interactions. Thus far, it's working(1).
(1) - The other x11 issues routinely seen OK too - so far.
I was able to duplicate your animation / X11 fails easily - thanks
(without the sigh this time :-)). Start up an animation and then create
many interrupts by moving the window hitting keys and such and somewhere
in the first 20 frames - almost always - boom! Having something which
fails reliably is very useful. I wasn't able to get there with the prior
SDL1.2 github issues.
I'll run with the x11 display for a few days and we'll see if the
XInitThreads() fix holds up.
In reading about it, it looks like it's not the efficient approach and
likely there is additional exposure to hangs where an interrupt
generating a lock happens elsewhere during a lock introduced by using
XInitThreads(). The latter particular locks perhaps not strictly necessary.
The underlying issue tangled here, given our current code architecture,
is the interrupt handing happening in ways that cause a deadlock of
locks and hence occasional hangs. For users not generating large numbers
of interface interrupts, I believe such hangs are rare.
Aside: An idea on my 'maybe someday' wish list is POV-Ray run-able in a
continuous loop(2) while accepting scene updating input. Re-reading and
rendering a scene file as edits/updates are made. I think it possible to
do limited modeling (spline editing say) without jumping up to Blender,
Moray or whatever tool to do it.
(2) - Similar in behavior to animation today, but where modeling not
animation is the aim. No image output, just continuous re-rendering of a
changing scene to the display. Yes, ugly, partial hacks of this can be
Post a reply to this message