<dnkl>
sevz: got it, but unfortunately most compositors fail to emit _any_ kind of event before the window is mapped. If we simply defaulted to 1, we'd display one frame with the wrong scale, causing visual "glitches"
<dnkl>
so, we want to guess the scale ourselves, until we do receive an event (preferred fractional, preferred surface, or just output event in case of an older compositor)
sentriz has quit [Ping timeout: 246 seconds]
sentriz has joined #foot
<kode54>
was there an error with this that would have caused some compositors to get stuck displaying a nearest neighbor scaled 1.0 scale window on a 2.0 scale output?
<dnkl>
no, nothing would get stuck. But if we use the default 1.0 preferred scale, on a 2.0 output, the window would glitch - one frame would be displayed with the wrong scale
<kode54>
ah
<kode54>
here, I've had weird issues on some compositors where the window would get stuck displaying 1.0 scale on my 2.0 output if the output scale reset momentarily
<kode54>
seems this happens when my primary monitor disconnects, which it does when DPMS is powered back on again
<kode54>
it resets to its default mode of 3840x2160 scale 1.0
<kode54>
before instantaneously resetting to my configured 2.0 scale
<toast>
the two genders of Wayland programs: not a single wrong frame (good), every frame is wrong (google)
<sewn>
toast: you didn't say two sexes so does that mean there can be inbetweens and nonbinaries
<toast>
sewn: gender is not sex, and Wayland programs are not people; this is a common joke format among trans communities ;)
<toast>
(anyway yes it does)
<dnkl>
kode54: what you'd do is run WAYLAND_DEBUG=1 and check if the compositor forgets to send an event
<dnkl>
(preferred fractional scale, preferred buffer scale, or output enter)
sefidel has quit [Remote host closed the connection]