Re: Heavy IOChannel use starves UI painting

[Murray Cumming <murrayc murrayc com>]

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?

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com