Bugzilla

Alrighty, I've finally had a chance to investigate this project.

As Christian pointed out to me, we already have [infrastructure to handle occlusion events](https://searchfox.org/mozilla-central/rev/97b93cd3205023061d454cf4a270a7e66127310b/widget/nsIWidgetListener.h#123) in Firefox - It's just that only Mac OS X actually fires them. So the effort here is generating these events when we're occluded on Windows.

I also tried the DXGI call Aaron talked about in Comment 1, and I agree that it seems like it doesn't report a lot of things, and it's not super-obvious why. This is probably why Chromium does it a different way.

I've had a chance to *really* go through the Chromium code and understand how it works and how difficult it would be to adapt to Firefox. Their description of it is a solid read, but to summarize:

At a high level it's mostly about installing Win32 global event hooks to monitor all the windows in the system for when they move/size/minimize/maximize/hide/show and periodically scheduling "occlusion checks" any time these things happen. (Chromium does these a maximum of every 16ms to avoid doing them more often than the user will be able to actually perceive).

An "occlusion check" is more-or-less just walking through all the windows from front-to-back and tracking the rectangles of the windows you've seen**. If you get to a window you care about and it's completely contained in the region of rectangles you've seen, it's occluded.

(Of course, the devil is in the details about what windows are able to occlude other windows, what windows are being checked, and managing the hooks and checks so you're not doing unnecessary work. A lot of the Chromium code is dealing with those issues. They also do the major calculations in a separate thread to keep it off the UI thread. I think we'd want to do the same.)

Overall though, it's not super-complex, but there's still a fair amount of parts to it. I'd estimate that it would take me about 4 weeks to write the code and have it working, and then a couple more weeks to test, document, debug, review, and polish the code up. So I'd say 6 weeks, but I tend to underestimate things a bit though, so to err on the side of caution maybe 7 or 8 weeks all-in. 

Does that seem in the ballpark of what you expected?

** Technically, it's done in a negative-sense. You actually start off with the entire screen being the "unoccluded region" and subtract rectangles of occluding windows

Alrighty, I've finally had a chance to investigate this project.

As Christian pointed out to me, we already have [infrastructure to handle occlusion events](https://searchfox.org/mozilla-central/rev/97b93cd3205023061d454cf4a270a7e66127310b/widget/nsIWidgetListener.h#123) in Firefox - It's just that only Mac OS X actually fires them. So the effort here is generating these events when we're occluded on Windows.

I also tried the DXGI call Aaron talked about in Comment 1, and I agree that it seems like it doesn't report a lot of things, and it's not super-obvious why. This is probably why Chromium does it a different way.

I've had a chance to *really* go through the Chromium code and understand how it works and how difficult it would be to adapt to Firefox. Their description of it is a solid read, but to summarize:

At a high level it's mostly about installing Win32 global event hooks to monitor all the windows in the system for when they move/size/minimize/maximize/hide/show and periodically scheduling "occlusion checks" any time these things happen. (Chromium does these spaced out by at-least 16ms to avoid doing them more often than the user will be able to actually perceive).

An "occlusion check" is more-or-less just walking through all the windows from front-to-back and tracking the rectangles of the windows you've seen**. If you get to a window you care about and it's completely contained in the region of rectangles you've seen, it's occluded.

(Of course, the devil is in the details about what windows are able to occlude other windows, what windows are being checked, and managing the hooks and checks so you're not doing unnecessary work. A lot of the Chromium code is dealing with those issues. They also do the major calculations in a separate thread to keep it off the UI thread. I think we'd want to do the same.)

Overall though, it's not super-complex, but there's still a fair amount of parts to it. I'd estimate that it would take me about 4 weeks to write the code and have it working, and then a couple more weeks to test, document, debug, review, and polish the code up. So I'd say 6 weeks, but I tend to underestimate things a bit though, so to err on the side of caution maybe 7 or 8 weeks all-in. 

Does that seem in the ballpark of what you expected?

** Technically, it's done in a negative-sense. You actually start off with the entire screen being the "unoccluded region" and subtract rectangles of occluding windows