
At 06:52 30-1-03 -0800, Krasimir Angelov wrote:
Maybe Krasimir can tell us more about the issues involved?
The first big stone which I was found was handling of scollbars in the windows. The scrollbars are implemented rather different in Windows and GTK. [..] ... The ScrollFunction calculates new position of the scrollbar after each scroll event. That means that scrollbar manipulation is handled at top level instead of low level C code. [..] I think that it isn't imposible to improve the library but this was too discounraged for me. The reason for the complicated implementation of scrollbars is that they have to be handled explicitly by the programmer on the Mac platform. The impression that I get from your account is that scrollbar handling on GTK is rather similar to Windows. In general, one really needs a ScrollFunction to determine its behaviour: imagine a textprocessor that allows you to handle text with different font (heights). Then scrolling down/up one line depends on the height of the current top/bottom line. I can't blaim you for being discouraged... the implementation of the Object I/O library isn't as 'clean' is I would like it to be.
[..] There is also another trouble with OS layer in ObjectIO. Because the Clean FFI doesn't allow C functions to execute Clean the OS layer is implemented with two co-threads. The first thread is in the C world and is synchronized with Clean thread with mutexes. The C<->Haskell communication can be much more easy but the ObjectIO still uses old fashion comunication with threads. Avoidance of this trouble isn't so easy because large part of library depends on co-threads. This is avoided in both HToolkit and Port. The co-thread architecture is indeed a major bottleneck both in understanding the implementation, and performance (which BTW is already very good). The reason is, as Krasimir says, the historical lack of calling Clean from C. Fortunately, this has been incorporated recently to Clean by John van Groningen, so this gives us a good opportunity to get rid of this approach and adopt a more natural and intuitive implementation. This will give another performance boost to the library.
Regards, Peter