I'll try to compule master, but it won't be tomorrow. I don't have my computers set up for development anymore, so I need to sort out all the dependencies.
Maybe if I pull in the Debian source package, they're all there. I was in IT until about 10 years ago, when I quit and went kayaking. Now I just do stuff to run my kayaking company and play. I've become a user ☺️ On 30 Jan 2017 11:44 pm, "jeremy rosen" <[email protected]> wrote: > > > On Mon, Jan 30, 2017 at 11:09 PM, René Seindal <[email protected]> wrote: > >> On 2017-01-30 22:21, jeremy rosen wrote: >> >>> Ok, i'm at home with a little more time on my hand. >>> >>> I didn't manage to reproduce any gui blockage, though I managed to make >>> it very sluggish. I don't have shotwell so I did a little test script >>> but my tests were limited >>> >>> so my first question is : What exactly do you see. Is it a complete gui >>> blockage, or is it just slugishness ? does the dt.gui.selection trick >>> make it completely responsive, or less sluggish ? >>> >> >> If I do nothing in the loop to yield control to the gui, the program is >> by all means unresponsive. If there is some kind of response it is way >> below any reasonable level of usefulness. >> >> > Ah ha... from a diagnosis point of view, "extremely slow" and "blocked" > are totally different things. exteremely sluggish is what I expected, > lookin at your code. That's good. I understand what's going on > > >> The dt.gui.selection trick renders the gui almost normally responsive >> (there are two in-process sql queries run for each file one of which is far >> less than optimal), and the progress bar updates neatly, and the cancel >> button works. >> >> > hmm, dt.gui.selection forces specifically the gtk thread to run... > > >> I'm not completely clear how you block the gtk thread, my guess is that >>> you don't but that somehow some lua is called on each redraw, and when >>> your process is running in a secondary thread, it blocks the lua lock >>> which in turn blocks the gtk thread trying to run lua code. >>> >> >> I have no other lua scripts loaded. >> >> yes, but you still need the lua lock to check that there is no code to > run on some events, so it can still block on the lua lock > > calling dt.gui.selection will force lua to run some code in the "real" >>> gtk thread. To do that, lua programs a task to be run in the gtk thread, >>> release the lua lock, and wait for the job on the gtk thread to do what >>> it has to do. So this call not only releases the lua lock, it also >>> forces a task switch >>> >>> a very short sleep timer will release the lua lock, but take it >>> immediately before the scheduler can run another thread which would take >>> the lock. >>> >> >> In fact, very short sleeps didn't do any good. It only made a difference >> when the sleep approached 1000ms. >> >> The core problem is that your main loop is a case I hadn't thought of. I >>> had thought of long-running shell scripts (darktable.control.execute) >>> waiting for some data to be availalbe on a socket or device >>> (darktable.control.read) or an infinite loop that sleeps for "a long >>> time" (darktable.control.sleep) I hadn't thought of a loop that makes >>> most of its processing in lua and tries to not sleep, but still need to >>> release the lock. >>> >> >> That'll be your just punishment for making the program so extensible - >> you get people like me doing odd stuff :-) > > > i'm fine with that, suprise me :) > > >> >> >> could you test if replacing your call to dt.gui.selection to a call to >>> dt.control.execute("true") also fixes your issue ? >>> >> >> There is some responsiveness, but much less than with the >> dt.guid.selection call. The gui is active but very sluggish and the >> progress bar doesn't update smoothly any more. > > > OK. I'm pretty sure I understand what's going on, but unfortunately i'm > not sure I can fix it completely. the problem is that your script and DT > can't run at the same time. by inserting long "sleep" period and little > "active" periods, you help responsiveness but you don't paralelize more. > > dt.gui.selection helps a little more but it won't be magic either > > The first thing would be to "sprinkle" more calls to > dt.controle.execute("true") around any "long" instruction. in particular > before/after the sql queries, and maybe in the loop on tags (assuming you > have lots of tags per image > > that should help a little > > > After that, I can add some yield magic in the lua locking system but i'll > need you to test it. can you compile DT yourself ? can you use master ? > > This is code that I can test but i don't want to commit if it doesn't > actually help... > > >> >> >> if that helps, I will add a call to g_thread_yield at a strategic place >>> in dt.control.sleep and you will be able to call dt.control.sleep(0) >>> >> >> That would definitely look less obscure than the selection call. >> >> Please let me know if there's anything I can do to help. >> >> I've written another similar script that sets the selection in lighttable >> to all missing files in the current collection. >> >> The script logic is practically the same, it just tries to open the files >> instead of looking stuff up in an sqlite db. This script doesn't slow down >> or block the gui, even if I leave out calls to dt.gui.selection or >> dt.control.execute. >> >> The main difference between the two scripts is now cpu-intensive they >> are. The shotwell script does loads of work on luasql, while the missing >> files script just opens a file and closes it again. >> >> I've attached the thing. >> >> >> >> Thanks for darktable. Now I've learned how to use it a bit, I can't >> imaging how I did without it. >> >> >> -- >> René Seindal - [email protected] >> >> ____________________________________________________________ >> ________________ >> darktable user mailing list >> to unsubscribe send a mail to darktable-user+unsubscribe@lis >> ts.darktable.org >> > > ____________________________________________________________________________ darktable user mailing list to unsubscribe send a mail to [email protected]
