Closed Bug 550737 Opened 16 years ago Closed 16 years ago

Applications which use Direct3D overlays cause various issues on 3.7a with D2D enabled

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: cheald, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100306 Minefield/3.7a3pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100306 Minefield/3.7a3pre In the attached screenshot, I'm using Mumble's overlay (top) (http://mumble.sourceforge.net/) and FRAPS (lower right); both programs attach an overlay to programs that acquire accelerated surfaces (generally, games). Mumble displays a list of people in a channel, and FRAPS displays your current framerate. With those on, when I scroll up and down the page, I get "ghosted" portions of the overlays that aren't repainted, and it generally ruins the entire effect of the page. The D2D acceleration is nice, but it is completely unusable with this kind of conflict. Reproducible: Always Steps to Reproduce: 1. Start up Mumble (ensure Overlay is on) or FRAPS 2. Open Firefox 3.72a with D2D acceleration on 3. Scroll up and down a page Actual Results: I get "ghosted" portions of the overlay copied up and down the page, making it unreadable. Expected Results: Ideally, the overlays should not appear. If they must appear, they should not ghost up and down the page, instead remaining in a static location as they would with any other similarly accelerated software (Flash fullscreen mode, Sony Vegas' video preview, Windows Media Player).
Additionally, it looks like there's something seriously wacky going on with the blending - in games, the overlay is alpha-blended, and the FRAPS counter is yellow with no black background. See http://i.imgur.com/NbiN3.png for a visual example.
Yeah... this is probably because they actually write to our front buffer.. This is those applications doing something they shouldn't.. not really use. That software isn't really doing the same thing, since they don't scroll. When we scroll we copy our front buffer to an intermediate surface, we then copy the part that is still in view after scrolling to the correct portion of our front buffer after scroll, this carries whatever meddled with our front buffer along. This is easily fixed by adding an intermediate buffer, but it will somewhat decrease performance. It's a trade-off and more of a design decision than anything else.
* with that software I ment Flash/Sony Vegas/Windows Media Player.
Yuck :(
You can detect when there are plugins visible and do something less efficient for that case. Just walk the child windows looking for eWindowType_plugin and check for nonempty clip rects.
(In reply to comment #5) > You can detect when there are plugins visible and do something less efficient > for that case. Just walk the child windows looking for eWindowType_plugin and > check for nonempty clip rects. FRAPS isn't a plugin, it's a third party application which attaches itsself to your surface.
OK, that is pure evil. They can just stop doing that.
(In reply to comment #7) > OK, that is pure evil. They can just stop doing that. It's kind of the business they're in :) They measure your framerate and then write it to your frontbuffer (it's a thing for gaming), and optionally record it. That's kind of what they're expected to do. Most applications just don't re-use their frontbuffer the way I do since they don't have something like scrolling.
Fine, then people can just stop using FRAPS on Gecko.
I was afraid that was going to be the answer :) I can set Mumble to ignore the Firefox frontbuffer (an empty "nooverlay" file in the same directory as the Firefox binary takes care of that). Not sure about FRAPS, though.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
I think we should not make an effort to fix this bug --- especially if the fix slows down D3D rendering for most users. However, I think this bug will be fixed as a side effect of moving to layer-based scrolling.
(In reply to comment #11) > I think we should not make an effort to fix this bug --- especially if the fix > slows down D3D rendering for most users. However, I think this bug will be > fixed as a side effect of moving to layer-based scrolling. I think you are correct :)
You need to log in before you can comment on or make changes to this bug.