[protocol PATCH v2 1/2] add parameters for set_fullscreen
spitzak at gmail.com
Tue Jan 10 13:26:13 PST 2012
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?)
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"
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.
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.
More information about the wayland-devel