Gaps appear in gif images when not using back buffer on OS X

VERIFIED FIXED in mozilla1.2beta

Status

()

P1
major
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: chrispetersen, Assigned: sfraser_bugs)

Tracking

(4 keywords)

Trunk
mozilla1.2beta
PowerPC
macOS
regression, testcase, top100, topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt1] [ETA 09/23], URL)

Attachments

(9 attachments, 3 obsolete attachments)

(Reporter)

Description

17 years ago
Build: 2002-04-12-08
Platform: OS X
Expected Results: Maximizing window should not cause painting issue with some of
the gif images.

What I got:
When the window is maximized (so no horizontal scrollbar is present), gaps
appear in the some of the gif images. I first thought this was a dup of
http://bugzilla.mozilla.org/show_bug.cgi?id=93170. 

However, no embedded content like flash, QT, or applets are present on this
page. Also, this is a regression starting with the 2002-04-12-08 build since it
works fine with the 2002-04-12-03 build.
(Reporter)

Updated

17 years ago
Keywords: nsbeta1, regression
Priority: -- → P2
(Reporter)

Updated

17 years ago
Keywords: top100
(Reporter)

Comment 1

17 years ago
This problem seems to only occur under Millions of color video setting. 
(Reporter)

Comment 2

17 years ago
Created attachment 79070 [details]
screenshot of problem

Three images on page should this problem.

Comment 3

17 years ago
Didn't pav land some image code about the time this regressed?  I could swear I
saw chatter about this on IRC but I wasn't logging so I can't go back and verify.

Comment 4

17 years ago
BTW, Chris, is this a trunk or Moz1.0 branch build?

Being an equal opportunity finger pointer I'll also mention the trunk build on
this date would have pink's change to always turn off double buffering whenever
running on Mac OS X.  That makes me suspect this _is_ related to #93170 as we
would previously also turn off double buffering for pages that contained a plugin.

Comment 5

17 years ago
Sho'nuff, it was pink's checkin that exposed this (sorry pav).  This means 93170
isn't a plug-in problem, it's a problem with images in general when double
buffering is turned off on Mac OS X and we're in millions of colors mode.
Summary: Gaps appear in gif images when browser window is maximized → Gaps appear in gif images when not using back buffer on OS X
(Reporter)

Comment 6

17 years ago
I have a branch build from April 11th (2002-04-11-17) which doesn't seem to have
this problem. The trunk builds (2002-04-12-08) and (2002-04-13-08) have
displayed this issue as described.

Comment 7

17 years ago
Interesting....turning off double buffering causes these gaps...that explains
why pages with plugins were seeing this.
(Assignee)

Comment 8

17 years ago
I'll take this.
Assignee: attinasi → sfraser
Target Milestone: --- → mozilla1.1alpha
(Assignee)

Comment 9

17 years ago
Created attachment 79294 [details]
Testcase: a page with an image and an <iframe>

This problem only happens when there is an <iframe> (or possibly some other
element that has its own widget) on the page. That's why it doesn't happen on
every page with just images.
(Assignee)

Comment 10

17 years ago
Created attachment 79296 [details]
Testcase with transparent and animated GIF

This testcase shows that image transparency matters, and that non-transparent
animated images are also messed up.
(Assignee)

Comment 11

17 years ago
Created attachment 79340 [details] [diff] [review]
nsImageMac patch

This patch works around the bug, which appears to be an OS bug, by passing the
current clip region to CopyDeepMask, and forwarding all masked-image draws
through CopyDeepMask. We have do to this because CopyMask exhibits the bug, but
does not take a maskRgn parameter that we can use to work around it.
Performance should be roughly the same.

I also put in some const goodness in the CopyBitsWithMask() method so that the
params match those taken by CopyBits/CopyDeepMask, and left some useful
debugging code #if 0'd in.
Comment on attachment 79340 [details] [diff] [review]
nsImageMac patch

r=pink
Attachment #79340 - Flags: review+

Comment 13

17 years ago
*** Bug 93170 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
Comment on attachment 79340 [details] [diff] [review]
nsImageMac patch

sr=beard
Excellent work.
Attachment #79340 - Flags: superreview+
(Assignee)

Comment 15

17 years ago
Fix checked into the trunk. Want this on the branch too.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Keywords: adt1.0.0
Resolution: --- → FIXED
Whiteboard: [ADT1]

Comment 16

17 years ago
chris, can you test this on the trunk and update the bug with your results?
(Reporter)

Comment 17

17 years ago
With the April 17th build (2002-04-17-03), the test cases render correctly
without gaps. But I now I see other issues at netscape.com. Some of the animated
gif banner ads only are drawn partially. 
(Reporter)

