Thread: [Java-gnome-developer] Re: [Help] CustomEvents refresh problem

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

On 2003-08-31 07:20, Mark Howard wrote:

> Hi,
>   I've noticed a bug with CustomEvents class, but don't know how to fix
> it (I wrote CustomEvents).
>
> My program calls custom events to update the gui and everything works
> fine from a multithreaded pov (no more of those XLib errors). But: the
> screen doesn't get refreshed until some gtk widget tells it to refresh.
> e.g. when moving the mouse over certain places.

Hello. I have a solution for your problem. I had the same problem myself=20
and I was just about to post my patch to the list anyway.

The patch works just fine for me - it is pretty clean and unless I got=20
something fundamentally wrong, it should work fine for you too. =3D)

The original implementation of CustomEvents does indeed what you said - i=
t=20
doesn't run your events until some other event is received by the so=20
called glib main loop (which gtk uses). The basic problem is how to make=20
glib know when we have posted new events to be executed with CustomEvents=
.=20
The current implementation just sits there and if glib-main-loop happens=20
to ask (which it does when some other event is received), only then does=20
it report whether it has events to serve or not.

The obstacle here is that there is no function we can call in glib to tel=
l=20
it that we have something for it. It basically sits waiting in a select()=
=20
(or similar) call (a function for waiting for file, socket etc descriptor=
s=20
without polling). Now, in CustomEvents, we could tell glib that we need t=
o=20
be polled with certain intervals, basically making select return after a=20
certain delay if there was no data. This is what I tried first, and it=20
worked semi-well, but there was still a "lag" when I kept the timeout at=20
200 milliseconds, as I didn't really want to load the system by polling=20
too often.

My current solution takes another approach - it makes a descriptor that I=
=20
can register to glib, and then I make this descriptor "return data" when =
I=20
want glib to wake up. It utilizes the pipe(2) function, which creates a=20
pair of file descriptors through which data can be piped. I give the=20
"reading end" to glib and keep the writing end for myself. So, whenever=20
there's an event that needs to be served, I write a byte to the pipe, and=
=20
boom, in the main glib thread, select() returns immediately, and glib=20
starts checking for events, including CustomEvents.

The solution provides perfect response for me.

The patch is available here:
  http://xkr47.outerspace.dyndns.org/tmp/java-gnome-0.8.0-customevents-1.=
diff

To use, simply:
   tar xzf java-gnome-0.8.tar.gz
   patch -p0 < java-gnome-0.8.0-customevents-1.diff
   cd java-gnome-0.8
   ..  (continue normal installation)

Alternatively you can use it with java-gtk as well:
   tar xzf java-gtk-0.8.tar.gz
   cd java-gtk-0.8
   patch -p1 < java-gnome-0.8.0-customevents-1.diff
   ..  (continue normal installation)

If anyone have any comments on the implementation, the approach or the=20
problem in general, I'll be glad to discuss it. I'm not on the=20
java-gnome-developer mailing list myself, so I'd appreciate if you CC me=20
anything related. Thanks! =3D)

While writing this, I started thinking, maybe this functionality could be=
=20
a part of glib itself, which would allow one to provide this "missing"=20
function that could be called to trigger a poll for events. Probably this=
=20
wouldn't benefit the java-gnome project itself, merely my patch could be=20
changed to make use of the function at that point.

- xkr47