**** BEGIN LOGGING AT Fri Nov 04 02:59:56 2022 **** BEGIN LOGGING AT Fri Nov 04 06:03:10 2022 Nov 04 12:02:41 Morning! Nov 04 12:02:53 Tofe: Does that actually help or not, not sure I understand what you're trying to do currently Nov 04 17:43:32 Herrie: well, what I see is that I finally have "something" that differs between a scaled app and a non-scaled app Nov 04 17:44:09 I also see that the scaling is applied to the window's geometry, while it shouldn't, so I have a visible bug Nov 04 17:45:27 And third, this "too big" window could explain why the content isn't scaled: it is actually scaled, but within an upscaled window, which is later on resized down to the screen size Nov 04 17:45:54 TL;DR: it's a mess, but there's a lead Nov 04 17:48:43 Tofe: Yes some leads indeed Nov 04 17:49:20 Could be sloppy code at LG side somehow, it might matter less for their use cases Nov 04 17:50:14 I think it's something that the wayland client of WAM does; but I didn't find where, so far Nov 04 17:50:40 debugging WAM is doable, but the wayland stuff is mainly in webruntime, and that's another story Nov 04 21:16:04 So, by applying a scaling in WebAppWindowBase::InitWindow, I got the scaling fixed -- but now it's scaled twice for JustType :/ Nov 04 21:28:38 Now trying a variant of the fix, where DesktopNativeWidgetAura::SetBounds doesn't apply any scaling (i.e. bounds are already in pixels) Nov 04 21:33:03 nope, justtype is still scaled twice. A bit weird. Nov 04 21:34:24 Maybe JustType is "wrong" and others correct? Nov 04 21:34:34 could be Nov 04 21:35:49 From what I understood, we initialize the window size in pixels, as usual; but down in webruntime, the size is taken as "device independent pixels", i.e. it needs to be scaled to match the actual pixels Nov 04 21:36:27 my second version of the fix eliminate this additional conversion, it's a nice one-liner Nov 04 21:37:09 then the question remains, what happens with justtype... **** ENDING LOGGING AT Sat Nov 05 02:59:57 2022