[protocol PATCH v2 1/2] add parameters for set_fullscreen

[Bill Spitzak]

Pekka Paalanen wrote:

> "none" means the application does not care what method a compositor
> uses, so the compositor would probably choose either the cheapest
> (fill? no-fill?) or the best desktop-integrated user experience (scale?)
> method.

I think the default will have to be "fill". My guess is that it is 
likely that the program expects 1:1 pixels on the screen and only "fill" 
does this.

I am assuming that if a client or wm makes a window full-screen, the 
next thing that happens is that the compositor sends a request to resize 
the surface to the size of the screen. If a client obeys then "fill" and 
"scale" are identical. If it disobeys (for instance it rounds to the 
nearest size it can handle) then I think "fill" is expected as this is 
the closest to the behavior of non-full-screen windows.

> "scale" is for preferring scaling in the compositor, the application
> really would like to fill the whole screen, even if it renders a buffer
> that is too small. The compositor might (be configured to) also switch
> the video mode, if it wants to scan out the client surface. Scaling
> would always preserve surface's aspect ratio. The surface is centered.

If the aspect ratio is preserved (which I agree is a good idea) then 
this will have black borders as well. There may be a desire to disable 
the aspect ratio preservation, which would be another mode?

> "fill" is for black borders. The application does not want other apps
> showing at all, and it does not want to be scaled, because it might
> look bad. This would be preferring 1:1 pixel mapping in the monitor
> native video mode. The surface is centered.

And I think this has to be the default.

> "force" is like "scale"...

I don't like this name, "force" implies that the scale will be exact, 
which this does not do. Maybe "fast scale".

It should act like "scale" except the window may not fill the screen and 
will have black borders on all sides. It can choose some faster/nicer 
scale factor, such as integers only. It should be able to change the 
video mode (though this means the window may change size if there are 
overlapping windows because they would prevent changing the mode).

Like scale this may need another mode to disable aspect ratio 
preservation, if users want that.

Oversize:

You need to figure out what should happen if the window is larger than 
the screen. This is likely a mistake by the client but some predictable 
result is needed. My best guess is that the window is centered at 1:1 scale.