Sorry that I used the digest mode. I have cancelled it. And change the bug no to "No icon bug". Comments with [Frank] below:
------------------------------------------------------------------------ - See my comments in private e-mail. BTW, I've wrapped your comments above and below. Traditional Internet mailing list etiquette recommends you wrap lines at about 72 columns. You're going to find out just how bad Outlook is. :-) [Frank] Correct. The Outlook's reply is not very clear. So I must use [...] to delegate me. This approach hasn't achieved the desired goal of isolating the problem to a small set of drawing routines so I think we will have try a different approach. Instead of the X server and a simple test application, let's try the X server, a simple window manager, and a simple test application with a colour icon. In other words, a minimal X session with window manager but not a full blown desktop environment. For a simple window manager, you can try icewm, fvwm, openbox, or perhaps metacity. If this demonstrates the problem, look at the icon handling code in the window manager and trace that back to rendering commands in the X server. [Frank] A gtk+ program does not need a window manager to run. With the Xorg + "gtk+ program", this bug can be reproduced easily. So I will trace the gtk+ application call. But it will need read the glib function call. This is me talking: > I'm assuming that the bug report is not a problem with the window > manager but a problem with the pixmap rendering code. In other words, > I'm assuming the window manger (and/or the GNOME desktop managed by > Nautilus) uses pixmaps to render icons and that the problem is with the > generic pixmap rendering code. Thus, you want a test program that simply > displays a small pixmap so we can see if it's rendered properly. The > test program should display the pixmap itself, not rely on the window > manager to display its icon. And your response: > What's the difference between using window manager to handle > and the pixmap rendering code? I don't know. It depends on the implementation of the window manager. There may be no difference, there may be large differences. That's why I'm trying to guide you into recreating the problem with a simple test program so we know which drawing routines trigger the bug. [Frank] With the help of Mart, I will trace the glib call from the gtk+ program(reproduce this issue) and find the Xserver render call part. > If using the pixmap rendering code, Does it use some function > from libxpm? Again, that depends on the implementation of the window manager. > And how about the code for geode driver? No, it won't use libxpm. It will have its own implementation and/or will take advantage of routines in the hardware. > I give some prints sentence in the lx_exa.c file and found > some functions are triggered here. Which ones? I expect many EXA backend functions are called but we're trying to isolate functions that fail to do what they're supposed to do. [Frank] I have not given deep understanding for this file. Mart find the lx_check_composite() and lx_prepare_composite() has relationship with this bug. > The basicwin program use a pixmap rather than an image. The > difference is what for a pixmap from data and from an image? Simply, pixmaps are server side objects and images are client side. Typically, images are used when you have to to do some client side image processing before rendering whereas pixmaps are used for static images that are loaded once and rendered repeatedly. [Frank] Got it. The difference is where it is. > The GNOME icons are typically png or svg files, so they're colour, but I > don't know how they are rendered. > > What happens if you run: > > eog /usr/share/icons/Human/24x24/places/folder.png > What about a different image viewer, e.g. `display' from Image Magick? > Run it like this: > > display /usr/share/icons/Human/24x24/places/folder.png > [Frank] The display application is also same as the eog. It can > display the icon normally on the screen and the color is also right > under two environments. OK, so neither `eog' nor `display' demonstrate the problem but `nautilus' does. Interesting. [rest deleted] ------------------------------ _______________________________________________ Xorg-driver-geode mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-geode End of Xorg-driver-geode Digest, Vol 27, Issue 2 ************************************************ _______________________________________________ Xorg-driver-geode mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-geode
