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

[Pekka Paalanen]

On Tue, 10 Jan 2012 13:26:13 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> 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.

Yeah, good point. Could also make this a compositor setting, defaulting
to fill. We don't have to specify the exact method in the protocol,
since it's "don't care".

> > "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?

Black borders, yes. IMHO, if an application does not want the black
borders that result from aspect-preserving scaling, it should choose a
buffer size with the output's aspect ratio in the first place. The
output's size it already knows from the configure event sent as a reply
to the set_fullscreen request.

Do you know of a case where this is not feasible?

> > "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".

Yeah, I forgot to note about the name. How about "driver"?
"surface scaling mode = driver" would refer to as the video driver
doing the scaling, which is usually achieved by switching a video mode.

"fast" crossed my mind, too. Maybe "fast" is more intuitive.

For comparison, the other modes, "scale" and "fill", imply "do not
touch the video driver if the user may notice".

> 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).

You add the mention of a fast scale factor as a possibility, good.

> 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.

Do we really need to define that? I guess that is a sane choice, since
downscaling loses information.


Thanks,
pq