228003 - When rendering to a remote X server without RENDER ext support, PNG's are much slower than GIF or JPG

Status: RESOLVED WONTFIX

(Core Graveyard :: X-remote, defect)

Description

[steve oconnor]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Im using an SGI Octane, Irix 6.5 as an XTerminal.  The Octane is fast enough,
and the 100Mbs ethernet works well.

From the Octane, I ssh to a number of linux boxes, and run a variety of gecko
based browsers - Galeon, Mozilla and the now the Latest Firebird release.

When the page that I am viewing has Gifs / Jpegs, performance is great .. almost
like I was on the local console.

When I change the webserver to use PNG's rather than GIFs, and view it again via
remote-X on the Octane,  all gecko based browsers that I am using choke
horribly.  I get 20 second delays, during which time the window will not repaint
at all.  (test by dragging a smaller window over the gecko window to force a
repaint).   The PNG's are around 30k, the Gif is around 10k - its not a
bandwidth issue. Both PNG and Gif in this case have transparent backgrounds. Im
not using alpha trans layers in the PNG.  

tcpdump reports large storms of traffic for the PNG pages which are not present
in the GIF or JPEG pages.

There may be something horribly wrong with the way that PNG's are rendered on X.
Hopefully, this happens in local-X mode as well, but is too fast to be
recognised .. just creating unneccessary CPU munching with PNGs ?


Reproducible: Always

Steps to Reproduce:
1. Create a page with a few transparent Gifs, and a duplicate page that uses
transparent PNGs.
2. Remote-X connect to a machine, run Mozilla on that machine.
3. Bring up a few tabs, load the Gif page in one of them. Observe that it is
snappy and fast moving between tabs.
4. Bring up the Png version in another tab. Observe that swapping between tabs
is criminally slow.
5. Run tcpdump to capture traffic from the remote machine to your Xserver,
observe the difference in traffic between PNG and GIF.

Actual Results:  
Very bad performance with PNG, and lots of X11 packets in comparison to GIF.

Expected Results:  
I dont understand the rendering details at this level. It may be that Gifs and
Jpegs are translated to X server-side pixmaps that can be flipped around as
needed, but transparent PNG's are not sent over as X server-side pixmaps.

There may be good reasons for handling this differently ? - Dunno, but it really
hurts performance and generates network traffic.

This would also hurt local displays (if true), by creating un-needed socket
traffic and CPU burn.

Comment 1

[Olivier Cahagne]

CC'ing tor, please remove self from CC if I abused this.

Comment 2

[tor]

X doesn't have any support for rendering images with more than masked (1-bit)
transparency, save for RENDER which doesn't really suite our needs.  We need
to do the compositing by hand which causes us to round-trip the X server;
reading back the background, compositing, then writing the result.

We're keeping an eye on the development of X extensions that hopefully we
can use in the future.  For now, the best advice we can give is to get a
faster network.  :-)