Re: Heavy IOChannel use starves UI painting

["Matt Hoosier" <mwhoosier gmail com>]

All,

Thanks for the links to the various multithreading classes. To be
honest, though, the threaded version of the program was already
written before my initial post :)

I'm mainly interested here in understanding what goes wrong when one
attempts the polling-based approach. As Murray suggests, I'll probably
cross-post the original problem description on gtk-list.

Thanks

On 5/31/06, Bob Caryl <bob fis-cal com> wrote:
> I think that the solution to this problem would be to put the file I/O
> into a separate thread, and use a Glib::Dispatcher object to which you
> could connect a function that updates your GUI progress bar.
>
> See
> http://gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1Dispatcher.html
> for details.
>
> Bob Caryl
>
> Murray Cumming wrote:
> > 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?
> >>
> >
> >