Comment 18

17 years ago
Created attachment 79636 [details]
screen shot of animated gif issue

Only portion of animated gif is painted

Comment 19

17 years ago
Please address the regression before we consider this for approval on the branch.
(Reporter)

Comment 20

17 years ago
After further testing using April 17th (2002-04-17-03) , I still see the gap
issue on gifs. However problem appears to be more random than before and can be
fixed by resizing window.

Our netscape site can should the gap when doing the following steps:

* First, delete cache so that the images are read from disk

1) Launch app and go to www.netscape.com
2) Notice house picture under Business/Finance section renders without gap
3) Now, open Mail window so that browser window is no longer top -most window
4) After mail window is opened, close it.
5) The house image on page now appears with gap (at least for me).
6) Resizing window with fix problem though.
(Reporter)

Comment 21

17 years ago
I'm also seeing this randomly with site's using plugins too of course..

http://www.shockwave.com/sw/games/
(Assignee)

Comment 22

17 years ago
Problems with fix, reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Removing adt1.0.0 as there were problems with the fix, and this bug was reopned
for the trunk. This is a good one to fix though, and we'd like it before Friday
(if possible). Pls add your best estimate on when this can be fixed to Status
Whiteboard.
Keywords: adt1.0.0
Whiteboard: [ADT1] → [ADT1] [ETA Needed]
(Assignee)

Comment 24

17 years ago
Created attachment 79901 [details] [diff] [review]
New patch fixes animated GIFs issue

The reason this regressed is that CopyBitsWithMask(), which I changed, is also
called for animated GIFs to copy between frames (when you don't want any
clipping). This patch conditionalizes the previous patch to only apply when
we're drawing to the window (when we need it), not to another image. I've
surfed around with this patch, and didn't see any image problems.
Attachment #79340 - Attachment is obsolete: true
(Assignee)

Comment 25

17 years ago
Created attachment 80078 [details] [diff] [review]
New version of patch fixes scoping problem.

Pinkerton tested the previous patch, and said that everything looked good. This
version is the same, but fixes an issue with scoping the StRegionFromPool.
Attachment #79901 - Attachment is obsolete: true
Comment on attachment 80078 [details] [diff] [review]
New version of patch fixes scoping problem.

r=pink, as promised.
Attachment #80078 - Flags: review+

Comment 27

17 years ago
Comment on attachment 80078 [details] [diff] [review]
New version of patch fixes scoping problem.

sr=beard
Attachment #80078 - Flags: superreview+
(Assignee)

Comment 28

17 years ago
Patch checked in on the trunk. Putting adt1.0.0 for branch consideration, and
reassigning to pinkerton, because I'm going on sabbatical (sorry pink).
Assignee: sfraser → pinkerton
Status: REOPENED → NEW
Keywords: adt1.0.0
Whiteboard: [ADT1] [ETA Needed] → [ADT1]
(Assignee)

Comment 29

17 years ago
Now marking fixed.
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
Keywords: nsbeta1 → nsbeta1+
(Reporter)

Comment 30

17 years ago
Wonderful ! This hideous bug is now fixed ... Marking verified on OS X trunk
(2002-04-22-03). Thanks , Simon !!
Status: RESOLVED → VERIFIED
(Reporter)

Comment 31

17 years ago
Oops. Maybe this isn't quiet fixed like I thought. All of my tests worked fine
though. However, I still see problem with the image (under business and finance)
when sidebar opens.

In millions of colors, 

1) Go to netscape.com 

2) Open the sidebar.

3) Notice gap on this image (under business and finance).


(Reporter)

Comment 32

17 years ago
Reopening for now.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 33

17 years ago
Same problem with top gif logo on this page (whichs uses an applet). Opening
sidebar displays gap.


http://pbskids.org/jayjay/colr.paintbox.herky.html
does this only happen in millions of colors? if so, it's an os bug and the patch
at least fixes a bunch of cases, so we should take it.

if it also happens in thousands, we should dig more.
(Reporter)

Comment 35

17 years ago
This problem doesn't occur in thousands, only millions. I agree that the fix
does resolve the tests I checked. I was just surprised to see it again when
opening the sidebar. Re-sizing the window does paint the image correctly. Maybe
there should be something mentioned in the read me documentation. 
(Reporter)

Comment 36

17 years ago
I see this problem at http://autotrader.com/. Simply by placing focus in the
select menu causes gaps in numerous images on page. Tested with build 2002-04-22-03.
cc'ing some other mac folk.

