Loading a page with a lot of images such as http://www.contaminated.net causes apprunner on Linux to slow to a crawl and not respond to any toolbar clicks or scrolls. After turning off Double Buffering, it seems that the screen is being redrawn constantly (even when an image is not visibly loading). Perhaps the status text causes the entire screen to redraw? Even if the loading image is not visible, the screen redraws. Also, it seems like even when an image is not loading the screen redraws while loading a page. I'm using the latest CVS source of apprunner (3/23/99) on a PII Redhat Linux box, kernel 2.2.3, gtk+ 1.2, XFree86.

I am caught up in getting a car pool ready to land. As soon as I get the code landed, I can dig into this. As this is on the rendering/FE side ( I handle image decoding), it might be worth reassigning to Ramiro to study the FE gtk code. He and I will have to find a solution that helps Linux without breaking Mac and Wintel. -pnunn

Upon further investigation, this seems to be a redraw issue. Viewer/Apprunner redraw like crazy, slowing everything down. Here's a post from netscape.public.mozilla.unix: So, I ran Quantify on viewer last night (Solaris 2.6, totally debug build, gcc 2.7.2.3, GTK 1.2.0, etc) Doing a run like this: start up load example 0 go to example 4 and let it load exit nsImageGTK::Draw() is called some 250 or so times. 13-14% of execution time is spent within moz_gdk_draw_bgr_image() If you count the time spent in everything called by moz_gdk_draw_bgr_image(), then you are looking at around 84-85% of total execution time. about 85% of that time is spent within gdk_draw_bgr_image(), so it isn't entirely the fault of the bit twiddling that goes on there for some platforms (like mine). Some things to consider: Can we do the bit manipulations for the platforms that need it for RGB->BGR conversions in place in the image? Should we be dithering in GTK code? Is there any dithering happening in imglib? Why are we doing the RBG->RBG conversions on every draw? Why not cache this? Are we forcing the Xlib buffers to get flushed too often (and driving up network overhead)? Pavlov reported numbers a lot higher than I saw for that test run (about 399 calls to nsImageGTK::Draw(), also running viewer). - Bruce

this bug is a dup of 4229, for which i just checked in some fixes. bruce: i tried this site and scrolling the top part is snappier with my fixes. of course the problem was not limited to the given url. thanks marking dup of 4229 *** This bug has been marked as a duplicate of 4229 ***

Marking Verified.

Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.