Closed
Bug 3958
Opened 26 years ago
Closed 25 years ago
[PP] Animation on throbber slow to load, doesn't show up sometimes
Categories
(Core Graveyard :: Tracking, defect, P3)
Tracking
(Not tracked)
M14
People
(Reporter: mikepinkerton, Assigned: pnunn)
References
Details
(Whiteboard: [Perf])
We use two gifs for the throbber, a static one for when the browser isn't busy
and an animated gif for when it is. The static gif displays fine, no problems.
When you go to a webpage, we switch over to the animated gif. However, it takes a
long time to image and a blank square is drawn in its place. If the page loads
quickly enough, you never even get to see the animated gif finish imaging once
and so the throbber appears and disappears as you surf. For long pages, there is
enough time to render the animated gif so you see it.
This is all platforms, but linux is affected the most. It seems to take the
longest to render there so you almost never get to see it animating.
Nothing is "broken" per se, it just looks bad. really bad.
Re-assigned to dp@netscape.com.
dp, this looks like a netlib or imagelib issue.
Updated•26 years ago
|
Target Milestone: M4 → M5
Comment 2•26 years ago
|
||
Looks bad is ok for M5. This does not effect functionality.
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Comment 3•26 years ago
|
||
this seems to be working ok on windows.
can we get the other platforms rechecked and re-open as [PP]
bug if linux or mac are still struggling to do the right thing...
Reporter | ||
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Updated•26 years ago
|
Resolution: FIXED → ---
Summary: Animation on throbber slow to load, doesn't show up sometimes → [PP] Animation on throbber slow to load, doesn't show up sometimes
Reporter | ||
Comment 4•26 years ago
|
||
clearing sar from list, replacing with cyeh (i guess)
Whoa, whoa, whoa. Since when do we mark a bug as resolved when looks ok on
Win32??? Sure, annotate that it looks ok on win32, but don't resolve it so that
it drops off our radar! Shame on you.
Reopening bug as macos does this still.
Reporter | ||
Comment 5•26 years ago
|
||
Marking as PP, clearing resolution.
Updated•26 years ago
|
Target Milestone: M5 → M6
Updated•26 years ago
|
Assignee: dp → pnunn
Status: REOPENED → NEW
Comment 6•26 years ago
|
||
Pam could you investigate this one.
??
Sounds to me like the problem is when the throbber image is
requested, which is more of a chrome/widget thing than an
image thing. The problem is not decoding the image, but when
the image request is issued.
The known Netlib/imagelib problem in which netlib checks with
the server for the lastmodifieddate on the image could slow
things down alittle. But this can't be addressed until Necko
lands.
I could mark this as a dupe of the bug I have for that problem.
Pink, are you still unhappy with the display here?
-pn
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Reporter | ||
Updated•26 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Updated•26 years ago
|
Resolution: FIXED → ---
Reporter | ||
Comment 9•26 years ago
|
||
sorry, pam. reopening (i should have read that last report more carefully, but i
don't think i ever saw it, maybe a mail burp).
Since the throbber image is local, there isn't a server for the external
requests. I just verified that it still does this on today's build 5/14/99.
What do you mean about it being when the request is issued?
Reporter | ||
Comment 10•26 years ago
|
||
clearing resolution
Reporter | ||
Comment 11•26 years ago
|
||
adding sfraser and radha to the bug.
Assignee | ||
Comment 12•26 years ago
|
||
I'm pushing this out to M7.
After a discussion with pinkerton, a very probable
cause is that NU_CACHE has not landed for the Mac.
Which would mean there is no cache for the mac.
Which would be bad.
-pnunn
Reporter | ||
Comment 13•26 years ago
|
||
adding gagan to the cc list.
Gagan, is it true that the mac currently has no cache? If so, where is it on
disk? Is it the old cache?
Assignee | ||
Comment 14•26 years ago
|
||
Another question: Are our fileopens slow? They were
painfully slow initially. Could this still be an issue?
-pn
Assignee | ||
Comment 15•26 years ago
|
||
*** Bug 1865 has been marked as a duplicate of this bug. ***
Updated•26 years ago
|
QA Contact: claudius → elig
Comment 16•26 years ago
|
||
Eli, I'm basically migrating you over from bug 1865. This is all you buddy. Someone want to change the componet? I'm afraid to.
Comment 17•26 years ago
|
||
Status quo sounds fine to me; thanks!
Comment 18•26 years ago
|
||
[Note to self for verification: when verifying this bug, double-check that
duplicate bug #1865 was fixed, too.]
Comment 19•26 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.
Assignee | ||
Comment 20•26 years ago
|
||
Could this be a dupe of #8645?
-pn
Assignee | ||
Comment 21•26 years ago
|
||
I need necko to land to address this properly.
-pn
Comment 22•26 years ago
|
||
*** Bug 10989 has been marked as a duplicate of this bug. ***
Comment 23•26 years ago
|
||
By the wisdom of leger@netscape.com, I append the following annotation:
(MICROSOFT WINDOWS 98 1999080212 Apprunner build)
As the start-up page is loaded (be it the MozillaZine default or a URL specified
at the command-line), the throbber gapes blankly at the user, remaining static
rather than animating.
Oh: the original bug is no longer evident to mine eyes on the cited platform
(having been all too visible), but was sealed *before* the rumble of Necko.
Comment 24•26 years ago
|
||
With the latest builds 1999080508 on Linux and Win32 and build 1999080510 on
Mac, the throbber seems to be loading a lot better, even though you still see
the blank square for a really short moment (a little longer on Linux).
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → DUPLICATE
Comment 25•25 years ago
|
||
*** This bug has been marked as a duplicate of 18738 ***
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 26•25 years ago
|
||
Rubber-stamping as duplicate. Leaving note in 18738 to verify this bug when 18738
is verified.
Comment 27•25 years ago
|
||
*** Bug 19436 has been marked as a duplicate of this bug. ***
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•