Specifically, in this case it's probably enough if the flush has time to reach the X-server (for X, that is) so it hangs on to the pixmap (yet another refcounted system)
GTK.Pixmap <-- refcounted by pike, but connected to GTK refcount GtkPixmap <-- refcounted by GTK, callback to pike when refs==0 GDK.Pixmap <-- refcounted by pike, imperfectly connected to GDK refcount GdkPixmap <-- refcounted by GDK Pixmap <-- refcounted by X
right, but that is my question, shouldn't the client tell the x-server to remove the image once it is done with it?
but then, i guess set_icon() is preventing that, and the actual problem is only that set_icon() itself for some reason does not send the image to the server.
greetings, martin.
I think you are somewhat confused. :-)
Pixmaps are always kept in the server.
There is really no sending done here, except for the initial creation of them (which is done by the time the constructor of GDK.Pixmap() returns)
Step Pike GDK X ----------------------------------------------------------------------- p=GDK.Pixmap() 1 1 1 <-- synchronous p2=GTK.Pixmap() 1+1 1+1 1 set_icon() 1+1 1+1 1 <-- async call p=0 0+1 0+1 1 <-- direct pike-ref gone p2=0 0+0 0+1 1 <-- GTK.Pixmap destroy scheduled backend called flush-to-x 0 0+1 2 <-- icon now set destroy call 0 0 2 <-- all gtk refs gone Free Pixmap 0 0 1 <-- synchronous -----------------------------------------------------------------------
Compare this with the alternative:
Step Pike GDK X ---------------------------------------------------------------------- p=GDK.Pixmap() 1 1 1 <-- synchronous set_icon() 1 1 1 <-- async call p=0 0 0 1 Free Pixmap 0 0 0 <-- synchronous backend called flush-to-x 0 0 0 <-- icon now set to non-existing image -----------------------------------------------------------------------
The solution is to actually handle refcounts correctly for GDK objects. Since they are now actual objects (in GTK 2.0) it's possible. :-)
On Wed, Feb 15, 2006 at 11:50:01AM +0000, Per Hedbor () @ Pike (-) developers forum wrote:
I think you are somewhat confused. :-)
yes, but only as to the point where the image is sent to the server (see below)
Pixmaps are always kept in the server. There is really no sending done here, except for the initial creation of them
i am well aware of that, and it is this initial sending i meant.
(which is done by the time the constructor of GDK.Pixmap() returns)
ok, from the docs (comparing GDK.Pixmap() with GTK.Pixmap()) i thought GTK.Pixmap() would be the one doing the sending.
The solution is to actually handle refcounts correctly for GDK objects. Since they are now actual objects (in GTK 2.0) it's possible. :-)
is that a problem in the pike gtk1 bindings?
greetings, martin.
On Wed, Feb 15, 2006 at 11:50:01AM +0000, Per Hedbor () @ Pike (-) developers forum wrote:
ok, from the docs (comparing GDK.Pixmap() with GTK.Pixmap()) i thought GTK.Pixmap() would be the one doing the sending.
No, GTK.Pixmap does not really talk with the X-server at all, only to GDK.Pixmap objects. It's a pure client-level abstraction (a UI object that draws a GDK.Pixmap)
The solution is to actually handle refcounts correctly for GDK objects. Since they are now actual objects (in GTK 2.0) it's possible. :-)
is that a problem in the pike gtk1 bindings?
Yes. It's not really possible to solve cleanly in GTK1. Hence this problem.
A somewhat unrelated issue: On Windows you need to keep the GDK.Pixmap used as icon around, since it's not refcounted in the 'server' (indeed, there is no server at all).
Same probably goes for the various other GDK ports.
pike-devel@lists.lysator.liu.se
-
Martin Baehr -
Martin B�hr
-
Per Hedbor () ＠ Pike (-) developers forum