wm_event_do_handlers calss this function for every event, I'd prefer to avoid setting DPI for every event.

Have not checked closely, but some potential solutions:

• Move this into wm_window_set_drawable?
• Call wm_window_reset_drawable on GHOST_kEventWindowDPIHintChanged or other relevant events?

Will revisit this soon as a possible 3.0 target

Not sure if it is the same issue, but https://developer.blender.org/T86466 seems to be related.

At least it is also caused by different monitor DPIs

Note that the only reason I have not worked on this further is that I have been unable to recreate this error condition at will. We still get reports that this still occurs of course, but I need an easily reproducible situation in order to examine, test, and correct.

It's not clear to me that removing it from wm_window_make_drawable is safe. That's called from more than just the wm_draw_update, for example when initially creating windows.

I would instead change the implementation of wm_window_make_drawable to:

if (win != wm->windrawable && win->ghostwin) {
  ...   
  wm_window_set_drawable(wm, win, true);
}

if (win->ghostwin) {
  /* this can change per window */
  WM_window_set_dpi(win);
}

! In D10483#363743, @Brecht Van Lommel (brecht) wrote:
It's not clear to me that removing it from wm_window_make_drawable is safe. That's called from more than just the wm_draw_update, for example when initially creating windows.

It can be removed from wm_window_make_drawable when it is added to wm_draw_update, which is always called including when initially creating windows.

! In D10483#363743, @Brecht Van Lommel (brecht) wrote:
I would instead change the implementation of wm_window_make_drawable to:

if (win != wm->windrawable && win->ghostwin) {
  ...   
  wm_window_set_drawable(wm, win, true);
}
 
if (win->ghostwin) {
  /* this can change per window */
  WM_window_set_dpi(win);
}

Doing only that is enough to fix this issue, and is also my very first version of this patch from Feb 20 2021. Your reply back then was that "wm_event_do_handlers calls this function for every event, I'd prefer to avoid setting DPI for every event." And you were correct. Not only is this called between windows (good) but it is also called with events.

@Brecht Van Lommel (brecht) - Anyway, if you can't figure why windrawable gets out of sync with the DPI...

That part is easy, but I find hard to explain because I am unclear on some of the intent of these functions...

We have wm_window_set_drawable, wm_window_clear_drawable, wm_window_reset_drawable and wm_window_make_drawable

It is only wm_window_MAKE_drawable that calls WM_window_set_dpi, but only if not already drawable. However we call wm_window_SET_drawable all over the place. So a window can be drawable and not have had that function called.

So we are doing the actual drawing in wm_draw_update, going one window at a time. if the first and last monitors differ in dpi you can have that loop start with a window that is drawable and has a different dpi from the last in the list. wm_window_make_drawable is called and does not update dpi because it is already drawable. Bam, it draws too large.

The smallest change to fix this would be to call wm_window_clear_drawable in that function:

void wm_draw_update(bContext *C)
{
...
  LISTBASE_FOREACH (wmWindow *, win, &wm->windows) {
...

      wm_window_clear_drawable(wm);

      /* sets context window+screen */
      wm_window_make_drawable(wm, win);
...

or perhaps a bit more correct to put that before the loop

void wm_draw_update(bContext *C)
{
...

  wm_window_clear_drawable(wm);

  LISTBASE_FOREACH (wmWindow *, win, &wm->windows) {
...
      /* sets context window+screen */
      wm_window_make_drawable(wm, win);
...

I think the ideal fix for this ensures windrawable and DPI is always matching, rather than fixing wm_draw_update specifically. Event handling and operators can use the DPI too.

wm_window_set_drawable is called in 3 places, and they seems correct to me:

• wm_window_ghostwindow_add sets the DPI
• wm_window_make_drawable sets the DPI
• wm_window_reset_drawable does not change the window, so no DPI change needed

I think probably the thing that makes it go out of sync is the calls to WM_window_set_dpi without corresponding wm_window_set/make_drawable. Probably some calls can be removed, or replaced by a function that returns DPI rather than changing global state.

It would be good to do that kind of refactor, but I'm ok with the simpler fix I proposed in my previous comment.