Jerome Glisse wrote:
The object that displays the window buffer could be a curved surface.
Imagine HUDs with a curved glass (in that case the effect is permanent
and no client should do sub pixel rendering)
Or consider fragment shaders applied to the window buffer. One cannot
apply fragement sh
2013/3/24 Pekka Paalanen :
> [...]
>> On DPI side i only proposed that client tell the compositor the DPI at
>> which it rendered its buffer so that compositor can upscale on high
>> dpi display.
>
> Exactly that is going to be a problem, since I expect rounding
> errors to produce nice 1-pixel gli
Pekka Paalanen wrote:
I always tend to assume we do not communicate the matrix, since that
exposes the global or output coordinate system, and surface
positions.
The transform is between the 0,0,w,h rectangle that the client claims
the surface occupies and the contents of the buffer. It does
On Mon, 25 Mar 2013 16:38:01 +0100
Renaud Hébert wrote:
> On Fri, 22 Mar 2013 23:51:41 +0200, Pekka Paalanen
> wrote:
> >This introduces temporary glitches, which we work hard to eliminate.
> >Unless you mean window outline moves instead of window content?
> >
> >(Window outline resizes are actu
On Fri, 22 Mar 2013 23:51:41 +0200, Pekka Paalanen
wrote:
>This introduces temporary glitches, which we work hard to eliminate.
>Unless you mean window outline moves instead of window content?
>
>(Window outline resizes are actually something I'd personally like
>to see, would make Weston on Raspb
On Sat, 23 Mar 2013 14:42:51 -0400
Jerome Glisse wrote:
> On Fri, Mar 22, 2013 at 5:51 PM, Pekka Paalanen wrote:
> > On Fri, 22 Mar 2013 10:41:00 -0400
> > Jerome Glisse wrote:
> >
> >> On Fri, Mar 22, 2013 at 6:35 AM, Pekka Paalanen
> >> wrote:
> >> > On Wed, 20 Mar 2013 13:09:48 -0400
> >>
On Sat, Mar 23, 2013 at 2:59 PM, Andreas Pokorny
wrote:
> Hi,
>
> 2013/3/23 Jerome Glisse :
>>> How would you transmit transformations that are not representable
>>> by a matrix? Nothing says we are limited to matrices, that is also
>>> just a special case. Or would you introduce that limitation i
Hi,
2013/3/23 Jerome Glisse :
>> How would you transmit transformations that are not representable
>> by a matrix? Nothing says we are limited to matrices, that is also
>> just a special case. Or would you introduce that limitation in the
>> protocol?
>
> What kind of transformation are not repres
On Fri, Mar 22, 2013 at 5:51 PM, Pekka Paalanen wrote:
> On Fri, 22 Mar 2013 10:41:00 -0400
> Jerome Glisse wrote:
>
>> On Fri, Mar 22, 2013 at 6:35 AM, Pekka Paalanen wrote:
>> > On Wed, 20 Mar 2013 13:09:48 -0400
>> > Jerome Glisse wrote:
>> >
>> >> On Wed, Mar 20, 2013 at 4:32 AM, RenoX wro
On Fri, 22 Mar 2013 10:41:00 -0400
Jerome Glisse wrote:
> On Fri, Mar 22, 2013 at 6:35 AM, Pekka Paalanen wrote:
> > On Wed, 20 Mar 2013 13:09:48 -0400
> > Jerome Glisse wrote:
> >
> >> On Wed, Mar 20, 2013 at 4:32 AM, RenoX wrote:
> >> >
> >> >
> >> > On Tue, Mar 19, 2013 at 11:34 AM, Jason E
On Fri, Mar 22, 2013 at 6:35 AM, Pekka Paalanen wrote:
> On Wed, 20 Mar 2013 13:09:48 -0400
> Jerome Glisse wrote:
>
>> On Wed, Mar 20, 2013 at 4:32 AM, RenoX wrote:
>> >
>> >
>> > On Tue, Mar 19, 2013 at 11:34 AM, Jason Ekstrand
>> > wrote:
>> >> I'm not sure exactly what I think of all this s
On Wed, 20 Mar 2013 13:09:48 -0400
Jerome Glisse wrote:
> On Wed, Mar 20, 2013 at 4:32 AM, RenoX wrote:
> >
> >
> > On Tue, Mar 19, 2013 at 11:34 AM, Jason Ekstrand
> > wrote:
> >> I'm not sure exactly what I think of all this surface transform
> >> passing. I'll get back to that once I get a
On Wed, Mar 20, 2013 at 4:32 AM, RenoX wrote:
>
>
> On Tue, Mar 19, 2013 at 11:34 AM, Jason Ekstrand
> wrote:
>> I'm not sure exactly what I think of all this surface transform
>> passing. I'll get back to that once I get a chance to think about it.
>> Part of the problem is that you don't want
On Tue, Mar 19, 2013 at 11:34 AM, Jason Ekstrand
wrote:
> I'm not sure exactly what I think of all this surface transform
> passing. I'll get back to that once I get a chance to think about it.
> Part of the problem is that you don't want to try and make your
> animations subpixel-perfect becaus
W dniu wto, mar 19, 2013 o 5:19 ,nadawca Jerome Glisse
napisał:
>
> See also:
http://en.wikipedia.org/wiki/Subpixel_rendering#Checkered_RG-BW_layout
AFAICT different RGB layout is a dead end and no longer pursue by
anyone. Everyone seems to be moving toward higher dpi. None the less
pr
On Tue, Mar 19, 2013 at 11:34 AM, Jason Ekstrand wrote:
> I'm not sure exactly what I think of all this surface transform
> passing. I'll get back to that once I get a chance to think about it.
> Part of the problem is that you don't want to try and make your
> animations subpixel-perfect becaus
I'm not sure exactly what I think of all this surface transform
passing. I'll get back to that once I get a chance to think about it.
Part of the problem is that you don't want to try and make your
animations subpixel-perfect because that would require a lot of
round-trips to make it right.
One
On Mon, Mar 18, 2013 at 03:55:03AM +0100, Sylvain BERTRAND wrote:
> But I'm still kind of uncomfortable to hand over to the
> compositor scaling in the case of fullscreen and buffer transform
> in the case of output tilting (renaming transform to tilting
> would not be a bad idea).
Oops! Of course
Jerome Glisse wrote:
Yes this is the idea i had, the client render in screen space and send
to the server a possible bigger buffer than what its window need.
Client send the screen space buffer size (wdith & height) but also the
untransformed size (width and height) and the transformation matrix
On Mon, Mar 18, 2013 at 4:17 PM, Bill Spitzak wrote:
> Jason Ekstrand wrote:
>
>>> For sub-pixel rendering the solution i have been thinking for a while
>>> but still haven't had time to prototype on weston, is to have weston
>>> send the transformation matrix to the client have the client render
Jason Ekstrand wrote:
For sub-pixel rendering the solution i have been thinking for a while
but still haven't had time to prototype on weston, is to have weston
send the transformation matrix to the client have the client render in
screen coordinate space and when commiting its surface the clien
I think the compositor has to be able to tell the client what transform
it plans to apply to the surface, and the client when setting the buffer
is able to say what transform it used to draw it.
This would also replace the current indications of 90 degree rotations.
The original email does poi
Ok, so allow me to try and sum up how I understand the discussion going so far.
It seems as if multiple buffers per surface is probably overkill.
However, we do want some sort of scaling support. Scaling could be
used for things like videos or for a surface that needs to be
displayed at different
On Thu, Mar 14, 2013 at 3:38 AM, Pekka Paalanen wrote:
> On Wed, 13 Mar 2013 19:52:55 +0100
> Sylvain BERTRAND wrote:
>
>> The other option would be to ignore those output properties, and
>> the compositor would manage something with an output agnostic
>> buffer. In that case, we would remove th
Hi,
On 18 March 2013 02:55, Sylvain BERTRAND wrote:
> Another though which targets sub-surface interfaces: are the
> hardware overlays for YUV buffers that more energy efficient than
> GPU scaling/color space conversion since most the energy would be
> burned into the video decoding anyway?
Ye
Hi again,
I put some more thoughts in those issues.
A client knows on which outputs its surfaces span over. Then the
client is in charge of configuring its rendering to find the best
trade off, but with one buffer. If the surface was entered on 2
outputs with really different DPIs... well it shou
It seems there is also an issue with the double buffered flow,
namely to make it work cleanly in a the case of a surface
spanning several outputs, those of course not in sync and with
different refresh rates. Better not be in a hurry to do a "page
flip" on a surface which covers several outputs.
O
I don't see why we'd want to remove properties from the output object.
They are still useful for the very common case where a surface is on a
single output only. For example, if a surface is on multiple outputs
with mismatching subpixel layouts, it could turn off subpixel
rendering.
Having clients
> Your proposal is middle ground: a set of buffers, and some
> heuristics applied on their properties to combine those in the
> compositor space. For simplicity, I dare to think one buffer for
> one output is quite clear cut and easier to deal with.
As a word of clarification, I said " keyed to o
On Wed, 13 Mar 2013 19:52:55 +0100
Sylvain BERTRAND wrote:
> The other option would be to ignore those output properties, and
> the compositor would manage something with an output agnostic
> buffer. In that case, we would remove the subpixel property from
> the output to stay consistent (mode i
Well, if a toolkit wants to render the same GUI on outputs of
differents properties (those properties significant for actual
rendering), they will have to render several times, no other
choice to do things properly.
The other option would be to ignore those output properties, and
the compositor wo
On Wed, Mar 13, 2013 at 10:48 AM, Sylvain BERTRAND wrote:
> Hi,
>
> The protocol does allow several outputs in the compositor space
> but does not allow a client to render a surface based on output
> properties (dpi,subpixel,frame buffer pixel format...) since
> you can attach only one buffer to a
Hi,
The protocol does allow several outputs in the compositor space
but does not allow a client to render a surface based on output
properties (dpi,subpixel,frame buffer pixel format...) since
you can attach only one buffer to a surface.
If wayland wants to give a client the ability to render its
33 matches
Mail list logo
