After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 89492 - gdk_pixbuf_render_to_drawable doesn't work on root window
gdk_pixbuf_render_to_drawable doesn't work on root window
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: X11
2.0.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2002-07-31 07:17 UTC by Thomas Munck Steenholdt
Modified: 2011-02-04 16:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Xtest application with extra images for testing (91.13 KB, application/octet-stream)
2002-07-31 20:36 UTC, Thomas Munck Steenholdt
  Details
small test app that renders two (one alpha, one non-alpha) png's onto root window (30.04 KB, application/octet-stream)
2002-08-13 06:28 UTC, Thomas Munck Steenholdt
  Details
revised testcase (1.82 KB, text/plain)
2002-08-13 08:25 UTC, Matthias Clasen
  Details
proposed patch (589 bytes, patch)
2002-08-13 21:44 UTC, Matthias Clasen
none Details | Review

Description Thomas Munck Steenholdt 2002-07-31 07:17:28 UTC
I was trying to port a GTK1.2 application to GTK2.0 and had som problems
getting the gdk_pixbuf_render_to_drawable like functions to work with a
pixbuf loaded from PNG files... Actually the only one of four images seemed
to work so i decided to investigate on the differences... 
file * told me that the image that worked was a PNG type RGBA whereas the
non-working images was PNG type RGB... So I used GIMP to convert the
images(added alphachannel) and suddenly it worked fine...

Am I doing something wrong or is this either a feature or a bug?
Comment 1 Owen Taylor 2002-07-31 16:18:11 UTC
Can you attach a test case? I'm a little suprised that nobody
has reported this before if it is in fact a problem.

Comment 2 Thomas Munck Steenholdt 2002-07-31 20:36:54 UTC
Created attachment 10159 [details]
Xtest application with extra images for testing
Comment 3 Thomas Munck Steenholdt 2002-07-31 20:44:22 UTC
OK, i added a sample program which is in fact the smapp app i have
been porting... The tool is used in (at least) the redhat
distribution, to test X configuration... The attached version is the
ported GTK2 version...

it loads images to draw on the screen from
/usr/X11R6/share/Xtest/pixmaps and i've included two sets of the
images - the original and the Gnome2 ones... copy the images from
sampleimages or sampleimages.orig to the path shown above to test with
the two different kinds of png's... The gnome2 version(sampleimages)
are all RGBA type PNG's... the Gnome1.x version (sampleimages.orig)
are all RGB type except for desktop_icons which also have the alpha
channel...

Please notice that the panel_mid image seems to show fine, but only
because a new pixbuf are created at runtime that is specified to have
transparency... The image is scaled into a new pixbuf, which is the
reason for this...

images are loaded in funcytion open_sample_image line 209 and rendered
onto the background in function set_background line 220

Hope this helps... The app is very simple so I didn't see a reason to
create a whole new project for debugging... hope you agree.
Comment 4 Owen Taylor 2002-07-31 22:29:24 UTC
Heh, amusingly:

 - I was Cc'ed on that bug report
 - I spent 5 minutes porting Xtest to GTK+-2.0
 - The images didnt' show up, it wasn't obvious why
 - I said "darn, this is too hard to debug, if someone
   else really cares, they will do the port."

It would actually be really useful to me if you could
modify the Xtest program to draw to a toplevel, instead
of starting an X server and drawing on the root window;
that would have been my next step if I continued trying
to debug Xtest.

(Also, I like to have reasonably portable as well as reasonably
standalone test cases in bugzilla.)

