00:47 danieldg: Company: if you don't use any fractional-scale stuff, it just goes at (1,1) in the scale-2 copy of your window, which is then scaled down
00:48 danieldg: Company: see https://wayland.app/protocols/fractional-scale-v1 for what happens if you do use viewporter - basically 'whatever the compositor wants'
00:49 danieldg: but if you put it at (4,4) then it should be fine
00:52 danieldg: if I were writing a compositor, I'd round subsurfaces to an integer alignment of true pixels if they use viewporter to make buffers with true pixels; but I'm not one
01:41 Company: danieldg: I'm trying to think about how to implement a video overlay
01:42 Company: for GTK
01:42 Company: and that kinda requires that I get pixel-exact positioning or the rendering is gonna look wrong
01:43 danieldg: put both at (0,0) and there's no issue
01:46 Company: sure
01:46 Company: but I'm talking about making it part of the toolkit
01:47 Company: so that when somebody puts a video widget somewhere, it gets automatically put in an overlay
01:50 danieldg: you could still start the subsurface at a known-integer point and then just have it transparent and no-input outside the 'real' region
01:51 danieldg: that seems to be the only way to get guaranteed correctness atm
01:51 Company: can't do that because I want to attach() the video buffer directly
01:52 Company: and afaics the attachment point is always top left
01:52 danieldg: viewporter set_destination
01:52 danieldg: oh, sorry
01:52 Company: that's just width/height, no?
01:53 danieldg: yeah
01:54 zamundaaa[m]: If there's demand, I could revive my fractional-scale-v2 MR again, which works properly with subsurfaces
01:54 danieldg: Company: wl_surface::offset
01:54 DemiMarie: zamundaaa[m]: There is demand from me!
01:55 DemiMarie: For just this reason
01:55 DemiMarie: Company: this is a good reason for fractional-scale-v2
01:55 danieldg: fixing the protocol migtht be better, yeah
01:58 Company: I'm not far enough into this process to actually know what I need
01:59 Company: peeling the dmabuf out of the render command tree is a fun task in itself
02:00 Company: one of the things that is rather relevant though - especially with fractional scaling - is the ability to express coordinates unscaled, to get pixel alignment
02:02 danieldg: yeah, if the protocol were being designed with fractional scale in mind, all integers would be in 1/120 pixel units
02:02 Company: especially because the whole rendering pipeline needs to operate on pixels
02:02 danieldg: it's not like anyone needs windows a billion pixels wide
02:02 Company: for things like glScissor() or so
02:05 Company: ugh, I'm just realizing that this all doesn't work
02:05 Company: because I don't want the window to resize when it moves outputs
02:06 Company: but if I move from a 100% to a 125% output, this might be necessary
02:18 danieldg: yes, if the actual pixel size changes, you'll need to render frames at that resolution
02:19 Company: that's not the point
02:20 Company: the point is that I can attach a subsurface at (1,1) with 100% scale but not with 125% scale
02:20 Company: so something will happen to that subsurface if it moves outputs, even if the app doesn't do anything
17:55 Company: emersion: why did you create https://wayland.app/protocols/single-pixel-buffer-v1 ? What were the use cases?
17:59 DemiMarie: Company: fractional-scale-v2 does what you seem to be asking for
17:59 DemiMarie: fractional-scale-v1 does not.
18:11 Company: I'm not even quite sure what fractional-scale-v2 is even doing
18:12 Company: do the compositor and client potentially use a different coordinate system there?
18:15 Company: also, is that 8.24 or 24.8 fixed point?
18:15 Company: and why is it not just using wl_fixed?
18:19 DemiMarie: I’m not zamundaaa, but my understanding is that fractional-scale-v2 changes the coordinate system used by the client **and** the compositor, so that physical pixels are used instead of logical ones. This is what allows subsurfaces to be aligned on arbitrary physical pixel boundaries.
18:20 Company: it looks to me like they both change coordinates on their own
18:20 Company: so everyone talks in their favorite coordinate system
18:21 DemiMarie: that is rather weird
18:21 Company: yeah, that's why I'm wondering
18:21 DemiMarie: Personally, I would have all coordinates be double-precision floating point with a pixels-per-inch scale factor
18:21 Company: I'm sure that would totally not ever cause rounding issues at all
18:23 DemiMarie: This assumes that window placement isn’t a hot path, so it is done on the CPU and not on the GPU where double precision might not be available.
18:23 Company: the other issue that neither protocol solves is that moving the surface from one output to another output might change the desired rendering scale
18:24 Company: at which point pixel alignment will be busted anyway
18:24 Company: and I think using floating point is always a bad idea - no matter what precision - when talking about pixels
18:25 DemiMarie: If you care about multiple outputs my non-expert opinion is that one should just be using physical coordinates and explicit output identifiers
18:25 DemiMarie: In other words, applications would need to know which output they are on and render to each monitor separately.
18:26 Company: you can be on >1 output though
18:26 DemiMarie: exactly
18:26 DemiMarie: and those outputs will (in the general case) have different resolutions
18:26 Company: and this isn't about rendering (only) but about placement of subsurfaces, too
18:27 DemiMarie: I don’t see any way to have physical-pixel-perfect rendering and subsurface placement without informing applications about the exact portion of each surface that is on each screen
18:27 DemiMarie: In other words, applications would need to render to each output separately.
18:28 DemiMarie: That’s the X11 model IIUC
18:28 Company: the X11 model is "yolo"
18:29 DemiMarie: What do you want to happen when a surface is split between outputs?
18:29 Company: I don't know
18:29 DemiMarie: In that case I would start with the simpler 1-output case
18:30 Company: what I know I want to do is have a dmabuf that I don't touch
18:30 Company: because it comes from the video decoder/webcam/whatever and I just want to pass it through
18:31 Company: and then I want to draw my window chrome (titlebar, buttons, whatever) around/on top of it
18:31 DemiMarie: Can you do that at all without knowing where the dmabuf will end up?
18:31 Company: no, not really
18:31 DemiMarie: To use a concrete example: do you want to use peer-to-peer DMA to transfer data from a webcam to a discrete GPU?
18:31 Company: it will look glitchy
18:32 Company: ideally I want to not touch the GPU at all
18:32 Company: and use DMA between the webcam and the compositing hardware
18:32 DemiMarie: I meant “where” as in “which physical device”, not ”where on the screen”
18:32 DemiMarie: Are there devices where the compositor can be a DMA target?
18:33 Company: there's hardware layers on various mobile chips, though I'm no expert on which ones and how
18:33 DemiMarie: but are those layers memory that one can DMA to?
18:33 Company: dunno
18:34 Company: the important part is that the GPU isn't involved
18:34 Company: and I know that that works
18:34 DemiMarie: Do you have the simple case (shaders) working?
18:34 DemiMarie: Direct scanout of a dmabuf is going to be very platform-dependent
18:34 Company: in the simple case we just compose the dmabuf into our rendering pipeline
18:35 DemiMarie: 36
18:35 DemiMarie: whoops, did not mean to send that
18:47 zamundaaa[m]: <Company> "so everyone talks in their..." <- Yes, ish. The thing is that Wayland is asynchronous, so if the compositor would just tell the client "the new scale is 2", the client will not instantly know about the new scale and take that into account in its requests
18:48 zamundaaa[m]: So you need some way for each side to say what its messages mean, independently of the other side
18:49 zamundaaa[m]: Ideally the client should always switch to the compositor's coordinate space as soon as it receives the event about the changed ideal scale. And ofc it should also re-render its surface with that ideal scale asap
18:50 Company: yeah, in the usual case that's what should happen
18:50 Company: but I'm trying to figure out how to trick the system
18:51 Company: I think what I'm after is a way to place my subsurface relative to the pixels of the buffer I submit
18:51 zamundaaa[m]: Yes, that is what the protocol allows you to do
18:52 Company: so if the buffer has scale 125% I want to place the subsurface relative to that
18:52 zamundaaa[m]: If you say you're using the scale 125% as the coordinate system for the parent surface, the subsurface positions will be in that coordinate system
18:53 Company: I'm not even sure what coordinate system the parent surface is using
18:53 Company: what I'm interested in is the scale that the buffer is using
18:53 Company: which is kinda evil, because now I want to place the subsurface using that
18:54 zamundaaa[m]: If you set the coordinate system of the surface to scale 125% and attach a buffer, the buffer size will be scaled by that as well
18:54 Company: by default, yeah, but I'm using wp_viewport
18:55 Company: and we actually use 2x scale for rendering on 125% surfaces currently (though that is about to stop)
18:56 zamundaaa[m]: I'm talking about my protocol, not current Wayland
18:56 Company: I'd imagine even with your protocol and wp_viewport, that could happen
18:57 zamundaaa[m]: What could happen?
18:57 Company: that the scale I'm using for the toplevel surface is different from the buffer scale
18:58 Company: but I could apply the buffer scale to the subsurface
18:59 Company: at that point it depends on which functions are actually affected by the scale
19:00 Company: like, is subsurface.set_position() affected by the subsurface's scale or by the surface's scale?
19:04 zamundaaa[m]: The subsurface position is a parent surface state, so it's affected by the parent surface's scale
19:05 Company: but I can of course use offset instead of position
19:06 Company: and offset is subsurface's state
19:10 DemiMarie: What could be done is to send a message to the compositor and wait for the reply before doing anything further.
19:14 zamundaaa[m]: why would you wait for a reply?
23:25 DemiMarie: zamundaaa: to ensure that the new coordinates have taken effect
23:46 daniels: no, that doesn’t fix it
23:46 daniels: the only two ways you can eliminate race conditions are to have only one side which can ever change co-ord systems, or to use a serial/epoch system so you can detect desync
23:47 daniels: without either of those, roundtrips only add latency without solving the problem
23:48 daniels: Company: spb exists so we don’t have to have 1x1 shm buffers to do e.g. letter/pillarboxing