On Sun, 2006-05-28 at 17:42 -0500, Matt Hoosier wrote:
On 5/28/06, Paul Davis <paul linuxaudiosystems com> wrote:
its to make it *possible* to integrate IO into the mainloop. the
mainloop's primary purpose is still to handle and dispatch events, and
if your file i/o code is stopping the mainloop from doing that in a
timely fashion, then its interfering with that purpose. the mainloop
calls your io callbacks and doesn't regain program control to handle
events until they return,
I am fairly confident that this can be made to work efficiently without
starving the UI. But you might need to ask on gtk-list about strategies
to do that, if nobody here knows how.
Agreed. But in this example, the IO handlers do return at least once
for every 32K chunk of data copied. For a file with even just 10 MB of
content, that's hundreds of iterations of the mainloop: chances (one
would think) for the UI to repaint itself. During those hundreds of
mainloop iterations, the progressbar widget is getting put into a
dirty state ~100 times. How does one judge when the painting logic
will take notice of this dirty flag and decide to issue an expose
event?