497837 - Scaling <video> element causes bars on left and top of video

Status: VERIFIED WORKSFORME

(Core :: Audio/Video, defect)

Description

[Jan Gerber]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090609 Minefield/3.6a1pre
Build Identifier: 

Scaling <video> element causes bars on left and top of video

in recent versions of mozilla-central and mozilla-1.9.1 nightlies
scaled video elements get a nasty border on left and top of the video.
this shows up on linux 32bit. 

it does not happen for builds from and before 20090602 on linux 32 

Reproducible: Always

Comment 1

[Matthew Gregan [:kinetik]]

I can reproduce this easily using the linked testcase.  The dark bars are visible when scaling down, but not when scaling up.  Changing nsMediaDecoder to paint with EXTEND_PAD resolves the issue, but the performance is poor, which is why we switched to EXTEND_NONE on Linux in bug 474748.

Not sure what changed around 2009-06-02 that made this so visible.  I can't see anything obvious in the regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-05-31&enddate=2009-06-03

Comment 2

[Matthew Gregan [:kinetik]]

An old build from 2009-05-29 still shows this, so I verified the regression range and found it was: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2009-05-12&enddate=2009-05-13

Note that this is the range in which the bars are black and very visible.  In earlier builds (after bug 474748 landed), the bars are only slightly visible because they're close to the color of the surrounding video.

Comment 3

[Matthew Gregan [:kinetik]]

From that regression range, and verified by modifying nsMediaDecoder and rebuilding, Jeff's patch from bug 487305 to use an RGB24 surface instead of an ARGB32 surface is what made the scaling artifacts to become so visible.

Comment 4

[Joe Drew (not getting mail)]

This might be impossible to fix unless we can move to EXTEND_PAD. :(

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Oh, so moving from ARGB32 to RGB24 means that instead of sampling transparent pixels outside the image, we're now sampling black pixels?

Comment 6

[Karl Tomlinson (:karlt)]

(In reply to comment #5)
> Oh, so moving from ARGB32 to RGB24 means that instead of sampling transparent
> pixels outside the image, we're now sampling black pixels?

Only with operator-source, I hope.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

WFM on:

Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110121 Firefox/4.0b10pre
Mozilla/5.0 (X11; Linux i686; rv:2.0b11pre) Gecko/20110126 Firefox/4.0b11pre

Can we resolve this WFM?

Comment 8

[Karl Tomlinson (:karlt)]

Attachment: uninitialized pixels snapshot

The left and top look fine to me, but i see uninitialized pixels on the right edge.  These change while resizing the browser window.

Comment 9

[Karl Tomlinson (:karlt)]

I can't reproduce with tigervnc's software framebuffer, so that is likely a driver/hardware issue, and so WFM seems appropriate.

Comment 10

[Karl Tomlinson (:karlt)]

For the record, the driver was xf86-video-ati-6.13.2 with an r500 card.

Comment 11

[Chris Pearce [:cpearce (Not reading bugmail)]]

Alrighty then, unless we hear otherwise, WFM.