Comment 5 Thomas Munck Steenholdt 2002-08-01 09:28:58 UTC
Argh - I have been trying all morning to make sort of a minimalistic
program that demonstrates the error, but haven't been able to figure
out how to create a top level window that can be used for rendering
pixbufs onto... I have never done anything in GTK before this tiny
porting thing and i guess thats whats coming back to haunt me now...
If you have any suggestions that migh help me, please do so, in the
meantime i guess i'll have to do some studying on GTK in order to
maybe succeed in creating the test app... :(
Comment 6 Thomas Munck Steenholdt 2002-08-02 10:07:03 UTC
OK, i cunducted a small test, which involved modifying the pixmap
example program from gtk+-2.0.5 to lead a pixbuf and render it onto
the pixmap in the example... Here the result is different... Also the
non-transparent PNG's work fine, which suggests(to me) that maybe this
has something to do with the pixmap returned by GDK_ROOT_PARENT(); Off
course i migh well be wrong. Please give me your oppinion on the
matter and let me know how to proceed... Summary: Unable to reproduce
error in toplevel window!
Comment 7 Thomas Munck Steenholdt 2002-08-12 10:05:43 UTC
I was just wondering I there was anything else I could provide you
with in order to figure out if this is indeed a bug or if it's working
the way it's supposed to!
Comment 8 Owen Taylor 2002-08-12 18:34:34 UTC
It probably "just" needs to be debugged in the root window
case... I guess it would help to have a standalone program that
didn't start an X server, but just tried to draw on the 
existing root window.


Comment 9 Thomas Munck Steenholdt 2002-08-13 06:28:53 UTC
Created attachment 10450 [details]
small test app that renders two (one alpha, one non-alpha) png's onto root window
Comment 10 Thomas Munck Steenholdt 2002-08-13 06:32:34 UTC
OK, I created a small test for you to try... It loads two included png
files one with alpha and one with no alpha, and renders them both onto
the root window 0,0(trans) 256,0(non-trans)

Hope it helps you to figure out if it is a bug at all ;-)
Comment 11 Matthias Clasen 2002-08-13 08:24:08 UTC
Doesn't work for me at all (nothing gets drawn), but this has nothing to do with alpha. 
Debugging into it, it seems that gdk_drawable_get_clip_region returns an empty 
region for _gdk_parent_root, since position_info.clip_rect is all 
zeros.

This conjecture is supported by the fact that rendering 
on

gdk_window_foreign_new (gdk_x11_drawable_get_xid 
(gdk_get_default_root_window ())); 

instead of 


gdk_get_default_root_window ()

works fine. I'll attach my modified 
testcase.
Comment 12 Matthias Clasen 2002-08-13 08:25:38 UTC
Created attachment 10453 [details]
revised testcase
Comment 13 Matthias Clasen 2002-08-13 08:26:28 UTC
I investigated on 2.0.6, btw. Don't know if the gdk initialization
changed in HEAD.
Comment 14 Thomas Munck Steenholdt 2002-08-13 08:46:00 UTC
Does this mean that both the alpha + the non-alpha image gets drawn on
the root window???

For the test I did, i logged into a "failsafe" session, with nothing
but an xterm and the transp. image would be rendered onto the
background but not the non-transp. one.

Could you please summarize for me what you found(I may be a little
slow) :)
Comment 15 Thomas Munck Steenholdt 2002-08-13 09:16:18 UTC
Actually I see it now, but just to make sure, the use of
GDK_ROOT_PARENT() is just not the way to do it in GTK2?
You really need the line you provided, to get the root window pixmap?

Just want to make sure I get it correctly!
Comment 16 Matthias Clasen 2002-08-13 10:08:13 UTC
Well, GDK_PARENT_ROOT is the same as gdk_get_default_root_window(),
and it 
doesn't work to draw on it - thats a bug. I have shown you
a workaround using 
gdk_window_foreign_new ().
Comment 17 Matthias Clasen 2002-08-13 21:44:01 UTC
Same problem occurs on cvs HEAD. 
Comment 18 Matthias Clasen 2002-08-13 21:44:58 UTC
Created attachment 10469 [details] [review]
proposed patch
Comment 19 Owen Taylor 2002-09-26 23:17:07 UTC
Looks fine to commit to both branches, assuming that it
works in testing.
Comment 20 Matthias Clasen 2002-09-27 23:06:18 UTC
Committed to both branches.