https://bugs.kde.org/show_bug.cgi?id=463197
--- Comment #12 from Metal450 <metal...@gmail.com> ---
(In reply to caulier.gilles from comment #11)
> For the rest, especially the GUI operations, X11 under Linux is not
> re-entrant, and threading cannot be used.
1) I see. So I'm assuming that in this case, it has already been determined
that the operation which locks up the software is purely the UI calls
themselves - in other words, there isn't anything else that could be pushed to
another thread?
2) For what it's worth, in C#/WinForms, you also cannot directly perform any UI
updates from background threads - however, in effect you can accomplish the
same with something like the following. Not sure if something similar exists in
qt:
// This function runs in a background worker thread
private void backgroundWorker_DoWork(object sender, DoWorkEventArgs e){
// If you need to update the UI, you cannot do it directly from
here - this would not be threadsafe/could crash:
//uiElement.Text = "whatever"
// However, you can safely accomplish the same by using a
MethodInvoker to dispatch it back to the UI thread:
MethodInvoker invoker1 = new MethodInvoker(delegate ()
{
// Can manipulate any UI elements here. So effectively the
operation was "originated" from the background worker, but the actual update
// gets queued to safely occur on the main UI thread
uiElement.Text = "whatever";
});
this.BeginInvoke(invoker1);
}
3) Even if there's no way to put it on another thread, it really seems like
there should be creative solutions that would prevent it from locking up,
regardless of the number of images. For example, break up the images into
batches, and only add at most "maxN" items to the UI per invocation, before
returning control to the message loop so that user interaction can still take
place. I'm not directly familiar with how qt's message loop is implemented,
but:
* Does that just mean inserting a brief sleep() or similar in the code that
adds all the image thumbnails to the UI, so any user interaction messages could
be processed before continuing?
* Or perhaps using a custom "SET_UI_IMAGES" message, which gets processed by
adding maxN images to the UI, and re-queuing the same message type until all
images have been added? (and when the user scrolls to a particular part of the
scrollable container, on the next iteration of SET_UI_IMAGES, it would
prioritize adding load the corresponding subset of maxN to the UI)
Basically, just some way to hand control back to the main message loop often
enough that this long process doesn't have to run all in one go - and thus
regardless of the total number of images, it need not block everything else
until it's done.
--
You are receiving this mail because:
You are watching all bug changes.
