210554 - After extensive viewing of images larger than screen size, images sometimes stop being painted.

Status: RESOLVED WORKSFORME

(Core Graveyard :: Image: Painting, defect)

Description

[Sam Little]

User-Agent:       Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4) Gecko/20030616
Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.4) Gecko/20030616

This is probably OS/2-specific, and I haven't completely determined the
conditions, so this may be a little convoluted....

Occasionally when surfing through large photo galleries for an extended period
of time (using Tabbed Browsing to load and navigate through multiple images),
large images embedded in HTML pages will stop being painted on-screen. Smaller
images continue to be displayed.

I can sometimes get pieces of the image to be rendered by placing or dragging a
dialog box over pieces of the image (and sometimes it erases parts of the image,
perhaps depending on whether more or less than half the image is covered by the
floating dialog box).

Exiting Mozilla solves the problem. I can save a tab group of "invisible"
images, exit Mozilla, restart and load the tab group without incident. This has
become more frequent under 1.4RC1 and 1.4RC2, but had happened once or twice
with earlier versions.


Reproducible: Sometimes

Steps to Reproduce:
1. If I can find a way to reproduce fairly consistently, I'll let you know....
2.
3.




Since I suspect this is OS/2-specific, system is eComStation 1.0 (OS/2 v4.51 CSD
Level XR04501, Generic SVGA w/GRADD (not SciTech).

Comment 1

[Jim Dunn]

hmmm, sounds similar to other reported windows image painting bugs where
GDI resources are being consumed and not freed.

Some things to try...
-does clearing your cache (Edit->Preferences->Advanced->Cache : Clear help???
-does reducing your memory cache (same as above) help?  for example
 mine is 50Meg... reducing it to 10Meg would be something to try
-When this has happened is there any way to look at systems resources 
 (I have not idea if os/2 has the concept of GDI resources).  On Windows
 we can look at the Task Manager and see GDI Objects or the amount of
 GDI resources used.  What I am wondering is if a HUGE quantity or precentage
 are being used by mozilla.
-Does disable'ing memory cache help?
 about:config
 scroll down and find browser.cache.memory.enable, click on it and
 replace "true" with "false"  (note if this does help, this is NOT
 a solution)

Depending on your answer(s) this is probably a dup of bug 203667

Comment 2

[Felix Miata]

What happens when you try what I describe at
http://bugzilla.mozilla.org/show_bug.cgi?id=100250#c25

Comment 3

[Sam Little]

Jim - 

1) Clearing cache doesn't help.
2) I'm not sure about reducing cache -- after extensive testing, I settled on
16MB. I've certainly viewed several multiples of 16MB during the session before
problems appear. 
3) Yes, I can look at memory resources. Free RAM is usually quite low by the
time this happens, but I haven't looked at what processes are using it. I'll
look next time it happens.
4) I'm trying disabled memory cache now. It was 8MB, which tends to be on the
low side.

These aren't necessarily huge image files, either. I saved a few a while back
and the JPEG files were 150KB-320KB. But all had vertical dimensions larger than
the page window and were embedded in HTML (as opposed to HREFs to JPEG files
which scale and don't have problems on their own). Show image didn't solve the
problem either, once this started to occur.

Felix - Loading that image consumed 46MB RAM, but the image displayed fine, both
enlarged and scaled. Since converting that image to an OS/2 v2.x BMP (using
PMView 2000) results in a 47MB file, this seems to be expected behavior. Now, if
the image had been embedded in an HTML page, I might expect difficulty. I may
test with that later today....

Comment 4

[Sam Little]

I have not encountered this problem since v1.5alpha. Changing to WFM now.