Re: [PATCH 00/15] weston scaling support
John Kåre Alsaker wrote: You might have me confused for Pekka or Alexander. Our proposals should be identical here. I'm just saying that it will increase the possibly resolution of input events on higher scaling factors, which reduces issues with rounding, but doesn't solve it altogether. Yes I believe our proposals are identical. I was saying that the other proposal for "pels" will require clients to round the returned events to get the actual pixels (otherwise they will get slightly different positions depending on the scale of their display, which can cause havoc in things like CAD). This rounding will throw away high-resolution information. Our proposals should return integers for pixels and therefore the clients will not have to do this rounding. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Wed, Jun 5, 2013 at 3:11 AM, Bill Spitzak wrote: > John Kåre Alsaker wrote: > > This is still a problem without any high-DPI stuff. You could just as >> easily have an input device with a resolution 3 times higher than the >> display. >> > > I am worried that most clients will work around the problem of the scale > proposal by rounding all numbers from 3.5 to 4.5 to 4, thus throwing away > the high resolution input device. > > Lets assume a screen has scale 3 and there is a pointing device with a > resolution of 1/2 of these pixels. And the client is drawing a full-res > surface. > > (note the numbers here looks strange but they are the closest decimal to > the 24.8 fixed-point values. That is why it is .332, not .333): > > Under your proposal a normal pointing device will return 1, 1.332, 1.664, > 2, ... as coordinates. If the client just blindly multiplies by 3 they will > get 3, 3.996, 4.992, 6. I think most clients will fix this by rounding to > the nearest integer to get 3, 4, 5, 6. > > Now the high-resolution device will return 1, 1.164, 1.332, 1.5, 1.664, > 1.832, 2. If the client blindly multiplies these by 3 they will get 3, > 3.492, 3.996, 4.5, 4.992, 5.496, 6. However if the client rounds (possibly > because the author never saw a high-resolution pointer) they will get 3, 3, > 4, 4, 5, 5, 6, thus losing the high-resolution. > > In my proposal a normal pointing device will return 3, 4, 5, 6. The client > will not need to round. The high-resolution device will return 3, 3.5, 4, > 4.5, 5, 5.5, 6. Since the client does not round, it will get these values > correctly. > > Of course the client could only round numbers that are "close" to > integers, but I still feel my solution is simpler. > You might have me confused for Pekka or Alexander. Our proposals should be identical here. I'm just saying that it will increase the possibly resolution of input events on higher scaling factors, which reduces issues with rounding, but doesn't solve it altogether. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
John Kåre Alsaker wrote: This is still a problem without any high-DPI stuff. You could just as easily have an input device with a resolution 3 times higher than the display. I am worried that most clients will work around the problem of the scale proposal by rounding all numbers from 3.5 to 4.5 to 4, thus throwing away the high resolution input device. Lets assume a screen has scale 3 and there is a pointing device with a resolution of 1/2 of these pixels. And the client is drawing a full-res surface. (note the numbers here looks strange but they are the closest decimal to the 24.8 fixed-point values. That is why it is .332, not .333): Under your proposal a normal pointing device will return 1, 1.332, 1.664, 2, ... as coordinates. If the client just blindly multiplies by 3 they will get 3, 3.996, 4.992, 6. I think most clients will fix this by rounding to the nearest integer to get 3, 4, 5, 6. Now the high-resolution device will return 1, 1.164, 1.332, 1.5, 1.664, 1.832, 2. If the client blindly multiplies these by 3 they will get 3, 3.492, 3.996, 4.5, 4.992, 5.496, 6. However if the client rounds (possibly because the author never saw a high-resolution pointer) they will get 3, 3, 4, 4, 5, 5, 6, thus losing the high-resolution. In my proposal a normal pointing device will return 3, 4, 5, 6. The client will not need to round. The high-resolution device will return 3, 3.5, 4, 4.5, 5, 5.5, 6. Since the client does not round, it will get these values correctly. Of course the client could only round numbers that are "close" to integers, but I still feel my solution is simpler. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Tue, Jun 4, 2013 at 10:24 PM, Bill Spitzak wrote: > John Kåre Alsaker wrote: > > And I'm worried that high-resolution pointing devices will be >> ignored by clients that immediately round to the nearest buffer pixel. >> >> Presumably they wouldn't use the high-resolution for anything then. I'm >> not sure how this relates to the topic either. >> > > A client has to round event if it wants to do high-resolution, because it > wants to align positions with things in the buffer. This gets pretty > important with 3D modelling, lots of users and software assume that the > mouse will stop on exactly the same fractional positions, and under your > proposal this would change. > > For instance if there is a low-res device and a scale-3 output, then a > client doing a hi-res display will get mouse positions of 1, 1.333.., > 1.666..., in that window. If there is no low-res device and the hi-res one > now has a scale of 1, then the client will get positions of 3,4,5. > > Multiplying the 24.3 fixed-point representation of 1.333.. by 3 gets > 3.996. The client has to round this to 4 or it will align things slightly > different on one system than the other. I can assure you that this > difference is very annoying in 3D software. > > The only solution is to figure out the resolution of the pointing device, > transform the fixed-point event positions to the buffer positions, and then > round to the nearest multiple of the pointing device resolution. I think a > lot of software will ignore the "figure out the resolution of the pointing > device" step and just assume it is 1 pixel. Therefore any possible > high-resolution pointing will be thrown away. > > Getting the events in buffer pixels would make it a lot easier as they > could be used unchanged. Clients could then just assume any fraction is due > to a high-resolution pointing device. > This is still a problem without any high-DPI stuff. You could just as easily have an input device with a resolution 3 times higher than the display. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
John Kåre Alsaker wrote: And I'm worried that high-resolution pointing devices will be ignored by clients that immediately round to the nearest buffer pixel. Presumably they wouldn't use the high-resolution for anything then. I'm not sure how this relates to the topic either. A client has to round event if it wants to do high-resolution, because it wants to align positions with things in the buffer. This gets pretty important with 3D modelling, lots of users and software assume that the mouse will stop on exactly the same fractional positions, and under your proposal this would change. For instance if there is a low-res device and a scale-3 output, then a client doing a hi-res display will get mouse positions of 1, 1.333.., 1.666..., in that window. If there is no low-res device and the hi-res one now has a scale of 1, then the client will get positions of 3,4,5. Multiplying the 24.3 fixed-point representation of 1.333.. by 3 gets 3.996. The client has to round this to 4 or it will align things slightly different on one system than the other. I can assure you that this difference is very annoying in 3D software. The only solution is to figure out the resolution of the pointing device, transform the fixed-point event positions to the buffer positions, and then round to the nearest multiple of the pointing device resolution. I think a lot of software will ignore the "figure out the resolution of the pointing device" step and just assume it is 1 pixel. Therefore any possible high-resolution pointing will be thrown away. Getting the events in buffer pixels would make it a lot easier as they could be used unchanged. Clients could then just assume any fraction is due to a high-resolution pointing device. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
Pekka Paalanen wrote: Bill Spitzak wrote: I always figured that the transformation of a subsurface is multiplied by the transformation of the parent surface. For the scaler proposal this means the output rectangle is in parent-surface buffer pixels. You are confusing things. Sub-surface is relative to its parent surface, and therefore in the compositor implementation level, the surface transform of the parent is multiplied into the transform of the child surface. That you got correct. However, we are not talking about surface transforms here. We are talking about buffer transformations, which are private to each surface. A buffer transform does not alter or affect the surface transform. The only thing a buffer transform does, is affect how the buffer contents and size are interpreted. The wl_scaler proposal is similar to buffer transforms: it is private to a surface, and only affects the mapping between the surface and the buffer. It does not affect the surface transform, and hence it has absolutely no effect on any other surface, be it a parent surface or a child sub-surface, or my uncle. Bill and John, please adjust all your suggestions to this principle, and we have one huge barrel of man-eating worms less. No. Our proposal is that "pels" ARE EQUAL TO BUFFER PIXELS. This makes the term "pel" useless, but it may be easier to think of it that way: In BOTH proposals the rectangle a subsurface occupies is specified in "pels". This is not different. In our proposal pels are buffer pixels, therefore it is specified in buffer pixels of the parent. In your proposal it is in the transform the compositor does to the outermost surface plus the xy offsets of each intermediate parent surface. I think clients are going to want to align subsurfaces with features in their buffer, which is the primary reason I propose this, and I think why John is proposing it as well. 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. This is true already for any third-party software called by a client that can draw directly into the client's output buffer. Yes, which is why we have sub-surfaces, so that the third-party thing can have its own buffer. I can certainly imagine drawing libraries that can either draw into the client's buffer or use a subsurface depending on how they are currently set, or maybe use both. To draw into it's own buffer the client will have to tell the library the scale. In addition video players that just resize to whatever rectangle they are told will not care about the scale and will work exactly the same in both proposals (except they will get events in video pixels in our proposal, which I think would be a little easier for them). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Mon, 03 Jun 2013 18:41:51 -0700 Bill Spitzak wrote: > Jason Ekstrand wrote: > > > 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. > > > > 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). > > I always figured that the transformation of a subsurface is multiplied > by the transformation of the parent surface. For the scaler proposal > this means the output rectangle is in parent-surface buffer pixels. You are confusing things. Sub-surface is relative to its parent surface, and therefore in the compositor implementation level, the surface transform of the parent is multiplied into the transform of the child surface. That you got correct. However, we are not talking about surface transforms here. We are talking about buffer transformations, which are private to each surface. A buffer transform does not alter or affect the surface transform. The only thing a buffer transform does, is affect how the buffer contents and size are interpreted. The wl_scaler proposal is similar to buffer transforms: it is private to a surface, and only affects the mapping between the surface and the buffer. It does not affect the surface transform, and hence it has absolutely no effect on any other surface, be it a parent surface or a child sub-surface, or my uncle. Bill and John, please adjust all your suggestions to this principle, and we have one huge barrel of man-eating worms less. > > 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. > > This is true already for any third-party software called by a client > that can draw directly into the client's output buffer. Yes, which is why we have sub-surfaces, so that the third-party thing can have its own buffer. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Mon, 3 Jun 2013 16:21:48 +0200 John Kåre Alsaker wrote: > On Mon, Jun 3, 2013 at 2:22 PM, Pekka Paalanen wrote: > > > On Tue, 28 May 2013 19:27:35 +0200 > > John Kåre Alsaker wrote: > > > > > + Conceptually simple to implement. Compositors doesn't have to deal with > > > scaling for subsurfaces and they are probably already able to resize > > whole > > > windows. > > > > Why would sub-surfaces have any effect here? > > > I have absolutely no idea how subsurfaces trees with different scaling > factors on surfaces would work in Alexander's proposal. I simply don't > allow specifying it on anything other than top level surfaces, which it > uses for the whole surface tree. The answer is: sub-surfaces do not interact with other surface's buffer scaling AT ALL. Everything except buffer sizes in the protocol are in pels. Sub-surface positions are in pels. Sub-surface sizes are in pels. Whether a parent surface or a sub-surface has some buffer scaling applied or not, does not have ANY effect to anything else. That's the trivial and obvious design. A buffer scale affects only that one particular surface in how its buffer content is interpreted. Nothing more. It's the same with buffer_transform. If the parent had a transformed buffer attached, it does not transform anything else. This is actually quite vital. If there were any interactions, the use of sub-surfaces would suddenly become extremely painful. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Mon, Jun 3, 2013 at 10:21 PM, Bill Spitzak wrote: > + Clients get input in exact pixels (no rounding errors). >> + Clients doesn't have to transform input events in order to match the >> sizes used by buffers. > > You said "pels" don't match buffer pixels. Therefore a transformation is > needed to get to buffer pixels. Clients can choose if this transformation is used. > And I'm worried that high-resolution pointing devices will be ignored by > clients that immediately round to the nearest buffer pixel. Presumably they wouldn't use the high-resolution for anything then. I'm not sure how this relates to the topic either. > > - Clients changing scaling factors will have older input reported in the >>> old size. This will be quite rare although clients can deal with it if >>> desired. >>> - Requires an implementation <:) >>> >> > This seems to be the biggest actual objection, other than apparent > misunderstanding of the proposal. > > 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. > > 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. > I believe the frame callback event can be used to tell when you get the events from the new frame. On Mon, Jun 3, 2013 at 11:56 PM, Jason Ekstrand wrote: > 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. > > 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). > The concept of window I refer to is just regular a wl_surface really. With the subsurface extension added in it breaks this concept so an exception in this extension is required. This is just a side effect of adding subsurfaces as an afterthought and not having a separate window object in the protocol. I'm sure there's quite a few other things we can't do with subsurfaces already. > 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. > I don't think that's going to be a problem. If the client for some reason want to mix scaling factors, it can resize the subsurface itself. > > 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. > The client can always resize the output of the library. It's just another side of thing 2 really. > 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. > It should expect the compositor to resize the window accordingly to it's policies. The client remains blissfully unaware of whatever that has been done. I don't see how this is a issue with either proposal. > > Food for thought, > --Jason Ekstrand > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
Jason Ekstrand wrote: 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. 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). I always figured that the transformation of a subsurface is multiplied by the transformation of the parent surface. For the scaler proposal this means the output rectangle is in parent-surface buffer pixels. 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. I saw the scaling factor as a scale by 1/N (followed by a scale of N inside the compositor to the output pixels so it is 1:1). If this is on a subsurface it would be multiplied by the parent's scaling factor. This is probably pointless unless one of the two scales is 1. 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. This is true already for any third-party software called by a client that can draw directly into the client's output buffer. It seemed the primary use of this is to display videos which will likely scale to whatever rectangle is asked for, regardless of output scale. 4. If a client presents a scale_factor to the compositor that is not an integer multiple of one of the output_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. I think the compositor can adjust it to a scale the hardware can handle. It looks like there is hardware that can only handle 1, or integers, or for a source buffer of width W it can only do integer/W. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Mon, Jun 3, 2013 at 3:21 PM, Bill Spitzak wrote: > 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. > > > Pekka Paalanen wrote: > >> On Tue, 28 May 2013 19:27:35 +0200 >> John Kåre Alsaker wrote: >> >> My proposal is simply to let the compositor tell the client how much >>> larger >>> it wants the client to render content. The client can then tell the >>> compositor how much larger it made content in the window. Armed with this >>> information the compositor can size the window accordingly. >>> >> >> How would this look in protocol? Just roughly, what requests and events >> would be involved. Especially, how does the compositor know to suggest >> a size? >> > > It would look *EXACTLY* the same as how the compositor currently tells > clients about the output scale. > > > I think they may have issues. A surface pel may not cover an integer >> amount of pixels in both buffer and output. Or how do you arrange that? >> > > 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. > > 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. > > > + Output sizes do not have to be a multiple of the scaling factor. >>> >> > 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. > > 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. > > > + Clients can specify their size in pixels exactly. >>> >> > 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. > > > + Clients get input in exact pixels (no rounding errors). >>> + Clients doesn't have to transform input events in order to match the >>> sizes used by buffers. >>> >> > 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. > > > I don't really get the above. >> > > There are however some downsides: >>> - Clients may need to transform input events in order to match the >>> coordinates used by applications. >>> >> >> So this is a minus here, but the same wrt. buffers was a plus. And it's >> the application that first deals with input events, and then decides >> what to draw. I don't think input goes directly to drawing machinery. >> > > 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. > > > - Clients changing scaling factors will have older input reported in the >>> old size. This will be quite rare although clients can deal with it if >>> desired. >>> - Requires an implementation <:) >>> >> > This seems to be the biggest actual objection, other than apparent > misunderstanding of the proposal. > > 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. > > 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. > > > I don't expect GTK or other (ancient) toolkits to do fractional scaling >>> and >>> reap all the benefits listed here. I don't want anything in the core >>> protocol blocking the ability for clients to scale smoothly up though >>> when >>> clients will actually be able to do this. >>> >> >> You listed some features, but I still have no idea what you are >> suggesting. >> > > I think is is incredibly obvious what the advantages of his scheme are. > The fact that you cannot see it is really mystifying. > > __**_ > wayland-devel mailing list > wayland-devel@lists.**freed
Re: [PATCH 00/15] weston scaling support
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. Pekka Paalanen wrote: On Tue, 28 May 2013 19:27:35 +0200 John Kåre Alsaker wrote: My proposal is simply to let the compositor tell the client how much larger it wants the client to render content. The client can then tell the compositor how much larger it made content in the window. Armed with this information the compositor can size the window accordingly. How would this look in protocol? Just roughly, what requests and events would be involved. Especially, how does the compositor know to suggest a size? It would look *EXACTLY* the same as how the compositor currently tells clients about the output scale. I think they may have issues. A surface pel may not cover an integer amount of pixels in both buffer and output. Or how do you arrange that? 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. 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. + Output sizes do not have to be a multiple of the scaling factor. 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. 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. + Clients can specify their size in pixels exactly. 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. + Clients get input in exact pixels (no rounding errors). + Clients doesn't have to transform input events in order to match the sizes used by buffers. 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. I don't really get the above. There are however some downsides: - Clients may need to transform input events in order to match the coordinates used by applications. So this is a minus here, but the same wrt. buffers was a plus. And it's the application that first deals with input events, and then decides what to draw. I don't think input goes directly to drawing machinery. 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. - Clients changing scaling factors will have older input reported in the old size. This will be quite rare although clients can deal with it if desired. - Requires an implementation <:) This seems to be the biggest actual objection, other than apparent misunderstanding of the proposal. 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. 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. I don't expect GTK or other (ancient) toolkits to do fractional scaling and reap all the benefits listed here. I don't want anything in the core protocol blocking the ability for clients to scale smoothly up though when clients will actually be able to do this. You listed some features, but I still have no idea what you are suggesting. I think is is incredibly obvious what the advantages of his scheme are. The fact that you cannot see it is really mystifying. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Mon, Jun 3, 2013 at 2:22 PM, Pekka Paalanen wrote: > On Tue, 28 May 2013 19:27:35 +0200 > John Kåre Alsaker wrote: > > > My proposal is simply to let the compositor tell the client how much > larger > > it wants the client to render content. The client can then tell the > > compositor how much larger it made content in the window. Armed with this > > information the compositor can size the window accordingly. > > How would this look in protocol? Just roughly, what requests and events > would be involved. Especially, how does the compositor know to suggest > a size? > We add a new event to wl_output to tell clients how much larger they should create their windows for optimal display on that output. Clients should then create larger windows and indicate so by a new request on wl_surface where they state how much they enlarged the window. This differs from Alexander's implementation in that the window itself is larger rather than the buffer. > > > Note that this implies no further change in the protocol or concepts. > > Surface coordinates are still of the same size as buffer coordinates. > > Alright. > > > This has a number of benefits over the current implementation: > > + Rational scaling factors has no issues (the most important benefit). > > I think they may have issues. A surface pel may not cover an integer > amount of pixels in both buffer and output. Or how do you arrange that? > A surface pel would correspond exactly with a pixel in the buffer, although it might be flipped or rotated. There's no guaranteed correspondence with an output pixel in either proposal. > > For crisp pel-sized graphics (pixel-sized in apps that do not > understand the output scale), a pel should be an integer amount of > pixels in both output and buffer. > How the compositor resizes surfaces is not defined by either proposal. It may not do it at all or it may only upsize with a integer multiple. > > + Output sizes do not have to be a multiple of the scaling factor. > Clients won't be able to fill the output exactly when the output size is not a multiple of the scale factor. With a scaling factor of 3, 2560x1600 would be 853.3... x 533.3 This can't be represented in the protocol so it will need to be cropped or padding added. > + Clients can specify their size in pixels exactly. > Client doesn't have to round to the nearest multiple of the scaling factor. > > + Clients get input in exact pixels (no rounding errors). > With a scaling factor of 3, you're suddenly unable to address individual pixels. > > + Clients doesn't have to transform input events in order to match the > > sizes used by buffers. > Toolkits may store geometry in actual pixels and need events to match pixels and not some virtual unit. That's how I'd design one. > > I don't really get the above. > > > + Conceptually simple to implement. Compositors doesn't have to deal with > > scaling for subsurfaces and they are probably already able to resize > whole > > windows. > > Why would sub-surfaces have any effect here? > I have absolutely no idea how subsurfaces trees with different scaling factors on surfaces would work in Alexander's proposal. I simply don't allow specifying it on anything other than top level surfaces, which it uses for the whole surface tree. > > > + Can support clients with integer scaling factors, although these raises > > the same edge cases as the current implementation (they may not be able > to > > fit the screen exactly). > > > > There are however some downsides: > > - Clients may need to transform input events in order to match the > > coordinates used by applications. > > So this is a minus here, but the same wrt. buffers was a plus. And it's > the application that first deals with input events, and then decides > what to draw. I don't think input goes directly to drawing machinery. > It will depends on how the toolkits interprets events. If you want to hack a toolkit by multiplying all buffer sizes by an integer (which Alexander is plotting with GTK) yet keep everything else the same this proposal will require transforming the input events too. The comparison with buffers was because normally toolkits store element sizes as the size in rendered pixels. > > > - Clients changing scaling factors will have older input reported in the > > old size. This will be quite rare although clients can deal with it if > > desired. > > - Requires an implementation <:) > > > > I don't expect GTK or other (ancient) toolkits to do fractional scaling > and > > reap all the benefits listed here. I don't want anything in the core > > protocol blocking the ability for clients to scale smoothly up though > when > > clients will actually be able to do this. > > You listed some features, but I still have no idea what you are > suggesting. > > It also seems the integer output scale proposal and implementation are > maturing nicely, so now there would need to be obvious reasons for > changing it. I just don't see it based on this descrip
Re: [PATCH 00/15] weston scaling support
On Tue, 28 May 2013 19:27:35 +0200 John Kåre Alsaker wrote: > My proposal is simply to let the compositor tell the client how much larger > it wants the client to render content. The client can then tell the > compositor how much larger it made content in the window. Armed with this > information the compositor can size the window accordingly. How would this look in protocol? Just roughly, what requests and events would be involved. Especially, how does the compositor know to suggest a size? > Note that this implies no further change in the protocol or concepts. > Surface coordinates are still of the same size as buffer coordinates. Alright. > This has a number of benefits over the current implementation: > + Rational scaling factors has no issues (the most important benefit). I think they may have issues. A surface pel may not cover an integer amount of pixels in both buffer and output. Or how do you arrange that? For crisp pel-sized graphics (pixel-sized in apps that do not understand the output scale), a pel should be an integer amount of pixels in both output and buffer. > + Output sizes do not have to be a multiple of the scaling factor. > + Clients can specify their size in pixels exactly. > + Clients get input in exact pixels (no rounding errors). > + Clients doesn't have to transform input events in order to match the > sizes used by buffers. I don't really get the above. > + Conceptually simple to implement. Compositors doesn't have to deal with > scaling for subsurfaces and they are probably already able to resize whole > windows. Why would sub-surfaces have any effect here? > + Can support clients with integer scaling factors, although these raises > the same edge cases as the current implementation (they may not be able to > fit the screen exactly). > > There are however some downsides: > - Clients may need to transform input events in order to match the > coordinates used by applications. So this is a minus here, but the same wrt. buffers was a plus. And it's the application that first deals with input events, and then decides what to draw. I don't think input goes directly to drawing machinery. > - Clients changing scaling factors will have older input reported in the > old size. This will be quite rare although clients can deal with it if > desired. > - Requires an implementation <:) > > I don't expect GTK or other (ancient) toolkits to do fractional scaling and > reap all the benefits listed here. I don't want anything in the core > protocol blocking the ability for clients to scale smoothly up though when > clients will actually be able to do this. You listed some features, but I still have no idea what you are suggesting. It also seems the integer output scale proposal and implementation are maturing nicely, so now there would need to be obvious reasons for changing it. I just don't see it based on this description. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On 05/30/2013 12:42 AM, Alexander Larsson wrote: The compositor will produce regions that are not integers in surface space. For instance the damage from an overlapping window atop a surface who's scale is not an integer will produce a region that is fractional in that lower surface's space. Damage from clients is in surface space, which will be in integer fraction of the output space. Its true that it may be a fractional coordinate of the buffer space of a window below it, but it will be an integer coordinate in both windows *surface* space and the output space. So, you can clip the output drawing to integer coordinates (well, you have to, can't draw half an output pixel) and let the actual scaling to fractional coordinates happen purely in the implementation of the drawing operation. I recommend that damage from clients be in "drawing space", since they are probably closely related to the drawing code anyway. This has the advantage that integers always mean buffer pixels and you can get any integer location in the buffer. What I was talking about is damage in the compositor from an overlapping rectangle of another surface. This is not going to be an integer in either surface space or buffer space. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On ons, 2013-05-29 at 07:55 -0700, Bill Spitzak wrote: > On 05/29/2013 12:31 AM, Alexander Larsson wrote: > > >> I don't think you can avoid non-integer scaling. What happens if a > >> client says it's scale is 3 and the output has a scale of 2? This is not > >> just hypothetical, it will certainly happen if there is both a scale 3 > >> and scale 2 output on the device. > > > > Yes, the actual scaling that the compositor has to apply from the buffer > > to a given output may be fractional. However, the scaling factor between > > the buffer and the surface (i.e. in pels or in global compositor > > relative sizes) is an integer. This means that any integer position in > > surface space corresponds to an integer in buffer space, so for instance > > a pixman region (in ints) damage or clip region in surface space > > corresponds to an exact pixman region in buffer coordinates. And, this > > is the transformation that the compositor really cares about internally > > (e.g. for input scaling, clipping, dirty tracking, etc) rather than the > > final drawing translation. > > The compositor will produce regions that are not integers in surface > space. For instance the damage from an overlapping window atop a surface > who's scale is not an integer will produce a region that is fractional > in that lower surface's space. Damage from clients is in surface space, which will be in integer fraction of the output space. Its true that it may be a fractional coordinate of the buffer space of a window below it, but it will be an integer coordinate in both windows *surface* space and the output space. So, you can clip the output drawing to integer coordinates (well, you have to, can't draw half an output pixel) and let the actual scaling to fractional coordinates happen purely in the implementation of the drawing operation. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On 05/29/2013 12:31 AM, Alexander Larsson wrote: I don't think you can avoid non-integer scaling. What happens if a client says it's scale is 3 and the output has a scale of 2? This is not just hypothetical, it will certainly happen if there is both a scale 3 and scale 2 output on the device. Yes, the actual scaling that the compositor has to apply from the buffer to a given output may be fractional. However, the scaling factor between the buffer and the surface (i.e. in pels or in global compositor relative sizes) is an integer. This means that any integer position in surface space corresponds to an integer in buffer space, so for instance a pixman region (in ints) damage or clip region in surface space corresponds to an exact pixman region in buffer coordinates. And, this is the transformation that the compositor really cares about internally (e.g. for input scaling, clipping, dirty tracking, etc) rather than the final drawing translation. The compositor will produce regions that are not integers in surface space. For instance the damage from an overlapping window atop a surface who's scale is not an integer will produce a region that is fractional in that lower surface's space. I agree that the compositor will then immediately expand these to integer buffer coordinates, but I don't think limiting the scales to integers is buying you anything. The client should send regions to the compositor in buffer pixels. It has to use these coordinates to draw and things like "opaque region" are much more related to drawing than anything else. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On tis, 2013-05-28 at 18:33 -0700, Bill Spitzak wrote: > On 05/28/2013 06:40 AM, Pekka Paalanen wrote: > > > If you really need an output scaling factor like 1.5, then you report it > > as either 1 or 2, and do a compensating scaling in the compositor to > > achieve 1.5. That is the best compromize I can imagine, since to be > > honest, 1.5 does not work for the protocol nor the clients' rendering. > > Then it is impossible for the client to render 1:1 with this output's > pixels. All it can do is set the scale to 1 and have it scaled up by 1.5 > to get the output pixels, or set the scale to 2 and have it scaled down > to .75 to get the pixels. > > I don't think you can avoid non-integer scaling. What happens if a > client says it's scale is 3 and the output has a scale of 2? This is not > just hypothetical, it will certainly happen if there is both a scale 3 > and scale 2 output on the device. Yes, the actual scaling that the compositor has to apply from the buffer to a given output may be fractional. However, the scaling factor between the buffer and the surface (i.e. in pels or in global compositor relative sizes) is an integer. This means that any integer position in surface space corresponds to an integer in buffer space, so for instance a pixman region (in ints) damage or clip region in surface space corresponds to an exact pixman region in buffer coordinates. And, this is the transformation that the compositor really cares about internally (e.g. for input scaling, clipping, dirty tracking, etc) rather than the final drawing translation. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On 05/28/2013 06:40 AM, Pekka Paalanen wrote: If you really need an output scaling factor like 1.5, then you report it as either 1 or 2, and do a compensating scaling in the compositor to achieve 1.5. That is the best compromize I can imagine, since to be honest, 1.5 does not work for the protocol nor the clients' rendering. Then it is impossible for the client to render 1:1 with this output's pixels. All it can do is set the scale to 1 and have it scaled up by 1.5 to get the output pixels, or set the scale to 2 and have it scaled down to .75 to get the pixels. I don't think you can avoid non-integer scaling. What happens if a client says it's scale is 3 and the output has a scale of 2? This is not just hypothetical, it will certainly happen if there is both a scale 3 and scale 2 output on the device. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
My proposal is simply to let the compositor tell the client how much larger it wants the client to render content. The client can then tell the compositor how much larger it made content in the window. Armed with this information the compositor can size the window accordingly. Note that this implies no further change in the protocol or concepts. Surface coordinates are still of the same size as buffer coordinates. This has a number of benefits over the current implementation: + Rational scaling factors has no issues (the most important benefit). + Output sizes do not have to be a multiple of the scaling factor. + Clients can specify their size in pixels exactly. + Clients get input in exact pixels (no rounding errors). + Clients doesn't have to transform input events in order to match the sizes used by buffers. + Conceptually simple to implement. Compositors doesn't have to deal with scaling for subsurfaces and they are probably already able to resize whole windows. + Can support clients with integer scaling factors, although these raises the same edge cases as the current implementation (they may not be able to fit the screen exactly). There are however some downsides: - Clients may need to transform input events in order to match the coordinates used by applications. - Clients changing scaling factors will have older input reported in the old size. This will be quite rare although clients can deal with it if desired. - Requires an implementation <:) I don't expect GTK or other (ancient) toolkits to do fractional scaling and reap all the benefits listed here. I don't want anything in the core protocol blocking the ability for clients to scale smoothly up though when clients will actually be able to do this. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Tue, 28 May 2013 17:03:29 +0200 John Kåre Alsaker wrote: > On Tue, May 28, 2013 at 3:40 PM, Pekka Paalanen wrote: > > > On Tue, 28 May 2013 15:10:53 +0200 > > John Kåre Alsaker wrote: > > > > > On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg > >wrote: > > > > > > > I read through the latest wayland protocol patches and the discussion > > > > around them and didn't seen anything I didn't like. I think the > > > > approach here is good and agree with the consensus. This patch series > > > > looks great too and I like the improvements to the pixman renderer and > > > > the compositor-x11.c optimization. > > > > > > > Where did the consensus come from? > > > > > > I think the lack of fractional scale factors will result in further > > > extensions to support that in the future. I really also dislike how this > > > implementation won't allow clients to draw with pixel precision on > > scaling > > > factors above 1. > > > > Quite the contrary, it does allow drawing at least at pel precision, and > > it even guarantees that a pel always accurately hits the pixel > > boundaries in both the buffer, and all outputs regardless of their > > scale factor (provided the compositor does not do additional > > transformations of its own). > > > The only problem is that pel precision is not pixel precision. Furthermore > output sizes are not aligned with pel unit sizes, they are in pixels. Output size does not matter, and wl_output reports modes in true pixels. Any issues with fullscreening are quite easily defined, including allowing direct scanout. At least with integer factors, a pel will always occupy an integer number of pixels in both dimensions, regardless of output_scale or buffer_scale. You can still choose the output_scale as your buffer_scale, and do pixel precision rendering on that output. If you consider outputs with different scales, you are screwed in any case. > > Introduce rational factors, and it can only be of worse image quality, > > combined with a lot of protocol and interpretation difficulties, when > > sizes are suddenly not integers. > > > Which protocol and interpretation difficulties are you referring to? I've > not found any in my proposal, buffer and surface sizes are still in > integers there. All the ones raised along the previous thread. Which email was the proposal you refer to? > I do wonder what happens if you attach a buffer of size 101x101 in the > current implementation with a scale factor of two. Is the compositor > expected to use 50.5x50.5 as the surface size? Using odd surface dimensions with a buffer_scale=2 is a client error. It is nothing the compositor needs to support correctly, even if one could define what correct would be. If you allow rational scaling factors, we either need a lot more complex rules about sizes, or then the compositor must always deal with fractional sizes, and we need to define all the behaviour in every step that may round. That is nasty. > While rendering at rational factor can't be of better quality, it can > however be done at a much higher quality than downscaling, faster and with > less memory usage. Perhaps, but that benefit diminishes compared to the cons. > > If you really need an output scaling factor like 1.5, then you report it > > as either 1 or 2, and do a compensating scaling in the compositor to > > achieve 1.5. That is the best compromize I can imagine, since to be > > honest, 1.5 does not work for the protocol nor the clients' rendering. > > > 1.5 works just fine for the protocol and clients' rendering. We cannot clip regions to fractional sizes, nor express them in the protocol. We would need lots of rounding rules in the protocol, which just makes everything more complex. Ever tried to render a crisp line, like a button border, as 1.5 pixels wide? Also: On Wed, 22 May 2013 10:12:00 +0200 Alexander Larsson wrote: > On tis, 2013-05-21 at 20:57 +0300, Pekka Paalanen wrote: > > On Tue, 21 May 2013 08:35:53 -0700 > > Bill Spitzak wrote: > > > > This proposal does not actually restrict widget positions or line sizes, > > > since they are drawn by the client at buffer resolution. Although > > > > No, but I expect the toolkits may. > > Gtk very much will do this at least. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Tue, May 28, 2013 at 3:40 PM, Pekka Paalanen wrote: > On Tue, 28 May 2013 15:10:53 +0200 > John Kåre Alsaker wrote: > > > On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg >wrote: > > > > > I read through the latest wayland protocol patches and the discussion > > > around them and didn't seen anything I didn't like. I think the > > > approach here is good and agree with the consensus. This patch series > > > looks great too and I like the improvements to the pixman renderer and > > > the compositor-x11.c optimization. > > > > > Where did the consensus come from? > > > > I think the lack of fractional scale factors will result in further > > extensions to support that in the future. I really also dislike how this > > implementation won't allow clients to draw with pixel precision on > scaling > > factors above 1. > > Quite the contrary, it does allow drawing at least at pel precision, and > it even guarantees that a pel always accurately hits the pixel > boundaries in both the buffer, and all outputs regardless of their > scale factor (provided the compositor does not do additional > transformations of its own). > The only problem is that pel precision is not pixel precision. Furthermore output sizes are not aligned with pel unit sizes, they are in pixels. > Introduce rational factors, and it can only be of worse image quality, > combined with a lot of protocol and interpretation difficulties, when > sizes are suddenly not integers. > Which protocol and interpretation difficulties are you referring to? I've not found any in my proposal, buffer and surface sizes are still in integers there. I do wonder what happens if you attach a buffer of size 101x101 in the current implementation with a scale factor of two. Is the compositor expected to use 50.5x50.5 as the surface size? While rendering at rational factor can't be of better quality, it can however be done at a much higher quality than downscaling, faster and with less memory usage. > > If you really need an output scaling factor like 1.5, then you report it > as either 1 or 2, and do a compensating scaling in the compositor to > achieve 1.5. That is the best compromize I can imagine, since to be > honest, 1.5 does not work for the protocol nor the clients' rendering. > 1.5 works just fine for the protocol and clients' rendering. > I thought I explained that before, maybe to someone else, but on this > mailing list anyway. > > > - pq > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Tue, 28 May 2013 15:10:53 +0200 John Kåre Alsaker wrote: > On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg wrote: > > > I read through the latest wayland protocol patches and the discussion > > around them and didn't seen anything I didn't like. I think the > > approach here is good and agree with the consensus. This patch series > > looks great too and I like the improvements to the pixman renderer and > > the compositor-x11.c optimization. > > > Where did the consensus come from? > > I think the lack of fractional scale factors will result in further > extensions to support that in the future. I really also dislike how this > implementation won't allow clients to draw with pixel precision on scaling > factors above 1. Quite the contrary, it does allow drawing at least at pel precision, and it even guarantees that a pel always accurately hits the pixel boundaries in both the buffer, and all outputs regardless of their scale factor (provided the compositor does not do additional transformations of its own). Introduce rational factors, and it can only be of worse image quality, combined with a lot of protocol and interpretation difficulties, when sizes are suddenly not integers. If you really need an output scaling factor like 1.5, then you report it as either 1 or 2, and do a compensating scaling in the compositor to achieve 1.5. That is the best compromize I can imagine, since to be honest, 1.5 does not work for the protocol nor the clients' rendering. I thought I explained that before, maybe to someone else, but on this mailing list anyway. - pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Thu, May 23, 2013 at 2:57 AM, Kristian Høgsberg wrote: > I read through the latest wayland protocol patches and the discussion > around them and didn't seen anything I didn't like. I think the > approach here is good and agree with the consensus. This patch series > looks great too and I like the improvements to the pixman renderer and > the compositor-x11.c optimization. > Where did the consensus come from? I think the lack of fractional scale factors will result in further extensions to support that in the future. I really also dislike how this implementation won't allow clients to draw with pixel precision on scaling factors above 1. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
- Original Message - > On Thu, 23 May 2013 10:55:08 +0200 > Alexander Larsson wrote: > > > On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote: > > > > > > > I hate to rain on the parade, but it's not going to be that simple. I > > > already tried adding a field to wl_resource and, as it currently > > > stands, it causes major issues. As a reminder, this is because > > > wl_buffer has a wl_resource field which means that altering > > > wl_resource breaks binary compatibility for EGL implementations. > > > > > > I've been trying to figure out how to do this with my java stuff and I > > > really think adding a version flag to wl_resource is the way to do it. > > > Unfortunately, but it's not going to be easy. > > > > Both wl_resource and wl_buffer are server internals though. And the > > server API/ABI is not yet frozen. (In fact we just massively broke it.) > > > > wl_buffer does appear in the client header, but just as a declaration, > > not the type definition. > > > > So, this doesn't necessary seem that hard. > > libEGL contains server-side code, too, for implementing > EGL_WL_bind_wayland_display. > > http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/wayland/wayland-drm/wayland-drm.h > > struct wl_drm_buffer will break. Ugh, this is really bad. It also uses the scanner and code generator to create wl_interface structs like wl_drm_interface. This means we can't extend wl_interface, etc, so we can't add a "since version" field to wl_message. So, how can we fix the crash in the server when it gets sent a new request that it doesn't yet handle? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Thu, 23 May 2013 10:55:08 +0200 Alexander Larsson wrote: > On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote: > > > > I hate to rain on the parade, but it's not going to be that simple. I > > already tried adding a field to wl_resource and, as it currently > > stands, it causes major issues. As a reminder, this is because > > wl_buffer has a wl_resource field which means that altering > > wl_resource breaks binary compatibility for EGL implementations. > > > > I've been trying to figure out how to do this with my java stuff and I > > really think adding a version flag to wl_resource is the way to do it. > > Unfortunately, but it's not going to be easy. > > Both wl_resource and wl_buffer are server internals though. And the > server API/ABI is not yet frozen. (In fact we just massively broke it.) > > wl_buffer does appear in the client header, but just as a declaration, > not the type definition. > > So, this doesn't necessary seem that hard. libEGL contains server-side code, too, for implementing EGL_WL_bind_wayland_display. http://cgit.freedesktop.org/mesa/mesa/tree/src/egl/wayland/wayland-drm/wayland-drm.h struct wl_drm_buffer will break. I'm beginning to think maybe we should simply fordib embedding a struct wl_resource, to make it future proof. In the future. Cheers, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On ons, 2013-05-22 at 20:36 -0500, Jason Ekstrand wrote: > I hate to rain on the parade, but it's not going to be that simple. I > already tried adding a field to wl_resource and, as it currently > stands, it causes major issues. As a reminder, this is because > wl_buffer has a wl_resource field which means that altering > wl_resource breaks binary compatibility for EGL implementations. > > I've been trying to figure out how to do this with my java stuff and I > really think adding a version flag to wl_resource is the way to do it. > Unfortunately, but it's not going to be easy. Both wl_resource and wl_buffer are server internals though. And the server API/ABI is not yet frozen. (In fact we just massively broke it.) wl_buffer does appear in the client header, but just as a declaration, not the type definition. So, this doesn't necessary seem that hard. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On ons, 2013-05-22 at 20:57 -0400, Kristian Høgsberg wrote:
> * Don't send out new wl_output events to clients that bind with
>version 1. For this I think we want to extend wl_resource with an
>int version; field.
Somewhat related, and I mentioned this earlier in the thread, we have a
problem with versioning of the *server* too. For instance, if you build
the new wayland server libs and run the old weston on it then you will
get server crashes if some client uses the new wayland ops.
It happens this way:
The old weston client did:
wl_client_add_resource(client, &surface->resource);
However, here resource.object.interface points to wl_surface_interface,
which is:
extern const struct wl_interface wl_surface_interface;
So, the wl_surface_interface is not in the client, but rather in
libwayland-server, as:
WL_EXPORT const struct wl_interface wl_surface_interface = {
"wl_surface", 3,
9, wl_surface_requests,
2, wl_surface_events,
};
This here hardcodes the version (3) into the *server* library rather
than the compositor, so when the compositor is later run with a newer
server library the request dispatcher assumes that the compositor
handles surface version 3, which means it will accept the new requests
and call into the vfunc in the compositor. But that vfunc doesn't
contain the new request, so we call into hyperspace and crash.
Similar things happens in the client if the compositor sends an event
that is later than the version the client bound as. This is clearly a
bug in the compositor though, so its not really as important.
I see two possibilities here. Either we add a version to
wl_client_add_resource() and encode version information into
wl_surface_requests. Then the dispatch machinery can check the version
and only dispatch the right requests. Or we could set up the headers so
that each compositor gets the wl_surface_interface linked into the
compositor itself. Of course, the second version has a similar behavior
to the current in the sense that if you accidentally rebuild the old
weston against the new wayland library you'd still get the crash, so the
first version seems more correct.
I'll have a look at this.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Thu, May 23, 2013 at 01:05:43AM +0200, Hardening wrote: > Le 22/05/2013 14:41, al...@redhat.com a écrit : > >From: Alexander Larsson > > > >This adds support to weston (X11 and DRM backends) for output > >scale and buffer_scale. It also contains some work on the > >example clients to make them support buffer scaling. > > > >I think the support is fairly comprehensive, although I'm aware of > >a few outstanding issues: > > > >* The drm backend doesn't upscale pointers on the DRM backend > >* There is no support in the desktop shell for setting up a higher resolution > > cursor image on scaled outputs > >* I did not yet look at the screenshoter/read_pixels APIs > > > >Overall I think the approach is working out well, but an obvious issue is > >how we handle > >scaling wrt modes. I'll bring this up in another mail. > [...] > > This trivial patch is missing to have it work with the RDP compositor: > diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c > index 15e340c..48ac77d 100644 > --- a/src/compositor-rdp.c > +++ b/src/compositor-rdp.c > @@ -473,7 +473,7 @@ rdp_compositor_create_output(struct > rdp_compositor *c, int width, int height, > > output->base.current = currentMode; > weston_output_init(&output->base, &c->base, 0, 0, width, height, > - WL_OUTPUT_TRANSFORM_NORMAL); > + WL_OUTPUT_TRANSFORM_NORMAL, 1); > > output->base.make = "weston"; > output->base.model = "rdp"; Thanks, fixed. Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Wed, May 22, 2013 at 7:57 PM, Kristian Høgsberg wrote: > On Wed, May 22, 2013 at 02:41:24PM +0200, al...@redhat.com wrote: > > From: Alexander Larsson > > > > This adds support to weston (X11 and DRM backends) for output > > scale and buffer_scale. It also contains some work on the > > example clients to make them support buffer scaling. > > > > I think the support is fairly comprehensive, although I'm aware of > > a few outstanding issues: > > > > * The drm backend doesn't upscale pointers on the DRM backend > > * There is no support in the desktop shell for setting up a higher > resolution > > cursor image on scaled outputs > > * I did not yet look at the screenshoter/read_pixels APIs > > Two more: > > * window.c pre-renders decorations at a fixed 1-to-1 pixel size which >then get scaled up. The rounded corners look blocky when you use a >scale > 1. > > * Don't send out new wl_output events to clients that bind with >version 1. For this I think we want to extend wl_resource with an >int version; field. > I hate to rain on the parade, but it's not going to be that simple. I already tried adding a field to wl_resource and, as it currently stands, it causes major issues. As a reminder, this is because wl_buffer has a wl_resource field which means that altering wl_resource breaks binary compatibility for EGL implementations. I've been trying to figure out how to do this with my java stuff and I really think adding a version flag to wl_resource is the way to do it. Unfortunately, but it's not going to be easy. > > Overall I think the approach is working out well, but an obvious > > issue is how we handle scaling wrt modes. I'll bring this up in > > another mail. > > I read through the latest wayland protocol patches and the discussion > around them and didn't seen anything I didn't like. I think the > approach here is good and agree with the consensus. This patch series > looks great too and I like the improvements to the pixman renderer and > the compositor-x11.c optimization. > > I've applied both wayland and weston patches. The protocol is not set > in stone, but the 1.2 release is coming up end of June, and which > point we lock it down. So we can tweak it further, but at least the > bulk of the work is now landed. > > thanks, > Kristian > > > The series is also availible in the scale branch here: (eventually) > > http://cgit.freedesktop.org/~alexl/weston/ > > > > Alexander Larsson (15): > > window: Support transform in widget_cairo_create() > > transformed: Rely on transformation in widget_cairo_create > > window: Track output scales > > window: allow setting a buffer scale on a window > > window: Apply buffer_scale automatically in widget_cairo_create > > transformed: Use the scale factor from the output > > window: Store server_allocation in surface size > > desktop-shell: Respect output scale and translate > > window: Add window_get_output_scale() > > terminal: Handle output transform > > transformed: Add keyboard shortcuts to change transform > > pixman-renderer: Fix up transform handling > > compositor: Support output/buffer scaling > > compositor-x11: Only repaint the damaged region > > compositor-drm: Support output scaling > > > > clients/desktop-shell.c | 75 ++-- > > clients/terminal.c| 13 +- > > clients/transformed.c | 124 ++--- > > clients/window.c | 237 ++--- > > clients/window.h | 13 ++ > > src/compositor-drm.c | 88 +++--- > > src/compositor-fbdev.c| 3 +- > > src/compositor-headless.c | 2 +- > > src/compositor-rpi.c | 3 +- > > src/compositor-wayland.c | 2 +- > > src/compositor-x11.c | 166 -- > > src/compositor.c | 110 +--- > > src/compositor.h | 18 +- > > src/gl-renderer.c | 21 +-- > > src/pixman-renderer.c | 436 > ++ > > 15 files changed, 977 insertions(+), 334 deletions(-) > > > > -- > > 1.8.1.4 > > > > ___ > > wayland-devel mailing list > > wayland-devel@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
On Wed, May 22, 2013 at 02:41:24PM +0200, al...@redhat.com wrote: > From: Alexander Larsson > > This adds support to weston (X11 and DRM backends) for output > scale and buffer_scale. It also contains some work on the > example clients to make them support buffer scaling. > > I think the support is fairly comprehensive, although I'm aware of > a few outstanding issues: > > * The drm backend doesn't upscale pointers on the DRM backend > * There is no support in the desktop shell for setting up a higher resolution > cursor image on scaled outputs > * I did not yet look at the screenshoter/read_pixels APIs Two more: * window.c pre-renders decorations at a fixed 1-to-1 pixel size which then get scaled up. The rounded corners look blocky when you use a scale > 1. * Don't send out new wl_output events to clients that bind with version 1. For this I think we want to extend wl_resource with an int version; field. > Overall I think the approach is working out well, but an obvious > issue is how we handle scaling wrt modes. I'll bring this up in > another mail. I read through the latest wayland protocol patches and the discussion around them and didn't seen anything I didn't like. I think the approach here is good and agree with the consensus. This patch series looks great too and I like the improvements to the pixman renderer and the compositor-x11.c optimization. I've applied both wayland and weston patches. The protocol is not set in stone, but the 1.2 release is coming up end of June, and which point we lock it down. So we can tweak it further, but at least the bulk of the work is now landed. thanks, Kristian > The series is also availible in the scale branch here: (eventually) > http://cgit.freedesktop.org/~alexl/weston/ > > Alexander Larsson (15): > window: Support transform in widget_cairo_create() > transformed: Rely on transformation in widget_cairo_create > window: Track output scales > window: allow setting a buffer scale on a window > window: Apply buffer_scale automatically in widget_cairo_create > transformed: Use the scale factor from the output > window: Store server_allocation in surface size > desktop-shell: Respect output scale and translate > window: Add window_get_output_scale() > terminal: Handle output transform > transformed: Add keyboard shortcuts to change transform > pixman-renderer: Fix up transform handling > compositor: Support output/buffer scaling > compositor-x11: Only repaint the damaged region > compositor-drm: Support output scaling > > clients/desktop-shell.c | 75 ++-- > clients/terminal.c| 13 +- > clients/transformed.c | 124 ++--- > clients/window.c | 237 ++--- > clients/window.h | 13 ++ > src/compositor-drm.c | 88 +++--- > src/compositor-fbdev.c| 3 +- > src/compositor-headless.c | 2 +- > src/compositor-rpi.c | 3 +- > src/compositor-wayland.c | 2 +- > src/compositor-x11.c | 166 -- > src/compositor.c | 110 +--- > src/compositor.h | 18 +- > src/gl-renderer.c | 21 +-- > src/pixman-renderer.c | 436 > ++ > 15 files changed, 977 insertions(+), 334 deletions(-) > > -- > 1.8.1.4 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/15] weston scaling support
Le 22/05/2013 14:41, al...@redhat.com a écrit : From: Alexander Larsson This adds support to weston (X11 and DRM backends) for output scale and buffer_scale. It also contains some work on the example clients to make them support buffer scaling. I think the support is fairly comprehensive, although I'm aware of a few outstanding issues: * The drm backend doesn't upscale pointers on the DRM backend * There is no support in the desktop shell for setting up a higher resolution cursor image on scaled outputs * I did not yet look at the screenshoter/read_pixels APIs Overall I think the approach is working out well, but an obvious issue is how we handle scaling wrt modes. I'll bring this up in another mail. [...] This trivial patch is missing to have it work with the RDP compositor: diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c index 15e340c..48ac77d 100644 --- a/src/compositor-rdp.c +++ b/src/compositor-rdp.c @@ -473,7 +473,7 @@ rdp_compositor_create_output(struct rdp_compositor *c, int width, int height, output->base.current = currentMode; weston_output_init(&output->base, &c->base, 0, 0, width, height, - WL_OUTPUT_TRANSFORM_NORMAL); + WL_OUTPUT_TRANSFORM_NORMAL, 1); output->base.make = "weston"; output->base.model = "rdp"; ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
