[PATCH weston 4/8] protocol: crop & scale RFC v3

[Bill Spitzak]

Pekka Paalanen wrote:

> You have read it right.

Okay. I really have doubts this is correct but I guess I will go along 
with it and see.

Can I suggest that it be an *error* if buffer_scale is any value other 
than 1 on a surface that the scaling extension is being used. Under the 
current design it is useless and this would allow the meaning to be 
defined in a future extension to Wayland.

> toolkits should be
> prepared to change the buffer_scale at will (window completely moves
> from HiDPI monitor to a low DPI one), so storing the scenegraph in
> buffer coordinates would be a lot of work for each change.

I don't think users that only have a high-dpi display are going to be 
really impressed with this feature.

> In other words, all GUI elements are defined in integer surface
> coordinates.

Our GUI is defined in multiples of the general font size, and this value 
can be scaled by steps of approximately 15% by the ctrl+/= shortcuts. 
All other dimensions are either linear functions of this size or they 
are done by measuring the extents of text rendered with this font. Our 
"scenegraph" has no coordinates, instead widgets are laid out more like 
word-wrapped text, by finding their size and packing them into rows and 
columns. We never use direct x/y positions or sizes of widgets. Qt 
supports this type of layout and we are using their standard container 
widgets. Even the most primitive toolkits do some layout this way, for 
instance menu items are rarely given x+y positions, but instead figured 
out from the height of all the items before them. Most toolkits support 
a word-wrapped menubar or tab bar.

Trying other software (Nuke, Maya, Blender, Photoshop, many others) and 
resizing the windows clearly shows that our approach is pretty common.

Multiplying the font size by the output_scale is trivial and is how I 
would scale our gui. There are no other numbers to change. All you have 
done is thrown in a monkey wrench in that the code needs to be fixed to 
not assume that all integers are possible everywhere.

> Defining GUI elements in smaller units is not useful,
> because people will not be able to take advantage of smaller
> things anyway: they cannot see it clearly, or they cannot poke it
> (input) accurately enough.

This is not true. The steps are easily visible when trying to drag a 
slider handle. Users can easily see irregularly-sized items because a 
dimension that is not a multiple of N was divided into N items that are 
supposed to be equal sized. Also the steps are very annoying for smooth 
scaling of the gui at small sizes because they cause abrupt changes in 
the layout, rather than a smooth flow that you get when changing the 
scale when it is very large.