Re: I can't understand the difference output of only a line differ

[Gregory Hosler <ghosler redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Binary Chen wrote:
> On Thu, 2007-12-06 at 11:53 +0000, Emmanuele Bassi wrote:
> > On Thu, 2007-12-06 at 19:40 +0800, Binary Chen wrote:
> > >  
> > > > gdk_draw_image() forces a flush. but that is not the problem: you should
> > > > never use a while() loop inside a GTK+ application, because you are
> > > > effectively blocking the real main loop from spinning. remember: GTK+ is
> > > > not threaded.
> > > Yes, I know GTK+ is not threaded, there is only one thread running, so
> > > this make things more complecated, whats loop am I prohibit running?
> > the main loop that processes and delivers the events and handles the
> > redraws, and that is invoked by gtk_main(). you should read the GTK+
> > documentation, at this point.
> >
> > > Again I'd like to say in both testing the gtk_main() is not running at
> > > all, so whats the difference? Can you point out the exact source of such
> > > headache problem?
> > the exact source is, in this case, a PEBKAC; the documentation available
> > on how GTK+ works (at this level, at least) is quite abundant; the GTK+
> > tutorial should shed some more light.
> >
> > > > use a timeout or an idle source to repaint your window with the
> > > > GdkImage.
> > > This is just a testing program, not production code, I just want to find
> > > out whats happening.
> > what's happening is that you are blocking the main loop from ever
> > running, so any result you see is an undefined behaviour.
> >
> > for the third time: use a timeout/idle source instead of the while()
> > loop to hook into the GTK+ main loop.
> You don't know my situation. I am writing a media player which need to
> copy the decoded bitmap into screen.
> I am using gdk_draw_image to draw a GdkImage to the drawing area.
> g_timeout_add is too slow because it need to update the screen  > 20
> times/sec.
> So I need to use a FAST blit to screen, which is only possible using
> busy while... but only if the delay is very small using usleep(1), the
> result is - no things on screen.
> Image a situation that a thread is doing decoding and put the result in
> somewhere memory, another thread drawing to GTK+ widget.

A couple of notes:

1) with a threaded application, you must make sure that *ALL* gtk calls
are done *ONLY* from one thread. Any multi-thread calls into gtk will
lead to unexplained behaviour, possibly including "unexplained" crashes.

2) When you write a "busy" loop, as you have, you are *not* giving the
gtk library any chance AT all to update the screen. Updating teh screen
essentially happens in the gtk_mail loop (or the idle loop), which gets
called when you return from your callback. While you have not given us
all your code, between what you have given us, and the above, it sounds
like when your thread "sleeps()"'s, it is giving the gtk_main a chance
to run.

3) one ugly hack (and it is just that, an ugly hack), would be do to the
following in your while loop:

                while( gtk_events_pending())
                        gtk_main_iteration();

This will "drain" the queued up gtk events (including the display
events), and you'll be happy.

4) Having said that, the fact that you have a forever loop and need to
do this highly suggests that you have a design error. You REALLY should
have a callback that is processing all the queued up images, and then
returns. Perhaps this should even be a g_idle_add() callback if there is
no convenient way to invoke it via some other callback method.

- -G

> Bin
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


- --
+---------------------------------------------------------------------+

Please also check the log file at "/dev/null" for additional information.
                (from /var/log/Xorg.setup.log)

| Greg Hosler                                   ghosler redhat com    |
+---------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFHV/67404fl/0CV/QRAjZmAJ9iYJVSU+xDjPLiW/0qGLpZOlceEwCgmoS5
+JNnCApXBOSEd0H6LoSinMc=
=K9nu
-----END PGP SIGNATURE-----