OpenGL renderer glitches on window scale (MacOS, retina)

[ytaras]

If I try to run simple example (using default OpenGL renderer) and try to resize game window, it acts weird. With original size render area take 100% of the window. If I shrink window vertically, render area shrinks non in proportion, leaving some of the window blank. On the other hand, if I resize window to be larger, drawing area doesn't fit into window. Same happens to horizontal scaling.
I think is caused by retina display on my laptop, as I've seen other issues in tracker related to hdpi display.
Here's an example of drawing 80x50 red area and resizing a window:

Source code for example:

use bracket_lib::prelude::*;
struct State {
}

impl GameState for State {
    fn tick(&mut self, ctx: &mut BTerm) {
        ctx.cls();
        ctx.fill_region(Rect::with_size(0, 0, 80, 50), ' ' as u8, RGB::named(BLACK), RGB::named(RED));
    }
}
fn main()  {
    let context = BTermBuilder::simple80x50()
        .with_title("Hello RLTK World")
        .build();
    let gs: State = State {
    };

    main_loop(context, gs)
}

[ytaras]

Have just verified same issue with latest (master) version of code

[thebracket]

I wish I had a Mac to test on; I can't get the same results on Windows or Linux messing with display scaling. Does it also do that on the included examples?

[ytaras]

Unfortunately it does.
If that helps - it works even for native_gl example, including custom-drawn triangle:

Do you have any suggestions how I could gather required information which helps to debug?
I've looked into window sizes - it has scaling factor 2.0, and physical size at start is width: 1280, height: 820 by default (for simple80x50() + 8x8 font). If I resize a window, I see nothing suspicious in a window size as well.

[djmittens]

I am also affected by this plague, is there any workarounds?

[thebracket]

Oh no, I thought this was fixed. Are you using the crate or the github version? I don't have a Mac to test on, but I'll see what I can do.

[djmittens]

I am following the rogue like tutorial and i am using the following version of rltk:

[dependencies]
rltk = "0.8.1"

Example code having this issue:
https://github.com/djmittens/tetra

[garritfra]

Just checking in to see if there's any progress on this? I've got the same issue, but I'm glad that it only seems to affect MacOS.

[singalen]

I tried debugging it, but didn't get very far, as my Rust is very basic.
Would love to get some clue where to look.

[thebracket]

Just getting back into the swing of things after being unwell and then having to care for my mother being unwell. It does look like a DPI issue, I have a few ideas - I'll do some digging and post results. Trying to avoid having to buy a Mac to test with!

[singalen]

Happy to help to diagnose it, I run into it each time. I also cannot build bracket-lib with Metal (#188).
Hope you family gets well.

[thebracket]

Now that's interesting. Updating glutin and winit has given me similar behavior on Windows! It looks like when PhysicalSize returns now, it already has the scale factor applied to it. I just tested on Windows, and removing the dpi_size division was required to make it work properly. I'm now testing that in a Linux VM.

Update: The fix worked with display scaling on Ubuntu X/11. Weird stuff happened on Ubuntu/Wayland - but it often does, so I'll worry about that as a separate issue.

The code I'm testing is with the latest head (to update dependencies; do a clean first). Then in bracket-terminal/src/hal/native/mainloop.rs:

fn on_resize(
    bterm: &mut BTerm,
    physical_size: glutin::dpi::PhysicalSize<u32>,
    dpi_scale_factor: f64,
    send_event: bool,
) -> Result<()> {
    INPUT.lock().set_scale_factor(dpi_scale_factor);
    let mut be = BACKEND.lock();
    if send_event {
        bterm.resize_pixels(
            physical_size.width as u32,
            physical_size.height as u32,
            be.resize_scaling,
        );
    }
    let gl = be.gl.as_ref().unwrap();
    unsafe {
        gl_error_wrap!(
            gl,
            gl.viewport(
                0,
                0,
                physical_size.width as i32,
                physical_size.height as i32,
            )
        );
    }

[thebracket]

I just committed the code that gives sensible behavior on Windows and Ubuntu/X11. Would someone mind giving this a go on a Mac for me, please?

[singalen]

It got much better now, thank you!
The default size is spot on (before it had offset on the left and was off the window on the right), but resize still misbehaves a bit. Looks like there's an extra multiplier.

[thebracket]

That's progress. :-) I suspect I can find a couple of other uses of DPI that are causing that issue. I'll go digging in a minute. (The bouncy gif is trippy!)

[thebracket]

Found the downside of the above fix - it messes up mouse position calculation after the window is resized. I think I know how to get this fixed, though - it may be tomorrow, I'm running short of time for the day. Thanks for the help - I'm pretty sure I've narrowed it down.

[thebracket]

Ok, I've taken the changes that helped earlier and gone a little further with them - and completely rewritten the mouse positioning section. This should help with the scaling issues. On my Ubuntu/X11 and Windows installations it's dead on the money both initially and after a resize on various scaling settings (tested 125%, 150%, 200%). So I'm really hopeful that this will help with the OS X issues.

[singalen]

Thank you very much!
Will try the mouse as soon as I can. So far, resizing the window still messes up the scale like on the image before 8(

[thebracket]

Progress! I found someone else who had suffered a similar problem, and applied their fix. Turned out to be two lines of code! It now scales correctly on everything I have available to test with - Windows, Ubuntu 20.1/X11, Ubuntu 20.1/Wayland. That's the first time Wayland has look right in a few winit releases, which is a good sign. :-)

[thebracket]

A friend (Red blob games on the roguelikedev discord) informs me that it is working really well on his Mac now. :-)

[thebracket]

I've now had two people tell me that this is working correctly now. So I'm closing this issue - please re-open if the plague returns!