- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Thu, 24 Apr 2014 17:54:22 -0400
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 24/04/2014 3:57 PM, Martin Thomson wrote: > On 24 April 2014 12:15, cowwoc <cowwoc@bbs.darktech.org> wrote: >> Something doesn't make sense here. If Alice is really sharing a specific >> application, no other processes cannot overlap its painting area. On the >> other hand, if Alice is sharing her entire desktop, I'd expect Bob to see >> the contents of the IM. > > Aside from the double negative here, I think that you are confusing > two separate things. Agreed. That was a very confusing typo :) > In the whole-screen sharing context, yes, everything is seen, warts and all. > > In the application sharing context, that application is all that is > shared. If something causes that application to be occluded, the > occluded area needs to be either frozen or greyed. To show the thing > that is doing the occluding is an over-share, which violates user > expectations. To continue to show the occluded content means that > there is something that is shared that the user is unaware of, > violating another expectation. > > This is talking about the latter. Yes, it turns out I was wrong. I thought that on Windows you could use ALT+PrintScreen to capture a window's surface area even if it was occluded and the IM wouldn't show up. It doesn't look like that is the case. It seems kind of odd though. Isn't there a Windows API to capture pixels directly from a window's surface area (as opposed to the rendered result on the screen)? Gili
Received on Thursday, 24 April 2014 21:55:10 UTC