simon and i think that the patch, as is, is still a big improvement and deserves
to go onto the branch. if there are still some lingering edge-cases that freak
out only in millions of colors, they shouldn't hold back a patch that fixes 95%.
As far as we can tell, this is an OS bug that (reportedly) has been addressed
for an upcoming version of MacOS X by apple.

I say fixed, let's get this on the branch.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 38

17 years ago
Ok, that's reasonable since this issue is in a milder form now. I would like to
recommend adding this to the read me notes. Marking verified in the OS X April
22 trunk (2002-04-22-03) build. Tested under OS X 10.1.4.
Status: RESOLVED → VERIFIED

Comment 40

17 years ago
adding adt1.0.0+.  Please check this into the branch as soon as possible and add
the fixed1.0.0 keyword.  Please open a bug for the remaining issues.
Keywords: adt1.0.0 → adt1.0.0+
landed on branch.

i still see issues with images when clicking in form controls, but oh well.
Keywords: adt1.0.0+ → fixed1.0.0

Comment 42

17 years ago
*** Bug 139486 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 43

17 years ago
Verified on OS X 2002-04-26-05 branch. Tested under OS X 10.1.4 in millions of
colors.
Keywords: verified1.0.0

Comment 44

17 years ago
*** Bug 141658 has been marked as a duplicate of this bug. ***

Comment 45

17 years ago
*** Bug 139486 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 46

17 years ago
*** Bug 142691 has been marked as a duplicate of this bug. ***

Comment 47

17 years ago
Reopening since bug 142691, just duplicated to this one, was confirmed against
FizzillaCFM/2002061014.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Reporter)

Updated

17 years ago
Keywords: testcase

Comment 48

17 years ago
Still happens frequently when using 1.1 to access <http://www.bayarea.com/>.

Comment 49

17 years ago
Re: comment 37, what was the OS X version that fixes this bug?

Comment 50

17 years ago
I believe the implication from Apple was that it would be fixed in Jaguar.
Removing, verified1.0.0, as this bug has been reopened.
Keywords: fixed1.0.0, verified1.0.0
Whiteboard: [ADT1] → [ADT1] [ETA Needed]
(Assignee)

Comment 52

17 years ago
Can we get a screenshot from 10.2 with a recent build?
petersen: can you pls verify that this is fixed when using jaguar? thanks!
(Reporter)

Comment 54

17 years ago
Yes, this problem is still occuring in 10.2.1 and 10.2 running in million of
colors (video setting). Autotrader.com is one of the sites where I still see
this problem.

http://autotrader.com/

Go to url and place focus on the Select make menu. Gaps should appear on the
various images on the page.
(Reporter)

Comment 55

17 years ago
Tested with the 2002-09-19-05 trunk under 10.2 and 10.2.1. 
(Reporter)

Comment 56

17 years ago
Created attachment 99853 [details]
Screen shot of autotrader.com (with gaps)
(Reporter)

Comment 57

17 years ago
Another site that shows this problem was http://www.tvguide.com/. This page uses
a flash based ad which is probably triggering the problem.
(Reporter)

Comment 58

17 years ago
Created attachment 99855 [details]
Screen shot of  TV guide
(Reporter)

Comment 59

17 years ago
Comment 54 should have mentioned the following:

Clicking on the Select Make field will display it's popup menu. Notice now that
some of the images on the page appears with a gap.

Comment 60

17 years ago
Nominating this to edt1.0.2.

I can reproduce this in www.aol.de with embedding product on MacOS X 10.1.5 and
10.2.  When I go to www.aol.de, "Community" "Shopping" or other words are
truncated. I tried this with Netscape 7.0 and PPembed build, but I have not been
able to reproduce this.  

However, I could reproduce this in www.tvguilde.com with Netscape branch build. 
Keywords: edt1.0.2, topembed
Removing edt1.0.2, as their is no patch to evaluate for checkin approval to the
1.0 branch. Adding topembed+ as this is an issue for a major embedding customer.
Blocks: 150046
Keywords: edt1.0.2, topembed → topembed+
Priority: P2 → P1
Whiteboard: [ADT1] [ETA Needed] → [adt1] [ETA Needed]
Target Milestone: mozilla1.1alpha → mozilla1.2beta
(Assignee)

Comment 63

17 years ago
This bug happens when there are plugins, or an <iframe>, on the page. I'm trying
to get a reduced testcase that shows the problem. I've found that behaviour
differs between mozilla and PPEmebed; it only shows up in Mozilla when the
browser window status bar is visible (go figga). It has to do with clipping in
the destination port when the image is redrawn.
(Assignee)

Comment 64

17 years ago
Created attachment 99942 [details] [diff] [review]
nsImageMac patch that fixes the bug.

