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

[Juan Zhao]

On Wed, 2012-01-11 at 10:10 +0200, Pekka Paalanen wrote:
> "None" means no need for the compositor to do any work here,  it is
> useful 
> > in case that client want to re-layout  his UI components to
> fullscreen. 
> > Re-layout means rearrange the contents of that client other than
> scaling.
> > 
> > For example, the current terminal demo code. It does the fullscreen
> > itself.  
> > Another example, when set the video window to fullscreen, the
> detailed
> > operation can be decided by video app, and no need for the
> compositor to
> > scale or change mode. For example, the scaling from 720X576 to
> 1024X768
> > of a video data is handled by video driver. When they set
> fullscreen,
> > they do not hope compositor to do anything. The video driver can
> make
> > the decision how to scale it.
> 
> Sorry, I do not see your point.
sorry for not expressing well. :)
> 
> In my view, "none" mode as you define it is implicit, and therefore no
> need to specify it in the protocol. Consider the following:
> 
> 1. client creates a surface
> 2. client sends the request set_fullscreen, and enters its event loop,
>         not rendering anything yet
> 3. client receives a configure event, which was triggered by the
>         set_fullscreen request
> 4. client chooses to use the exact size from the configure event, and
>         creates a buffer with that
> 5. client renders the content to the buffer
> 6. client attaches the buffer to the surface to show it.
> 
> That is the basic flow of communication for any surface that
> starts out as fullscreen or maximised. 
really, very good description for the communication. :)

> I think it would also apply for
> the case where a normal surface changes to fullscreen or maximised, in
> which case you just ignore step 1.
Yeah.

> 
> For fullscreen, the compositor has chosen an output, and sends the
> output's size in the configure event. If the client uses that size,
> the scaling mode is completely irrelevant, since the buffer has the
> matching size. That is the "none" case.
good point, we can add it in a compositor side.

> 
> The scaling modes apply only to the case, where the client decides to
> attach a buffer of different size than what the compositor suggests
> (which is the size of the assigned output).
> 
> The configure event is just a hint, an application can be
> well-behaving
> even if it does not exactly follow the configure data. That is how we
> are supposed to implement integer-cell resizing (what was the proper
> term for this?), the client rounding the size to the nearest integer
> multiple of a character size (think about terminals), for example.
in the shell side, send a configure event to the client, to provide the
correct size.
when painting, scale it or change mode when the surface size does not
match the assigned output?
> 
> > For your concern, I think we can add one "auto" to give the decision
> of
> > choosing one for the compositor.
> 
> Yes, that would be nice. It allows to have a default scaling mode
> in the compositor, which then gets used by applications which do not
> have a real preference (usually because they honour the size from the
> configure events, in which case no scaling is performed).
> 
> Ok, so "auto" does sort of match your "none" in most of the
> practical use cases, I would just change the semantics a bit.
No, your comments make sense, and can also resolve my previous concern.
Thank you so much!
> 
> Should we call it "default" mode?
No problem.


Thanks, 
Juan
>