Untriaged the issue so as to triage it further.

[mac triage]

niklase@ what's your take on this?

I don't think it should be necessary, but having no constraints should give a stream with the true window resolution. Can you give us some details on how that fails? 

If you do not provide constraints, then small windows are true window resolutions, but larger windows are limited in size.

It would be great if the windows are always using true window resolution with a max specified resolution.  However, today small windows are larger than life when using large max dimensions.  This is more likely to happen on HDPI displays (such as the MacBook Pro).

Can you give a concrete example with app shared and numbers for resolution?

I am on a macbook pro 15" with Retina display.  The settings are on scaled for more space.  The resolution on the display reported: 1920x1200.

Now I make safari as small as possible (708x278) and share that.  
- If I use a max resolution of 1280x1024, then the shared video dimensions are: 1280x502

- If I use a max resolution of 1920x1200, then the shared video dimensions are: 1416x556

I am uploading 2 files.
- safari.png is a screen shot of the safari window
- test2.png is what was captured in test2.

Deleted: safari.png 65.2 KB

	safari.png 65.2 KB View Download

Deleted: test2.png 190 KB

	test2.png 190 KB View Download

These issues only appear to happen on HDPI displays (both mac and windows).  When on older non-HDPI display, it seems to work as expected.  

If you specify the correct dimensions then it works on HDPI, but since we don't know the dimensions in advance, we cannot do that.

An alternative fix would be to make this work on HDPI displays...  There are useful scenarios where knowing the dimensions of a window allows you to decide if you want to scale it and by how much (you can be more explicit about it) to get better performance and legibility.

What you see here comes from that we capture the actual screen resolution. When your window is rendered in a Retina display it's upscaled a factor 2, to 1416x556. We try to send that except when the max constraints prevents it. This is working as intended. What about the other case where you have no max and get a smaller resolution?

How will I build a screen shot application without knowing the dimensions or the scaling factor?

The other issue is that when I send the screen capture video over the network with WebRTC, the participants sees it in the extra large video.  How would I solve that?

niklase: Any response to #14 or can we loop in somebody else?

Not sure what #14 is about. You can make the play <video> any size you want to.

Since it is a desktop share, the video is of an application and users expects to see the application video at the original resolution and not larger than life.  This makes it more readable and application windows are not unexpected sizes to users.

Since I have no idea if the video is scaled larger, I cannot reduce it in size for the users... if you give me some indication I can do that.  (even though sending larger video, would still use more bandwidth than needed and slow down application sharing).

Also, when I do a screenshot application, users expect the screenshot to be the exact size that they see.  When I let them email the screen shot, it is twice as big as it should be.

friksa@ I think it would be easiest if you can create a minimal reproduction case and put it up at https://jsfiddle.net/ to showcase when you think the size of the captured images are incorrect and/or width+height information is missing. Then we can try it on a regular density display and a HDPI one.

@niklase already explained that Chrome captures the video at the native screen resolution.  That is exactly the issue on HDPI displays.  

When you build a screen shot application and you take a screen shot at the native HDPI resolution, then you show it in the browser or save it to a PNG, it is 1.5x bigger than what the user expects.

The same is true for video when doing screen sharing or record the screen.

It didn't make it into M55 so moving to M56.

Thanks so much!!

Since @niklase clarified that the capture on HDPI displays are done at the native resolution, we also need to know the scaling factor so that the dimensions can be translated. Otherwise we will not know how much smaller it should be made to look life-size to the user.

friksa@ #22 is confusing, is there still something 
that needs to be done for this issue?

The API callback should include the dimensions of the video and the scaling factor used.  On non-hdpi displays, the scaling will be 1.  On HDPI displays, it might be 1.5 or 2.

Please take a look at the images I posted in #10.

Bumping to M57. Please update if that's wrong.

Bumping this to M58. Please correct if that's wrong.

Cleaning up sheriffbot label "Needs-Review" label as a part of modified "Needs-Feedback" sheriffbot rule. [ref bug for cleanup 684919]

Bumping to M60. Please correct if that's wrong.

This should be discussed here:https://w3c.github.io/mediacapture-screen-share/, not in a chrome bug.