4221 - Slow Image Loading and Redraws

Status: VERIFIED DUPLICATE of bug 4229

(Core Graveyard :: Tracking, defect, P3)

Description

[skamil]

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.

Comment 1

[pnunn]

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

Comment 2

[skamil]

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

Comment 3

[ramiro]

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 ***

Comment 4

[leger]

Marking Verified.

Comment 5

[leger]

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.