www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Fiber based UI-Toolkit

reply =?UTF-8?Q?Christian_K=c3=b6stlin?= <christian.koestlin gmail.com> writes:
I wonder if there is any fiber based / fiber compatible UI-Toolkit out
for dlang. The second question is, if it would make sense at all to have
such a thing?

christian
Jul 09
next sibling parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
 I wonder if there is any fiber based / fiber compatible 
 UI-Toolkit out for dlang. The second question is, if it would 
 make sense at all to have such a thing?

 christian
It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render.
Jul 09
next sibling parent Meta <jared771 gmail.com> writes:
On Sunday, 9 July 2017 at 21:12:24 UTC, bauss wrote:
 On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
 I wonder if there is any fiber based / fiber compatible 
 UI-Toolkit out for dlang. The second question is, if it would 
 make sense at all to have such a thing?

 christian
It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render.
Aren't all fibers executed from a single thread?
Jul 09
prev sibling next sibling parent reply =?UTF-8?Q?Christian_K=c3=b6stlin?= <christian.koestlin gmail.com> writes:
On 09.07.17 23:12, bauss wrote:
 On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
 I wonder if there is any fiber based / fiber compatible UI-Toolkit out
 for dlang. The second question is, if it would make sense at all to
 have such a thing?

 christian
It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render.
Thanks for answering! you are touching exactly my question: Lets say, that all the event handling is done by fiber-aware code (means all io gives the thread free, when it would block, and perhaps a yield function for calculation heavy operations). It would then I think reduce the "risk" of a ANR (Application not responding (from android) or the famous beachball) without sacrificing the clarity of the code. e.g. you want to download something from a webpage and process the data, if you click a button. you cannot do this in the buttons-onclick callback (because this is usually a long running operation and the callback is called from the main thread). with fibers, the main thread could continue running (and update the screen) as soon as the io thread is blocking or the process thread calls yield (which he should on a regular basis). after the processing as soon as the fiber gets back the control, the result can easily be integrated back into the ui, because its already in the right thread. compare this with the traditionally apporach of spawning a new thread, passing over the arguments, processing it, passing back the result and integrating this into the ui, it could perhaps be "simpler". on the other hand, the process code would get a little bit messy because of the manually inserted yields (as far as i know, the erlang vm for example inserts such instructions automatically every n instructions). what do you think?
Jul 09
parent =?UTF-8?Q?Christian_K=c3=b6stlin?= <christian.koestlin gmail.com> writes:
On 10.07.17 00:23, Christian Köstlin wrote:
To elaborate on the previous post, I uploaded a small example, that
tries naively to mix dlangui with fibers. Please have a look at:
https://github.com/gizmomogwai/fibered-ui.git
For sure it does not work. The fiber in the callback is started,
but after the first yield, dlangui never returns to the fiber.
Does anybody know what needs to be done for that?

thanks a lot,
Christian

 On 09.07.17 23:12, bauss wrote:
 On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
 I wonder if there is any fiber based / fiber compatible UI-Toolkit out
 for dlang. The second question is, if it would make sense at all to
 have such a thing?

 christian
It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render.
Thanks for answering! you are touching exactly my question: Lets say, that all the event handling is done by fiber-aware code (means all io gives the thread free, when it would block, and perhaps a yield function for calculation heavy operations). It would then I think reduce the "risk" of a ANR (Application not responding (from android) or the famous beachball) without sacrificing the clarity of the code. e.g. you want to download something from a webpage and process the data, if you click a button. you cannot do this in the buttons-onclick callback (because this is usually a long running operation and the callback is called from the main thread). with fibers, the main thread could continue running (and update the screen) as soon as the io thread is blocking or the process thread calls yield (which he should on a regular basis). after the processing as soon as the fiber gets back the control, the result can easily be integrated back into the ui, because its already in the right thread. compare this with the traditionally apporach of spawning a new thread, passing over the arguments, processing it, passing back the result and integrating this into the ui, it could perhaps be "simpler". on the other hand, the process code would get a little bit messy because of the manually inserted yields (as far as i know, the erlang vm for example inserts such instructions automatically every n instructions). what do you think?
Jul 09
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-07-09 23:12, bauss wrote:

 I believe OSX (possibly macOS too.) only allows it from the main thread.
Yes, that's correct. But what's the difference between OSX and macOS ;) -- /Jacob Carlborg
Jul 10
parent bauss <jj_1337 live.dk> writes:
On Monday, 10 July 2017 at 08:40:15 UTC, Jacob Carlborg wrote:
 On 2017-07-09 23:12, bauss wrote:

 I believe OSX (possibly macOS too.) only allows it from the 
 main thread.
Yes, that's correct. But what's the difference between OSX and macOS ;)
Well besides that it's newer versions of the OS, then nothing much I guess. It could potentially change such specs though.
Jul 10
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-07-09 21:43, Christian Köstlin wrote:
 I wonder if there is any fiber based / fiber compatible UI-Toolkit out
 for dlang. The second question is, if it would make sense at all to have
 such a thing?
If I recall correctly, vibe.d has some form of integration with the native GUI event loop on Windows. -- /Jacob Carlborg
Jul 10
prev sibling parent reply Gerald <gerald.b.nunn gmail.com> writes:
On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
 I wonder if there is any fiber based / fiber compatible 
 UI-Toolkit out for dlang. The second question is, if it would 
 make sense at all to have such a thing?
