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]
