[MPlayer-dev-eng] GUI's icon - a X11 issue?

[Ingo Brückl]

Steaphan Greene wrote on Sun, 12 Jun 2011 16:18:23 -0400:

> On 06/11/2011 06:10 PM, Ingo Brückl wrote:
>> Although I'm relieved to finally have found a solution, there are questions
>> and oddities left I'm very curious about. I don't know whether you are in the
>> mood for looking into them (attached test.patch), but I'd really like to
>> unravel some mysteries:
>>
>> 1. Why does the GDK mask (most often) not work?
>>
>> 2. Why do I get return code 1 instead of Success from XCopyArea() and
>>    XCopyPlane()?
>>
>> 3. Why is the mask copied with XCopyPlane() to the video window all black
>>    and doesn't show any contours?

> I believe the answers to most, if not all, of your questions and
> problems lies deep inside GDK.  Basically, what's happening here is that
> you are creating the GDK pixmap, but requesting its XID before GDK ever
> actually uses it with X (it hasn't actually put the data there yet).
> GDK must have realized this icon (and its mask) before its XID actually
> has the data, and you can really use it.

This carries conviction, but raises the question why the icon itself seems
to be ok, while the mask is a problem. Looking into the GDK source code
shows, that gdk_pixmap_colormap_create_from_xpm_d() (finally somewhere) does
a gdk_draw_pixbuf() for the icon, which seems to execute an X11 draw then.
For the mask, there is no such draw, which may be the explanation.

A look into the X11 sources reveals the explanation for #2 above. Both
functions end with "return 1" instead of "return Success". So how am I
supposed to check the return code of a X11 function? 1 can be BadRequest as
well.

#3 remains a mystery to me.

> I'm sure there is a better way to realize these GtkDrawables into their X11
> Pixmaps.

With your indication of "realization" the gtk main loop came into my mind and
I was wondering whether a call would perform this "pending" task. It seems
that it does.

> And, I also found a bug in a later section of code dealing with this
> icon (a "long" was assumed to be 32-bits), which I have also corrected
> in this patch.

Thanks, I'll patch it.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icon.new.patch
Type: application/octet-stream
Size: 1146 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110613/6faa5ddb/attachment.obj>