<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 3, 2013 at 3:21 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It appears John Alsaker is proposing exactly the same change I have been proposing. I think we are having a hard time explaining it however.<div class="im">
<br>
<br>
Pekka Paalanen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 28 May 2013 19:27:35 +0200<br>
John Kåre Alsaker <<a href="mailto:john.kare.alsaker@gmail.com" target="_blank">john.kare.alsaker@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My proposal is simply to let the compositor tell the client how much larger<br>
it wants the client to render content. The client can then tell the<br>
compositor how much larger it made content in the window. Armed with this<br>
information the compositor can size the window accordingly.<br>
</blockquote>
<br>
How would this look in protocol? Just roughly, what requests and events<br>
would be involved. Especially, how does the compositor know to suggest<br>
a size?<br>
</blockquote>
<br></div>
It would look *EXACTLY* the same as how the compositor currently tells clients about the output scale.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think they may have issues. A surface pel may not cover an integer<br>
amount of pixels in both buffer and output. Or how do you arrange that?<br>
</blockquote>
<br></div>
In John's proposal a "pel" *EQUALS* a buffer pixel. It is always an integer number of pixels in buffer space, no matter what scale is chosen. The fact that you don't see this means that somehow John is not explaining his design well enough, and perhaps that is why there is resistance to it? But it seems pretty obvious to me.<br>
<br>
The current scale proposal allows a "pel" to be a non-integer in both buffer and output space. The easiest way is to put a surface with a scale of 3 on an output with a scale of 2.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+ Output sizes do not have to be a multiple of the scaling factor.<br>
</blockquote></blockquote>
<br></div>
I think this may be useful for tablets? But it turns out that large monitor sizes have been designed to allow integer scales of smaller sizes. For instance 1920x1080 has common factors of 2,2,2,3,5, meaning any integer scale that is a multiple of any set of those factors will work.<br>
<br>
However if there is any kind of "panel" on the edge of the monitor there are going to be problems with maximized windows because the reduced size is going to have much fewer factors, or the panel is going to be restricted to large increments in size that may mean only ugly sizes are possible.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+ Clients can specify their size in pixels exactly.<br>
</blockquote></blockquote>
<br></div>
The biggest problem with the scale proposal is that the sizes and positions of windows are restricted to visibly large steps, thus defeating the whole point of high-dpi displays.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+ Clients get input in exact pixels (no rounding errors).<br>
+ Clients doesn't have to transform input events in order to match the<br>
sizes used by buffers.<br>
</blockquote></blockquote>
<br></div>
You said "pels" don't match buffer pixels. Therefore a transformation is needed to get to buffer pixels. And I'm worried that high-resolution pointing devices will be ignored by clients that immediately round to the nearest buffer pixel.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't really get the above.<br>
</blockquote>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are however some downsides:<br>
- Clients may need to transform input events in order to match the<br>
coordinates used by applications.<br>
</blockquote>
<br>
So this is a minus here, but the same wrt. buffers was a plus. And it's<br>
the application that first deals with input events, and then decides<br>
what to draw. I don't think input goes directly to drawing machinery.<br>
</blockquote>
<br></div>
I think the assumption that the application is working in "pels" is simplistic. We *KNOW* that part of the application is working in buffer pixels (ie the drawing code). It should use a coordinate system that is known to mean something to the application.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Clients changing scaling factors will have older input reported in the<br>
old size. This will be quite rare although clients can deal with it if<br>
desired.<br>
- Requires an implementation <:)<br>
</blockquote></blockquote>
<br></div>
This seems to be the biggest actual objection, other than apparent misunderstanding of the proposal.<br>
<br>
However the same problem applies for when a buffer attach is done with an x and y offset. The client does not know exactly what mouse events are pointing at unless it knows whether they are before or after the commit.<br>
<br>
So I now think a better solution is to have the compositor echo the commit in the event stream, so the client can easily tell whether events are before or after it. It is possible that existing events can be used to determine this.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't expect GTK or other (ancient) toolkits to do fractional scaling and<br>
reap all the benefits listed here. I don't want anything in the core<br>
protocol blocking the ability for clients to scale smoothly up though when<br>
clients will actually be able to do this.<br>
</blockquote>
<br>
You listed some features, but I still have no idea what you are<br>
suggesting.<br>
</blockquote>
<br></div>
I think is is incredibly obvious what the advantages of his scheme are. The fact that you cannot see it is really mystifying.<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.<u></u>freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/<u></u>mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">I think I'm begining to see what you and John have been suggesting. While I think Alexander's proposal will work well enough for the standard case, I think this also has merit. If I were to sum up, I'd say I was "cautiously supportive" of the above. It does seem to solve some of the edge-cases. That said, there are a few things I'd like to note.<br>
<br></div><div class="gmail_extra">1. This requires a concept of a "window" which is one we currently don't have. If we put it in wl_surface, we have to define how it works for subsurfaces. We could say that the scale factor on subsurfaces gets ignored. However, this means that we have defined an extension-specific exception. What happens if we add another future extension that alters the window's size or orientation? This will get messy. We could put this in wl_shell_surface but then we are mixing the global (wl_output) with the desktop-specific (wl_shell_surface).<br>
<br></div><div class="gmail_extra">2. This restricts subsurfaces to the same scaling factor as the original surface. Probably not a huge problem, but I'm not convinced it's a smaller restriction than requiring subsurfaces on pel-boundaries.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">3. This makes the subsurface case of handing off to a library more complicated. In Alexander's implementation, the library would simply render at native resolution or not. With this, the client has to tell the library what surface scale to use and the library has to *EXACTLY* match. Maybe this isn't a huge issue, but there's no opportunity for a client to embed an older library.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">4. If a client presents a scale_factor to the compositor that is not an integer multiple of one of the ouput_scale factors provided by the compositor, it should not expect the compositor to do anything intelligent. There are similar problems with integer proposal, but this one makes it more interesting.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Food for thought,<br></div><div class="gmail_extra">--Jason Ekstrand<br></div></div>