Slow Image Loading and Redraws

VERIFIED DUPLICATE of bug 4229

Status

Core Graveyard
Tracking
P3
normal
VERIFIED DUPLICATE of bug 4229
19 years ago
2 years ago

People

(Reporter: skamil, Assigned: Ramiro Estrugo)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Assignee: pnunn → ramiro
Status: ASSIGNED → NEW

Comment 1

19 years ago
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
(Reporter)

Comment 2

19 years ago
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
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 3

19 years ago
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 ***

Updated

19 years ago
Status: RESOLVED → VERIFIED
Target Milestone: M4

Comment 4

19 years ago
Marking Verified.

Comment 5

19 years ago
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.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.