User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090306 Minefield/3.1b2pre ( LIKE Firefox/3.0 ) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090306 The video element shows a lot of tearing when the processor load is high. Especially the controls area seems to update out of sync with the rest of the video. Apparently, the control area is always drawn, no matter if it is currently visible or not. The clean way to fix this would be finally changing the rendering path for opacity==0 to just skip rendering, but for now it would probably be sufficient to just set the controls to visibility:hidden when the opacity approaches 0. I really think this should be fixed prior to the debut of VIDEO in the next stable release as it makes even DVD quality video pretty much unwatchable. Reproducible: Always
Curiouser and curiouser: Apparently it does set visibility:hidden, but the problem persists. Apprently visibility:hidden doesn't skip rendering either.
Tried again with display:none instead of visibility:hidden and what do you know: the issue went away. I really don't trust myself to create a patch for this, but if you guys think it will help, I'll still do it.
The fix for bug 483841 might solve this, or at least change the behaviour.
Status: UNCONFIRMED → NEW
Ever confirmed: true
FWIW, I wasn't able to reproduce this on OS X, my Linux boxes, or on Windows under VMWare. I meant to track down some real Windows hardware, but got sidetracked. I'm assuming, though, that this isn't a common problem or others would be reporting it. Perhaps it's only noticeable on older/slower systems, or certain video drivers?
I see this tearing on my dual core fast laptop running Linux. Graphics card is an ATI X1400.
My system isn't really slow either. I think the main reason people aren't reporting it is that VIDEO isn't really used on anything but tinyvid.tv which (figures) mostly has tiny vids that don't strain the processor. Specs: Vista Nvidia 7900GS Dual Core 2x1.8Ghz About OSX and Linux: Could just be that the blits are synchronized differently on different systems. Anyway, I really think we should fix this with display:none for now. It doesn't really have any drawbacks so why not?
Bug 484935 has landed on trunk, which basically sets display:none on the controls when hidden. For those of you who were seeing tearing, does this fix it? (Test after updating to tomorrow's nightly, ~12 hours from now).
It is for me.
Ok, let's call this fixed by bug 484935, then.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Depends on: 484935
Resolution: --- → FIXED
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio
You need to log in before you can comment on or make changes to this bug.