ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
fmuellner has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
sevz has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
mtboehlke has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
kts has quit [Ping timeout: 480 seconds]
mtboehlke has left #wayland [#wayland]
carlos_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
tesjhg has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
tesjhg has quit [Ping timeout: 480 seconds]
cptaffe has quit [Remote host closed the connection]
cptaffe has joined #wayland
sima has joined #wayland
tesjhg has joined #wayland
slattann has joined #wayland
rasterman has joined #wayland
Company has quit [Quit: Leaving]
kelnos has quit [Remote host closed the connection]
kelnos has joined #wayland
grinja has quit [Remote host closed the connection]
kts has quit [Read error: Connection reset by peer]
kts has joined #wayland
grinja has quit [Ping timeout: 480 seconds]
flom_84 has joined #wayland
flom84 has quit [Ping timeout: 480 seconds]
flom_84 has quit []
Avenaire has quit [Quit: Avenaire]
privacy has quit [Quit: Leaving]
Moprius has joined #wayland
sjao2 has quit [Quit: WeeChat 3.4.1]
tristianc6704 has joined #wayland
sjao2 has joined #wayland
privacy has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
mbalmer has quit []
junaid has quit [Remote host closed the connection]
junaid has joined #wayland
kts has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
kts has joined #wayland
cptaffe` has quit []
cptaffe has joined #wayland
cptaffe has quit [Remote host closed the connection]
cptaffe has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
Leopold has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
mblenc has joined #wayland
Leopold_ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
junaid has quit [Remote host closed the connection]
tesjhg has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Read error: No route to host]
mblenc1 has joined #wayland
mvlad has quit [Remote host closed the connection]
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
rv1sr has quit []
<aleasto>
should I expect a performance penalty in using wp_viewport.set_destination for scaling instead of wl_surface.set_buffer_scale ?
kts has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
aleasto: why should you?
<orowith2os[m]>
And afaik those two are not mutually exclusive
<orowith2os[m]>
set_destination sets the window size, set_buffer_scale sets the window scale size in integer form (use the fractional scale protocol for fractional scaling)
<aleasto>
i know they're not mutually exclusive
<orowith2os[m]>
The only time you should expect a performance penalty is when relying on integer scaling when the compositor has a fractional scale set for you
<aleasto>
i'm implementing fractional scaling for my application. i was wondering if i should keep using set_buffer_scale for integer scales or if i should just go with viewporter for everything
deathmist has joined #wayland
nerdopolis has joined #wayland
<orowith2os[m]>
Still not sure how set_destination matters here, as a "this instead of set_buffer_scale"
mblenc1 has joined #wayland
<orowith2os[m]>
Set_destination doesn't give you the scale, it gives you the size
kts has joined #wayland
<aleasto>
right, so either i say that the buffer should be interpreted as double the size, or i provide the destination size as half of the buffer
<aleasto>
(in an example with scale=2)
<orowith2os[m]>
Ah, English, fun
<orowith2os[m]>
That's better
<orowith2os[m]>
Iirc you're supposed to multiply the size by the scale and submit that
<orowith2os[m]>
Or, something like that
<orowith2os[m]>
Like, multiply a 1920x1080 monitor size by 0.75 for 75% scaling and you use that resolution instead. Hoping the concepts apply here.
<orowith2os[m]>
Will let someone else come along and pick this up, probably
<aleasto>
i'm not asking for advice on the implementation, i have both versions already implemented
<orowith2os[m]>
Er, yeah, got a bit sidetracked
<orowith2os[m]>
Tl;Dr use viewporter where possible ig?
mblenc has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
New protocols good 👍
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
Oh, I see where I got confused >>
<orowith2os[m]>
Maybe?
<orowith2os[m]>
Eh, I'll just leave it
<aleasto>
from the description of fractional-scale-v1:
<aleasto>
A client can submit scaled content by utilizing wp_viewport. This is done by creating a wp_viewport object for the surface and setting the destination rectangle to the surface size before the scale factor is applied.
<aleasto>
i'm wondering if doing that should be assumed to be more expensive than using wl_surface.set_buffer_scale when i know that the scale is integer
<orowith2os[m]>
I'd assume not? The compositor would scale it appropriately in the end
<zamundaaa[m]>
Both have exactly the same performance cost - in 95% of situations, none
<aleasto>
thank you :)
Brainium has joined #wayland
cstub has quit []
<danieldg>
there's a tiny cost from the server needing to do a bit of math to figure out your viewport plus the integer scaling is a no-op, but that's so small in comparison to an actual rescale you can't measure it
kts_ has joined #wayland
kts has quit [Read error: Connection reset by peer]
aswar002 has quit [Remote host closed the connection]
aswar002 has joined #wayland
Ampera_ has quit []
Ampera has joined #wayland
Ampera has quit [Remote host closed the connection]