Hi, As far as I remember the problem was that with the threads the UI was too slow. It was basically working but from time to time it was just freezing for few milliseconds and then continues. My guess was that the thread switching takes some time and that this causes the problem. Indeed when I removed the threads everything worked well.
I think the gtk2hs will never become thread friendly. The problem is in the underlying C libraries. I found this page: http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness.html It says that it is possible but cumbersome to write multithreaded applications with GTK. I think that reintroducing the threads is not the right way. This will always introduce some delay between actions and refresh. I am surprised that you redraw the whole screen after each change. This is not the conventional solution and this is the problem. The solutions should be something like this: - the UI independent code should calculate which area of the buffer has been changed i.e. some rectangular area. - the GUI dependent code should call gtk_invalidate (I am not sure about the function name, the documentation should be checked) with the area that has been changed as an argument - the GTK main loop will call the redrawing method of the window at the right moment. The redrawing method will have to redraw only the range that has been changed. Using threads is only workaround which will make the things only heavier. Krasimir On 7/30/09, Jean-Philippe Bernardy <jeanphilippe.berna...@gmail.com> wrote: > > On Thu, Jul 30, 2009 at 4:24 AM, Jason Foutz<jfo...@gmail.com> wrote: > > > > I'm not familiar enough with yi to know where to put the split, but > > yeah, approach sounds exactly right. > > Somewhere, you'll have some code that looks just about like this. > > [...] > > Agreed, this might improve the situation. However, an important part is > missing > in that code: how is the channel going to be filled? I guess whenever > an event comes > from gtk. Therefore the "ui" thread must also fill in an event channel > somewhere. > > Now, this structure existed a couple of years ago in Yi, but gtk2hs > did not support threading > properly, and therefore channels have been replaced by synchronous > function calls. > This was implemented in a patch by Krasimir Angelov around April last > year (I think). > There is still trace of this structure in the code, so I don't think > it would be difficult to revert. > However, I don't know if threading in gtk2hs has improved much since then. > > Cheers, > JP. > > > > --~--~---------~--~----~------------~-------~--~----~ Yi development mailing list yi-devel@googlegroups.com http://groups.google.com/group/yi-devel -~----------~----~----~----~------~----~------~--~---