Some analysis suggests that the bug (which is an OS bug in CopyDeepMask)
happens when the clip region of the destination port is complex (possible
having 'holes' in). This patch works around the bug by temporarily setting the
port clip region to the intersection of the the original clip region, and the
destination rectangle of the the image being drawn. This fixes the bug in the
test cases that I've tried.
Attachment #80078 - Attachment is obsolete: true

Comment 65

17 years ago
Comment on attachment 99942 [details] [diff] [review]
nsImageMac patch that fixes the bug.

r=sdagley (sure, regions _sound_ like a good idea... :-)
Attachment #99942 - Flags: review+

Updated

17 years ago
Attachment #99942 - Flags: superreview+

Comment 66

17 years ago
Comment on attachment 99942 [details] [diff] [review]
nsImageMac patch that fixes the bug.

sr=scc
Nominating as adt1.0.2, as this is a very issue on a top100 site.
Keywords: adt1.0.2, approval, mozilla1.0.2
Whiteboard: [adt1] [ETA Needed] → [adt1] [ETA 09/21]
um ... meant "very visible issue".
(Assignee)

Comment 69

17 years ago
Taking.
Assignee: pinkerton → sfraser
Status: REOPENED → NEW
(Assignee)

Comment 70

17 years ago
Fix checked in to the trunk.
petersen: can you pls verify this as fixed on tomorrow's trunk builds? thanks!

Comment 72

17 years ago
A bit late, but just for completeness:The description of Vantive 318061 is
following.

- start an fresh installed client
- Sign on
- open www.aol.de

*** Result
the site is not displayed correctly => The icons for "eMail", "SMS", "Boards"
and "Die Woche" are truncated and some captions are incomplete e.g. "community"
below the icons.
If you close and open the site several times, the site will be displayed
properly till you empty the browser cache.

*** Expected
the site should be always displayed properly
(Assignee)

Comment 73

17 years ago
Fixed on the trunk; fix is in the 20020920 build.
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 74

17 years ago
With the 2002-09-20-08 OS X trunk build, I can't reproduce the problem on the
site's mentioned (autotrader.com ,tvguide.com) earlier. I no longer see this
problem on other sites like espn.com too. Tested with 10.2.1 under Millions of
Colors video setting. Thanks Simon !!
Status: RESOLVED → VERIFIED
(Assignee)

Comment 75

17 years ago
The patch actually may cause some over-drawing of images; I missed interesecting
the clip region, and the image bounds. I'll have to redo the fix.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 76

17 years ago
Created attachment 100004 [details] [diff] [review]
Better fix that intersects with existing clip region
Attachment #99942 - Attachment is obsolete: true
Comment on attachment 100004 [details] [diff] [review]
Better fix that intersects with existing clip region

r=pink.
Attachment #100004 - Flags: review+

Comment 78

17 years ago
Comment on attachment 100004 [details] [diff] [review]
Better fix that intersects with existing clip region

sr=beard (good find)
Attachment #100004 - Flags: superreview+
(Assignee)

Comment 79

17 years ago
Patch checked in, with feeling.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 80

17 years ago
Marking verified in the 2002-09-23-08 OS X build.
Status: RESOLVED → VERIFIED
Comment on attachment 99942 [details] [diff] [review]
nsImageMac patch that fixes the bug.

This isn't obsolete; the later patch depends on this one.

a=rjesup@wgate.com for 1.0 branch; change mozilla1.0.2+ to fixed1.0.2 when
checked in.  Please check in both related patches.
Attachment #99942 - Attachment is obsolete: false
Attachment #99942 - Flags: approval+
Attachment #100004 - Flags: approval+
Keywords: approval, mozilla1.0.2 → mozilla1.0.2+
adt+ for the branch.
Keywords: adt1.0.2 → adt1.0.2+
(Assignee)

Comment 83

17 years ago
Paches checked into the mozilla 1.0 branch.
Keywords: adt1.0.2+, mozilla1.0.2+ → adt1.0.2, fixed1.0.2
Marking as a adt1.0.2+ per Comment #82 From dveditz@netscape.com.

petersen: can you pls verify this as fixed on the 1.0 branch, then replace
"fixed1.0.2" with "verified1.0.2"? thanks!
Keywords: adt1.0.2 → adt1.0.2+
Whiteboard: [adt1] [ETA 09/21] → [adt1] [ETA 09/23]
(Reporter)

Comment 85

17 years ago
Verified on 2002-09-24-08 branch
Keywords: fixed1.0.2 → verified1.0.2

Updated

17 years ago
No longer blocks: 150046
You need to log in before you can comment on or make changes to this bug.