As previously noted, like other UI toolkits GTK maintains a single thread for processing UI events with an event loop running in that thread. GTK does support passing a function to be called when the main loop is idle, it could be possible to leverage this to manage fibers with appropriate yielding. Having said that, I'm in the camp where this doesn't make much sense. Using fibers on the main UI thread is likely going to result in a blocked UI whenever a fiber takes too long to do its work. History has shown that cooperative multi-tasking typically doesn't work well for UI applications. I think you would be much better off starting an additional thread and managing fibers in that thread outside the context of the main UI thread. You can then use things like std.concurrency to receive messages from the external thread to update the UI as needed in it's own thread.
Jul 10
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-07-10 15:37, Gerald wrote:

 Having said that, I'm in the camp where this doesn't make much sense. 
 Using fibers on the main UI thread is likely going to result in a 
 blocked UI whenever a fiber takes too long to do its work. History has 
 shown that cooperative multi-tasking typically doesn't work well for UI 
 applications.
It's that basically the whole idea of async/await? Seems like Microsoft is pushing quite heavily for that in GUI code. -- /Jacob Carlborg
Jul 10
parent reply Gerald <gerald.b.nunn gmail.com> writes:
On Monday, 10 July 2017 at 14:03:59 UTC, Jacob Carlborg wrote:
 On 2017-07-10 15:37, Gerald wrote:

 Having said that, I'm in the camp where this doesn't make much 
 sense. Using fibers on the main UI thread is likely going to 
 result in a blocked UI whenever a fiber takes too long to do 
 its work. History has shown that cooperative multi-tasking 
 typically doesn't work well for UI applications.
It's that basically the whole idea of async/await? Seems like Microsoft is pushing quite heavily for that in GUI code.
Thanks for the link, I'm not active with .Net so I had to go look it up. Reminds me a lot of the way node.js works. If all your async activity is IO bound maybe it works fine and I'm wrong about this. My past experience has been that it's challenging to determine the appropriate times to yield particularly with a lot of async activity happening. However with it baked into the framework and a simplified API maybe it becomes less of an issue. I'll have to do more reading on it, again thanks for the pointer.
Jul 10
parent Jacob Carlborg <doob me.com> writes:
On 2017-07-11 04:40, Gerald wrote:

 Thanks for the link, I'm not active with .Net so I had to go look it up. 
 Reminds me a lot of the way node.js works. If all your async activity is 
 IO bound maybe it works fine and I'm wrong about this.
 
 
 My past experience has been that it's challenging to determine the 
 appropriate times to yield particularly with a lot of async activity 
 happening. However with it baked into the framework and a simplified API 
 maybe it becomes less of an issue.
 
 I'll have to do more reading on it, again thanks for the pointer.
I'm not that familiar with .Net either but this async/await feature is spreading across languages: C++, JavaScript, .Net, Dart and possibly others. As far as I understand it consists of two parts: coroutines (resumable functions) and asynchronous operations, usually IO. Any async function returns some form of future type. If you call that function, it will return immediately and let the execution continue. Now it's possible to do work that is independent of the result of the previous call. When you do need the result of the first call, you call "await" on the return value of that call, the future. If the result is ready, everything is fine and the execution continues. If the result is not ready, your function will suspend and the caller will continue the execution. You don't need to do any explicit yielding due to the language and framework support. The only thing you need to determine is when you need the result of an aysnc function call. -- /Jacob Carlborg
Jul 10
prev sibling parent =?UTF-8?Q?Christian_K=c3=b6stlin?= <christian.koestlin gmail.com> writes:
On 10.07.17 15:37, Gerald wrote:
 On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
 I wonder if there is any fiber based / fiber compatible UI-Toolkit out
 for dlang. The second question is, if it would make sense at all to
 have such a thing?
As previously noted, like other UI toolkits GTK maintains a single thread for processing UI events with an event loop running in that thread. GTK does support passing a function to be called when the main loop is idle, it could be possible to leverage this to manage fibers with appropriate yielding. Having said that, I'm in the camp where this doesn't make much sense. Using fibers on the main UI thread is likely going to result in a blocked UI whenever a fiber takes too long to do its work. History has shown that cooperative multi-tasking typically doesn't work well for UI applications. I think you would be much better off starting an additional thread and managing fibers in that thread outside the context of the main UI thread. You can then use things like std.concurrency to receive messages from the external thread to update the UI as needed in it's own thread.
Thanks for this answer, my thinking was also in this direction. I guess for many use cases fibers in ui could be good enough (like my simple example, getting something from a webserver, (quickly) process it and display it). given a fiber-based http-client, this could work quite nicely. For real programs, with heavy transformation of the data, I think this would not work so well, because either you block the ui with the processing code in the fiber, or your processing code is not running full speed, because it has some yields sprinkled throughout the code. On the other hand side, i also guess, that for ui and even more for audio rendering, every tiny bit of delay can hurt the experience. So probably not a good idea for a real world application? Best regards, Christian p.s. i still wonder about jacobs argument about microsofts async/await.
Jul 10