Re: Heavy IOChannel use starves UI painting

[Bob Caryl <bob fis-cal com>]

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?
> >     
>
>   
begin:vcard
fn:Robert Caryl
n:Caryl;Robert
org:Fiscal Systems, Inc.
adr:;;102 Commerce Circle;Madison;AL;35758;USA
email;internet:bob fis-cal com
title:Senior Software Design Engineer
tel;work:356-772-8920 X108
x-mozilla-html:TRUE
url:http://www.fis-cal.com
version:2.1
end:vcard