ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
AJC_Z0 has joined #wayland
AJ_Z0 has quit [Ping timeout: 480 seconds]
AJC_Z0 is now known as AJ_Z0
glennk has joined #wayland
Brainium has joined #wayland
JayBeeFOSS has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
JayBeeFOSS has quit [Ping timeout: 480 seconds]
JayBeeFOSS has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts has quit [Quit: Konversation terminated!]
nerdopolis has joined #wayland
lsd|2 has joined #wayland
lsd|2|2 has joined #wayland
kts has joined #wayland
lsd|2|2 has quit []
lsd|2 has quit []
lsd|2 has joined #wayland
kts has quit [Quit: Konversation terminated!]
nerdopolis has quit [Ping timeout: 480 seconds]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
carlos_ has quit [Ping timeout: 480 seconds]
paulk-bis has quit [Remote host closed the connection]
m5zs7k has quit []
m5zs7k has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
RAOF_ has quit [Remote host closed the connection]
RAOF has joined #wayland
nnm has quit []
nnm has joined #wayland
Company has quit [Quit: Leaving]
sima has joined #wayland
bindu has quit [Remote host closed the connection]
<kchibisov>
How to identify that the output has fractional scaling? I'd assume one could do that based on the resolution and logical size from the xdg-output?
<emersion>
why do you need to know?
<kchibisov>
I said the same to the user of the library.
<kchibisov>
but they want it to contraint size.
<kchibisov>
They are just get confused that the `monitor` object returns scale 2, but `window` scale 1.5.
<kchibisov>
I just remember that GTK folks needed something like that in the past to scale their widgets.
<kchibisov>
Since before they used the `some monitor` as a hint, which is obviously wrong.
<emersion>
monitors should not be used to infer anything really
<emersion>
monitors are best ignored unless there is a really good reason to look at them
<kchibisov>
I guess I'll just update the docs and close the issue.
<kchibisov>
I was just curious if someone decided to add a fractional scaling information to outputs.
<emersion>
nope
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
<emersion>
also wl_surface.preferred_buffer_scale might not match any output's
<kchibisov>
I know, I know compositor which has a scaling on per-window basis.
<kchibisov>
So you can make some windows smaller/bigger separatelly.
kts has quit [Ping timeout: 480 seconds]
<kennylevinsen>
wl_output.scale was superseded by preferred_buffer_scale, so if anything changes I imagine it would be deprecation rather than upgrade to fractional...
<kchibisov>
Is it valid for compositor to send configure larger than the configure_bounds it send?
kts has quit [Ping timeout: 480 seconds]
<emersion>
yes
<emersion>
configure_bounds is just a hint
<kchibisov>
But I can use them reliably to constraint initial window size?
kts has joined #wayland
<kennylevinsen>
it's a bit weird to explicitly request a size larger than configure_bounds, but I suppose it could happen if e.g. a user is resizing a window past output dimensions with SSD
<kchibisov>
Like the hint is used for users to not try to draw the window larger than compositor can present in the current state. From what I understand.
<Company>
GTK uses the bounds as a hint for the application as an upper limit when the application picks a size
<kchibisov>
Yeah, when compositor sends `0x0` I want to limit the size by the configure bounds.
<Company>
and the configure size to set the size when it doesn't ask the application
<zamundaaa[m]>
kchibisov: yes, that is the intended purpose
<Company>
so those numbers rarely ever meet each other in that codebase
<Company>
but it's expected that configure size can be largeer than bounds
<kchibisov>
Thanks.
<Company>
usually the results are inpleasant though
<Company>
because a bunch of code will cause a sudden shrink of the window to the bounds
<kchibisov>
If the user asks GTK to resize window to WxH will it use configure bounds for that or just resize?
<kennylevinsen>
I suppose the flow would be: if configure contains dimensions, adhere to those - if not, pick a size less than or equal to configure_bounds (infinity if not set)
<Company>
kchibisov: it will just resize
<kchibisov>
Hm, interesting.
<Company>
kchibisov: but the next time the app initiates a resize, it will limit itself to the bounds
<Company>
which is where you get the sudden shrinking
<kennylevinsen>
I suppose that's also fair enough - if a user wants to make the window span two outputs, why not let them? It's just not a pleasant size to pick autonomously.
<Company>
you can experiment with that in mutter I believe if you have 2 monitors
<Company>
and resize the window to be larger
<kchibisov>
kennylevinsen: you don't have tiles spanning 2 outputs.
<emersion>
in sway, configure_bounds would account for desktop UI elements like bars, but the user can resize past these bounds
<emersion>
in floating mode
<emersion>
the bar is actually displayed under the floating windows
<Company>
kennylevinsen: it's problematic in the sense that you need to come up with an algorithm that works both for users growing the window out of bounds and for things like output size shrinking
<Company>
kennylevinsen: say when you disconenct from an external monitor
<kchibisov>
emersion: the bar is displayed where you told it to be displayed though.
<emersion>
i mean, sway with default config
<kchibisov>
sure.
<kennylevinsen>
I would expect a conventional stacking compositor to set bounds to the usable visible area of the current monitor
<emersion>
it's just an example of when configure can go past configure_bounds
<kennylevinsen>
tiling is just a case where we reduce the bounds further
<Company>
we've had various discussions about how to handle bounds and no good conclusion
<kennylevinsen>
Company: Yeah I can imagine it's tricky to deal with for a toolkit :)
<kchibisov>
The issue I'm trying to solve is to 1) constraint the initial size 2) disallow resizing in tiling in some cases.
<kchibisov>
The 1) I solved.
<Company>
ie if compositors should send monitor bounds or root window bounds or what
<kennylevinsen>
on the protocol level it's trivial enough, but that's how the story goes for most things isn't it?
<Company>
and if apps should shrink to bounds or only use it as a limit when growing
<kchibisov>
The other issue I have is users want to resize, but not when their window can't resize, like on sway with tiling.
<kchibisov>
But tiling state doesn't mandate that it can't resize, and users on compositor I use can resize tiles.
<Company>
kennylevinsen: depends on how prescriptive the protocol wants to be - "here's a random number" or "if you do not stay below this number, the compositor will disconnect you"
<emersion>
clients are not allowed to resize when maximized
glennk has quit [Ping timeout: 480 seconds]
<kchibisov>
does sway set maximize for everything?
<kennylevinsen>
kchibisov: A tiling compositor should send dimensions in the configure event together with the tiled state, which should overrule bounds anyway. But I would also expect a tiling compositor to send bounds equal to the tile.
<kchibisov>
I remember it sets maximize or tiling.
<emersion>
do we not have wording to disallow resize when tiled?
<kennylevinsen>
clay does that
<kchibisov>
emersion: we don't and I'm not sure why we need it.
<emersion>
kchibisov: sway sets tiled when xdg-shell version is high enough, otherwise maximized
<kchibisov>
kennylevinsen: my tiling compositor can handle user tiles resizes.
<kchibisov>
because the `x` is infinite.
<kennylevinsen>
which should result in configure events with new dimensions
<kchibisov>
So it'll naturally resize and my viewport just scroll.
<kennylevinsen>
which should take priority over bounds
<kchibisov>
yes, but I'm talking about different issue.
glennk has joined #wayland
<kchibisov>
user want to not resize during tiling when the compositor will crop them, like sway.
<kchibisov>
So in theory, I could use `configure_bounds` to limit the resizing in such case, but gtk doesn't do that for example.
<emersion>
sway crops because sending a protocol error trips too many clients
<kchibisov>
emersion: there's no wording for tiled states though.
<kchibisov>
so it's not like you can do so.
<kennylevinsen>
emersion: do we? I only see tiled for xdg and maximized for xwayland
<emersion>
kennylevinsen: logic is in wlroots
<kchibisov>
the maximized has the right wording.
<emersion>
kchibisov: that sounds like an oversight to me
<kennylevinsen>
ah, there
<kchibisov>
ok, what to do with tiled compositor which can resize?
<kchibisov>
I'd assume that if it can resize, it's not really tiled?
<kchibisov>
but without tiled state we can't get rid of the shadows.
Moprius has quit [Quit: bye]
<kchibisov>
Maybe sway should always set `maximized` then?
<kchibisov>
And compositor which can resize during tiling can just have `tiled`?
<emersion>
it's not maximized though
<kchibisov>
it's just `must be obeyed` doesn't work for 'us' with tiled.
<kennylevinsen>
for sway, tile resizing is initiated by sway itself, so whether to allow a certain resize is up to sway. What is communicated to the client would be the current size of the tile, and the client in return states its preferred min/max size which can be used as input
<kchibisov>
kennylevinsen: yes, but some compositors can resize tiles when user does it correctly.
<kchibisov>
So if user decided to resize due to some input event, it'll work normally.
<kchibisov>
even when everything is tiled.
<kchibisov>
sway can't do that, because it's `x` limited.
<kchibisov>
Separate `RESIZEABLE` flag sent by compositor could work though.
<kennylevinsen>
I don't understand why that is important. In sway, when you enlarge one tile, it shrinks another. In your case, it grows the viewport and shifts is neighbors. Potato tomato?
<kchibisov>
kennylevinsen: it doesn't shift anything though.
<kennylevinsen>
But if you are not making your windows tiled and using client-side decoration resize, then maybe that is an issue?
<kchibisov>
I don't want `must obey` wording.
<emersion>
kennylevinsen: sway doesn't support client-initiated resize when tiled, kchibisov's compositor does
<kchibisov>
because `must obey` => crash client.
<kennylevinsen>
emersion: yeah I had a feeling that was where the issue lied, but didn't seem obvious from the chat so far :)
<emersion>
i think tiled GTK hides the resize handles?
<emersion>
not sure
<kchibisov>
it is, but window could decide to resize itself by some other event.
<kchibisov>
like you opened a video of a larger size so it tried to account for it.
<emersion>
that sounds like a recipe for disaster tbh
<kchibisov>
Yeah, but the user on the sway issue really does that.
<emersion>
if you start allowing client-initiated resize when tiled, there's a chance you end up with an infinite feedback loop
<kchibisov>
even when I said them the exact same thing.
<emersion>
clients fighting each other for the "correct" size
<kchibisov>
I'll wait a bit for YaLTeR[m] since its his compositor that can handle client initiated non interactive resizes.
<kchibisov>
emersion: this particular compositor doesn't have an issue with fighting, the `x` is unbounded.
<kchibisov>
so they all can grow as large as they can.
<kennylevinsen>
yeah that differs from sway where there is always a correct size
<emersion>
not sure "tiled" is the correct state to use for them
<kchibisov>
emersion: it's still tiled, to some sort.
<emersion>
to me it's maybe tiled on some edges, but not on the resizable edges
<kchibisov>
yeah, but if you don't set tiled you have shadows, etc.
<kchibisov>
it can probably crop though.
<emersion>
shadows are used to allow the user to resize
<kennylevinsen>
I imagine you either have resize handles with shadows or no resize handles - if you go full tiled you'll probably need to do fully server-initated resize.
<kchibisov>
it uses ssd, so...
<kchibisov>
the problem are not with interactive resizes though.
<kchibisov>
but with just submitting larger buffer.
<kchibisov>
besides, the right wording for tiled could be hard.
<kennylevinsen>
yeah and probably wouldn't match your use-case regardless
<kchibisov>
Because you can only apply it when 'top and bottom' are tiled.
<kchibisov>
The same for 'left and right'.
<kennylevinsen>
well maybe not that hard - "if a surface is tiled on two opposing edges, the surface must adhere the window dimension between these edges"
<kennylevinsen>
then you'll be able to enforce height without width
<kennylevinsen>
but you'd get a shadow on that side most likely
gspbirel5687340886706131448762 has joined #wayland
<kennylevinsen>
do we know of compositors that tile fewer than 4 edges today?
<emersion>
i think GNOME does?
<kchibisov>
yeah, snap to corner thing.
<kchibisov>
You still need an edge to resize with CSD.
<kchibisov>
with SSD you don't have to deal with all of that though.
<emersion>
kennylevinsen: that would make sense to me
<emersion>
(the wording you suggested)
<kchibisov>
You'd need a different wording a bit though.
<kchibisov>
Since you know the name of the `opposing` edge.
<emersion>
allowing resize on one axis when both edges are the edge of the screen doesn't make sense, for instance
<emersion>
i'd go as far as saying all compositors i know but niri can't handle client resize when two opposite edges are tiled
<kchibisov>
I mean, the wording is correct, you should just tune it a bit to say `right`/`left`.
<kchibisov>
since each tiled state is separate.
<emersion>
sure
rgallaispou has quit [Read error: Connection reset by peer]
<kchibisov>
I guess the said compositor is not really tiled on the `right` edge.
<kchibisov>
But at the same time, we don't want the shadow, since we can resize on our own.
<kchibisov>
basically what sway does.
agd5f_ has quit []
rgallaispou has joined #wayland
agd5f has joined #wayland
<emersion>
it would be nice to open an issue summing everything up if you have time
<emersion>
maybe jadahl has some insights as well
<emersion>
the way i see it, right now we have two states: either ask the client to draw decos and allow resize on a given edge, either ask the client to not draw decos and not resize on that edge
<emersion>
and you want a third state: no decos, but resize allowed still
<kchibisov>
pretty much it.
<kchibisov>
but it's not like compositors can't crop CSDs.
<emersion>
that really needs to be per-edge as well, because you still can't resize vertically in niri
<emersion>
cropping CSDs kinda works but also doesn't look very good with e.g. border radius
<kchibisov>
emersion: you better not see what hack there's in niri.
<emersion>
("what if i want to have tooth-shaped window borders?!?")
<kchibisov>
kennylevinsen: thx, though, it feels like emersion's patch should go first.
<emersion>
it's fine, either of us can rebase whenever a patch lands
<kennylevinsen>
indeed
<kchibisov>
yeah, it's just the kennylevinsen wording feels like not-complete.
<kchibisov>
in the context of present wording in maximize.
<kennylevinsen>
feel free to add a review comment, it's what MRs are for. :)
nerdopolis has quit [Ping timeout: 480 seconds]
<kchibisov>
btw, what groups on gitlab are for? I was added to wayland group in the past, but I have no idea why.
<kchibisov>
maybe because of the `spam` incedents?
<emersion>
shouldn't be the case
<emersion>
in general we add people to groups when they can contribute better that way, e.g. issue triage or merging or such
<emersion>
you were added by daniels on Mar 30, 2023 for issue triage purposes
<kchibisov>
yeah, it's just it's not like I'm very active on wayland tracker, so I don't use any powers.
<emersion>
please make use of your powers ;)
<kchibisov>
btw, while you're here, why wlroots/sway counts serials for input-method/text-input but never uses them to discard?
<kchibisov>
wlroots also resets the serial on input-method::commit, but I also don't know why. Probably these protocols are just a mess...
<emersion>
i have no idea, sorry
<emersion>
would need to dig into the impl again, it's been ages
<kchibisov>
I just have a dig a while ago.
<kchibisov>
I'm still not sure that I understand how it all supposed to work with serials.
<kchibisov>
especially when gtk commits without active text-input...
kts has quit [Ping timeout: 480 seconds]
<kennylevinsen>
I wonder if it would have been better to just have strict min_size/max_size separate from state...
<YaLTeR[m]>
does this go through now?
<YaLTeR[m]>
yeah it does. At last
<emersion>
actually let me try to allow unregistered users one more time, with a secret channel
lsd|2 has joined #wayland
xyene_ is now known as xyene
that_guy_ is now known as that_guy
<YaLTeR[m]>
I tried to register on OFTC like a year ago, but NickServ wasn't responding to me. So now I tried again and it worked this time so yay
<kchibisov>
emersion: secret should work just fine, given that sr.ht wasn't spammed.
<kchibisov>
Though, some users could target this specific channel.
<emersion>
it's on another network though
<kchibisov>
the spam was there as well, no?
<kchibisov>
the sway was spammed a lot.
<emersion>
hm, didn't pay close attention
<kchibisov>
I know that it had `global pings`.
<emersion>
i'd trust libera staff to be reactive about spam a lot more than OFTC
<kchibisov>
the same global pings I was getting on oftc.
<YaLTeR[m]>
makes me wonder how many more times I thought my messages were going through when they weren't
<kchibisov>
just use irc directly, YaLTeR[m] .
<kchibisov>
always go through.
<emersion>
i wish someone patched the matrix bridge to at least surface back errors properly
<YaLTeR[m]>
don't want to set up a bouncer and keep something open just for 1-2 channels
<kchibisov>
Some forges provide said bouncer with the account.
<kchibisov>
just saying.
<emersion>
^^
<YaLTeR[m]>
this coming from someone explaining to me earlier today how hard it is to log into gitlab :)
<kchibisov>
YaLTeR[m]: it was yesterday.
<YaLTeR[m]>
ah right
<kchibisov>
I mean, asking question on irc without registration is instant.
<kchibisov>
you just type nick and ask.
<kchibisov>
Though, if you just use wayland channel, you don't have to be idle here.
<YaLTeR[m]>
well I read this channel and generally expect to participate occasionally
<kchibisov>
just read the logs on the logger.
<YaLTeR[m]>
anyhow now it works as is, i got registered
<kchibisov>
yeah, some channels ask you to register, but it's kind of rare.
<kchibisov>
The issue is that you can get logged out and I don't think you'll get notified.
<kchibisov>
it's pretty common with oftc to end up like that.
<YaLTeR[m]>
oh that's still a thing?
<YaLTeR[m]>
isn't technology wonderful
<kchibisov>
not with libera, but with oftc it still does happen to me.
<emersion>
thank-you-oftc.jpg
<zamundaaa[m]>
NickServ does tell you. But if you overlook that and type in the channel, your messages just go into the void
<kchibisov>
emersion: we say no to sasl.
<emersion>
;_;
<Company>
it's still weird to me how people try so hard to make a communication protocol designed for transient communication retain everything
<Company>
use a different protocol if you want that
<kchibisov>
yeah, for most projects retain communication is on the git forge.
<Company>
you can also use matrix or discourse or all the closed protocols
<Company>
YaLTeR[m]: while you're here, there was one thing I wanted to ask you
<YaLTeR[m]>
sure
<Company>
YaLTeR[m]: in the video apps you're hacking on, what's the alrgest number of video streams you have playing at the same time?
<YaLTeR[m]>
I load-tested Identity with, like, 12 FullHD 30 FPS streams at once, which ran in realtime
<YaLTeR[m]>
it currently easily runs into a gstreamer crash tho
<Company>
I'm trying to figure out how many subsurfaces we would end up with if we passthrough all the video streams
<Company>
so that ultiamtely I can judge how much I can automate stuff and how much we need API to toggle things
<pq>
Company, what do you worry about with the number of sub-surfaces?
<Company>
pq: dunno extensively yet - but it's coming up sometimes, like wondering about swapchains and their sizes
<Company>
or how hard it is to (de)compose the render tree in GTK
<pq>
Company, hmm. Why would you have your own swapchain for a sub-surface?
<Company>
and how important it is to avoid O(N^2) algorithms
<Company>
because I want to send dmabufs straight to the compositor
<YaLTeR[m]>
I also load test by loading 50+ images at once
<Company>
and I can't do that unless I've gotten my dmabufs accepted as wl_buffers by the compositor
<YaLTeR[m]>
all of those go through gstreamer
<YaLTeR[m]>
so there's that
<Company>
50+ images at once (assuming they're large) will get you bandwidth slowdowns
<pq>
Company, use sub-surfaces when you *get* dmabufs readily, like from a video decoder. I would not use the GPU to create a dmabuf from something that wasn't, but just compose that to the main window image.
i509vcb has joined #wayland
<pq>
IOW, if you need to use a GPU to make a copy of something in order to get a dmabuf you can send to the compositor, maybe it's better to just render that into the window main buffer instead of a sub-surface.
<Company>
pq: well, I still need to get it turned into a wl_buffer (unless I use immediate, but that seems scary, too, with how easy it is to break dmabufs)
<Company>
no, that's not what I'm wondering about
<pq>
no, immediate does not bypass any checks, it just explodes harder
<Company>
yeah, that's what I mean
<Company>
I want stuff to not explode
<Company>
so having a bufferpool set up in advance seems preferable
<Company>
and then shuffling those buffers around from the compositor to the video producer (decoder, camera, whatever)
<pq>
it depends
<pq>
ah, that way, that's cool
<Company>
from GTK's POV I think there's 4 rather different producers of buffers:
<Company>
video decoders (ie usually same hardware as compositor)
<Company>
cameras (different hardware)
<pq>
I was assuming that you let the video decoder allocate its own destination buffers, because... they often want that?
<Company>
VMs (ie virgl, so probably same hardware, but different settings)
<Company>
and OpenGL libraries, that want to render on their own buffer
<Company>
and for those 4 cases, GTK should just operate as a passthrough in default operation
<pq>
right
<Company>
but I'm not quite sure how to achieve that reliably
<pq>
you can't, not reliably
<Company>
like, in conforming to the protocols and APIs those things use
<Company>
and in not exploding various hardware limits and limitations
<pq>
protocol and APIs are the easy thing to get right, it's all the stuff that's not explicitly in APIs that likely fails you
<Company>
protocols and APIs definitely are not the easy part
<pq>
ok, "easiest"
<Company>
hehe
<pq>
I mean, they are defined at least, to some extent :-)
<Company>
yeah, and then they're incompatible
<pq>
but yeah, in the end, everything is trial-and-fallback
<Company>
bufferpools could simplify that quite a bit, because everything gets negotiated and agreed upon and then it's just a question of who uses which buffer of the pool right now
<Company>
basically one big swapchain that goes from producer to compositor - or for direct scanout, potentially straight from webcam to monitor
<pq>
ideally, yes
<Company>
now we just need to do the "easy" part and make all the protocols and APIs do that ;)
<pq>
except you have to negotiate separately for each set of specific devices involved in any particular path
<Company>
yeah, I need to tell the compositor and GTK and GStreamer and pipewire and v4l and they all need to agree on stuff
<Company>
currently my laptop's webcam produces YUYV buffers and my laptop's GPU only accepts NV12
<Company>
so we're almost there!
<pq>
heh
<pq>
when all else fails, CPU conversion! /o\
<Company>
so it's unlikely that for big videos like FullHD with YaLTeR[m] we get >10 videos at once
<Company>
we could easily get >10 videos when somebody scrolls in tiktok, but those won't be fullHD
<Company>
same for videoconferencing
<pq>
I think it's unlike to achieve direct scanout from a webcam anyway, so might as well use a shader to convert. A webcam probably wouldn't use a non-linear format modifier.
<pq>
*unlikely
<Company>
the question with all of that is how far I can push things
<Company>
like, if I get the webcam buffer to the compositor, and the compositor does the compositing/converting, that's better than if I do it
<any1>
Switch the camera to MJPEG and HW decode that?
<pq>
I wouldn't take that as a given.
<Company>
it's the same amount of work in the ideal case, but it's easier to find the ideal case the further downstream the conversion happens
<YaLTeR[m]>
switch the camera to MJPEG except it's a logitech camera which will reset all settings and go to 5 fps max when you do that
<pq>
is it the same amount of work? I think that might depend on the framerates in each software component.
<pq>
but it should be I guess, fully optimized
<Company>
this is the simple case anyway
<pq>
actually, yes, the compositor might be able to do better than the client indeed, especially if the window is partially occluded
shankaru has quit [Read error: Connection reset by peer]
<Company>
if there's any compositing happening (like occlusion or scaling or clipping or subtitles or notification overlays or buttons), you want to do the conversion there
<Company>
but that's another problem (to know the right thing to convert to)
shankaru has joined #wayland
<MrCooper>
pq: FWIW, some GPUs can scan out from linear buffers; apparently Nvidia dGPUs can even scan out from system memory, in contrast to AMD & Intel dGPUs
<kennylevinsen>
hmm that would actually be quite a neat trick, why can't other GPUs do that :(
<pq>
MrCooper, can, but is it a good idea? anyway, sysram vs. VRAM was the difference I was thinking.
<kennylevinsen>
direct scan-out shm buffers!
<pq>
I'd imagine integrated display controllers have even less problems scanning out from sysram.
<Company>
does the Wayland spec specify somewhere what algorithm is used for scaling buffers?
<emersion>
nope
<Company>
hrm
<Company>
I'm wondering about GTK's scaling guarantees wrt passthrough
<Company>
in particular when downscaling videos
<Company>
though I'm not even sure what the best thing to do is when playing a 4k video in a window that's resized to 800x600 or so
<Company>
do you want to just linear downscale it or do you want to create mipmaps first - or do you even want to write a fancy shader that does cubic or lanczos or whatever
<Company>
question for video people I guess
<emersion>
we could have a wayland protocol to set the scaling algo
<emersion>
KMS has stuff like this
<Company>
might be useful to look into
<emersion>
no mimaps though
<Company>
I'm far from an expert on scaling algos anyway
<Company>
so no idea how video people want their videos downscaled
<Company>
emersion: do you ahve a link for docs about that kms property?
<emersion>
the extra modes were removed because no clear use-case iirc
<Company>
what do video players actually do when downscaling?
<Company>
just use LINEAR?
<Company>
run custom shaders?
<DemiMarie>
Company: How big is the performance win from trying to do passthrough instead of just using a shader?
<Company>
mipmap?
<Company>
DemiMarie: there's tons of answers to that question depending on target hardware, app and what you're actually passing through
<Company>
there's 2 potential wins: 1. is not hitting the GPU on mobile devices that have a custom compositing engine
<Company>
when playing back video
<Company>
the video decoder sends its frame straight to the compositing engine, because GStreamer, GTK and gnome-shell all don't need to touch it
<Company>
2. is the case where you run benchmarks in a VM
<Company>
potentially benchmarks that hit the fill rate, so that the framerate goes down if someone does extra copies
<DemiMarie>
Is this because the CPU is bottlenecked on memory bandwidth?
<Company>
no, the GPU is
<DemiMarie>
Anyway, from what others (notably pq) have mentioned here, it seems that the first step is to use shaders because they will work everywhere, and only after that is done look at hardware-specific offloads.
<Company>
GPUs can do billions or trillions of pixels per second
<Company>
but if you run a benchmark you can see the difference between 500fps and 400fps
* DemiMarie
shrugs
<Company>
yeah, the trick is to set up your APIs so that it will magically hit the fast path
<DemiMarie>
Who uses GTK on mobile anyway?
<Company>
that's the wrong question
<Company>
the right question is "Who doesn't use GTK when it's obviously the fastest on mobile?"
<DemiMarie>
Does it support Android?
<Company>
no
<DemiMarie>
Because non-Android Linux is a rounding error
<DemiMarie>
non-Android mobile Linux
<Company>
I mean, it probably coudl rather easily, but nobody cares
<kennylevinsen>
So is desktop Linux, but we're all here aren't we?
<Company>
I'm also not doing this to gain market share
<Company>
I'm doing this so gnome boxes has a higher framerate than native Windows
<DemiMarie>
How will that even be possible?
<DemiMarie>
kennylevinsen: desktop Linux is a development environment. For me at least, my phone is not a development environment, and Qubes OS hasn’t been ported to it yet.
<Company>
because the native Windows has a shitty gl driver and the VM uses virgl
<DemiMarie>
which hardware?
<Company>
Intel is known for shitty GL drivers on Windows