Opened 5 years ago

Last modified 4 weeks ago

#152 new defect

Strange behavior when actual size is different from requested size

Reported by: Philip Linde Owned by: pulkomandy
Priority: minor Milestone: 2.10
Component: GrafX2 Version: 2.6
Keywords: Cc:


It seems that GrafX2 will request a specific window size on startup. If this size is different from (or at least greater than) the actual size that the window gets, GrafX2 will still assume that the requested size is correct and draw its UI in only that area.

This is a problem when using tiling window managers, which frequently give windows different sizes than requested to fit them into the layout. Ideally, GrafX2 should request a size and after that check the actual size.

Cause a window resize event, which redraws the UI for the new size.

Change History (11)

comment:1 by Philip Linde, 5 years ago

This may be a bug either in SDL or the window manager I use. There is already a check in sdlscreen.c for whether the reported size matches the requested size. This check passes on my system whether the actual window size is different from the requested size or not. I'll have a closer look.

comment:2 by Thomas Bernard, 5 years ago

can you test with the latest sources ?
And alse report which Window Manager you use, and if you tested with the SDL / SDL2 and/or X11 backend.
To build with a specific backend :

$ API=sdl2 make
$ API=x11 make

sdl 1.2 is the default

comment:3 by Philip Linde, 5 years ago

I have built binaries with each of the backends from the latest master commit, and they all exhibit slightly different behavior:


  1. Start in a large window
  2. Exit
  3. Start in a small window
  4. Close splash screen
  5. Resize the window

X11: On step 3, starts up with GUI cropped to fit smaller window. After step 4, the GUI is fit to the window as it should be.

SDL: On step 3 starts up with GUI cropped to fit smaller window. No improvement after splash screen. Step 5 does however cause the GUI to fit to the window.

SDL2: On step 3 starts out with the GUI compressed to fit inside the smaller window (non-square pixels). After step 4 the GUI is fit to the window as it should be.

Also noting that while the splash screen is open, window size events do not cause a re-fit of the whole GUI. It seems that this may partially be causing the issue. Maybe a re-fit from requested size to actual size rolls in as a window event that's ignored because of the splash screen. I will have a look tonight to see if it's something I can fix.

comment:4 by PulkoMandy, 5 years ago

Ah, right, the grafx2 window is not resizable while one of the internal windows is open. Fixing this is not trivial with the way the windows are implemented currently (as they have to save and restore the background they are hiding)

In the old SDL2 branch (which was never merged) I had started reimplementing them to open actual OS windows (not possible with SDL1 but easy with the other backends), maybe we should revisit that

comment:5 by yrizoud@…, 5 years ago

Actually I continued the old sdl2 branch with SDL_Surfaces for these, pasted into the single window.
Extra "UI windows" would allow more freedom of moving things, but then I think there's the issue that the custom Grafx2 mouse cursor will be clipped when it overlaps the borders. Or it needs a different way to render the mouse cursor.

comment:6 by Philip Linde, 5 years ago

As far as I'm concerned, it's not a problem that the window is fixed during the splash screen. After the splash screen, if there was a window size event, it seems to trigger a redraw anyway.

Something that I noticed now, with the SDL back-end, is that the screen is adjusted to the correct size on a mouse click event. Not on mouse motion, window focus or button press event, only on click. Possibly there is some handling of Resize_width and Resize_height in click events that should also be triggered every time a window closes.

comment:7 by Philip Linde, 5 years ago

By button above I mean keyboard, of course

comment:8 by PulkoMandy, 4 years ago

Milestone: 2.8

comment:9 by PulkoMandy, 3 years ago

Milestone: 2.82.9

comment:10 by PulkoMandy, 4 weeks ago

Milestone: 2.93.0

Move tickets to next release

comment:11 by PulkoMandy, 4 weeks ago

Milestone: 3.02.10

Move tickets to next milestone after release

Note: See TracTickets for help on using tickets.