[Xorg-driver-geode] No icon bug

[Huang, FrankR]

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
Xorg-driver-geode at lists.x.org
http://lists.x.org/mailman/listinfo/xorg-driver-geode


End of Xorg-driver-geode Digest, Vol 27, Issue 2
************************************************