#18839: Implement wxEVT_DPI_CHANGED for wxOSX

[wxTrac]

#18839: Implement wxEVT_DPI_CHANGED for wxOSX
-------------------------+-------------------------
Reporter: vadz | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: wxOSX | Version: dev-latest
Keywords: HiDPI | Blocked By:
Blocking: | Patch: 0
-------------------------+-------------------------
As
[https://developer.apple.com/library/archive/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/CapturingScreenContents/CapturingScreenContents.html
described here], we can listen to
`NSWindowDidChangeBackingPropertiesNotification` and generate
`wxEVT_DPI_CHANGED` from there to allow wx apps react to moving between
displays with different scaling factors.

--
Ticket URL: <https://trac.wxwidgets.org/ticket/18839>

[wxTrac]

#18839: Implement wxEVT_DPI_CHANGED for wxOSX

--------------------------+------------------------
Reporter: vadz | Owner: csomor
Type: enhancement | Status: accepted

Priority: normal | Milestone:
Component: wxOSX | Version: dev-latest

Resolution: | Keywords: HiDPI

Blocked By: | Blocking:
Patch: 0 |

--------------------------+------------------------
Changes (by csomor):

* owner: => csomor
* status: new => accepted


Comment:

I'll add that

--
Ticket URL: <https://trac.wxwidgets.org/ticket/18839#comment:1>

[wxTrac]

#18839: Implement wxEVT_DPI_CHANGED for wxOSX

--------------------------+------------------------
Reporter: vadz | Owner: csomor
Type: enhancement | Status: accepted

Priority: normal | Milestone:
Component: wxOSX | Version: dev-latest

Resolution: | Keywords: HiDPI

Blocked By: | Blocking:
Patch: 0 |

--------------------------+------------------------

Comment (by csomor):

what should the DPI values be ? scaled multiples of the 'original' 72 dpi
?

and actually the logical DPI does not change, if I look at the handlers in
wx, they are looking the dpis and recalculating window sizes, logical
coordinates for drawing, which would be wrong on macOS, unless we add
content scale fields to the event and keep dpi as it is

the only place where it would be important for macOS/iOS would be the
opengl controls

--
Ticket URL: <https://trac.wxwidgets.org/ticket/18839#comment:2>

[wxTrac]

#18839: Implement wxEVT_DPI_CHANGED for wxOSX

--------------------------+------------------------
Reporter: vadz | Owner: csomor
Type: enhancement | Status: accepted

Priority: normal | Milestone:
Component: wxOSX | Version: dev-latest

Resolution: | Keywords: HiDPI

Blocked By: | Blocking:
Patch: 0 |

--------------------------+------------------------

Comment (by vadz):

Thanks for looking at this!

DPI values should be just the real DPI before and after the change. E.g.
when moving from "normal" to "high DPI" display, the old one would be 72
and the new one 144. It's a bit annoying that normal value under Mac is 72
and not 96 as everywhere else, but I think it's mostly/only the ratio of
them which counts. In fact, as I think I've already mentioned in one of
our discussions with Maarten before, I think we should add
`wxDPIChangedEvent::Rescale()` method using `wxMulDivInt32()` to adjust
the value used with the old DPI to the new one.

It's true that under Mac we don't have to do manual relayout (see #18649),
but I think it's still important to get this event for any kind of
dynamically generated content, e.g. AUI art provider icons would need to
be recreated when DPI changes etc.

--
Ticket URL: <https://trac.wxwidgets.org/ticket/18839#comment:3>

[wxTrac]

#18839: Implement wxEVT_DPI_CHANGED for wxOSX

--------------------------+------------------------
Reporter: vadz | Owner: csomor
Type: enhancement | Status: accepted

Priority: normal | Milestone:
Component: wxOSX | Version: dev-latest

Resolution: | Keywords: HiDPI

Blocked By: | Blocking:
Patch: 0 |

--------------------------+------------------------

Comment (by csomor):

I'm not thinking about not triggering it, I have it already implemented
it's just a few lines after all, but I'm worried about setting the dpi
values, if we agree that osx is dpi-independent, then this should not
change, because otherwise things like this in datavgen will run haywire


{{{
int minWidth = m_cols[i]->GetMinWidth();
if ( minWidth > 0 )
minWidth = minWidth * event.GetNewDPI().x /
event.GetOldDPI().x;
m_cols[i]->SetMinWidth(minWidth);

}}}

--
Ticket URL: <https://trac.wxwidgets.org/ticket/18839#comment:4>

[wxTrac]

#18839: Implement wxEVT_DPI_CHANGED for wxOSX

--------------------------+------------------------
Reporter: vadz | Owner: csomor
Type: enhancement | Status: accepted

Priority: normal | Milestone:
Component: wxOSX | Version: dev-latest

Resolution: | Keywords: HiDPI

Blocked By: | Blocking:
Patch: 0 |

--------------------------+------------------------

Comment (by vadz):

Code like this probably needs to be taken inside `#ifndef
wxHAVE_DPI_INDEPENDENT_PIXELS`. Although in this particular case it seems
that we don't need to do anything at all on DPI change, i.e. row height
cache probably doesn't need to be recomputed neither, and then the entire
handler becomes completely unnecessary. I.e. even if we implemented my
`Rescale()` suggestion from above and made it do nothing under Mac, it
would still be completely unnecessary to even run this loop there.

I don't see any elegant way to handle this :-( Maybe we really need 2
events, one that would be generated and handled only under non-{Mac,GTK 3}
platforms and another one which would be generated everywhere but need to
be handled only when you really need to react to the physical pixels DPI
change?

--
Ticket URL: <https://trac.wxwidgets.org/ticket/18839#comment:5>

[wxTrac]

#18839: Implement wxEVT_DPI_CHANGED for wxOSX

--------------------------+------------------------
Reporter: vadz | Owner: csomor
Type: enhancement | Status: accepted

Priority: normal | Milestone:
Component: wxOSX | Version: dev-latest

Resolution: | Keywords: HiDPI

Blocked By: | Blocking:
Patch: 0 |

--------------------------+------------------------

Comment (by csomor):

I think these questions all boil down to the same things, they are all
connected, it all means the physical backing has changed, however this is
mapped onto what ... let's take the discussion to the mailing list

--
Ticket URL: <https://trac.wxwidgets.org/ticket/18839#comment:6>

[wxTrac]

#18839: Implement wxEVT_DPI_CHANGED for wxOSX

--------------------------+------------------------
Reporter: vadz | Owner: csomor
Type: enhancement | Status: accepted

Priority: normal | Milestone:
Component: wxOSX | Version: dev-latest

Resolution: | Keywords: HiDPI

Blocked By: | Blocking:
Patch: 0 |

--------------------------+------------------------

Comment (by csomor):

https://github.com/wxWidgets/wxWidgets/pull/1984

--
Ticket URL: <https://trac.wxwidgets.org/ticket/18839#comment:7>

[wxTrac]

#18839: Implement wxEVT_DPI_CHANGED for wxOSX

--------------------------+------------------------
Reporter: vadz | Owner: csomor

Type: enhancement | Status: closed

Priority: normal | Milestone:
Component: wxOSX | Version: dev-latest

Resolution: fixed | Keywords: HiDPI

Blocked By: | Blocking:
Patch: 0 |

--------------------------+------------------------
Changes (by vadz):

* status: accepted => closed
* resolution: => fixed


Comment:

As this was merged in 56177cb5a3c33a898f5848cf6cf0e084d43560f5, I think
this one can be closed now.

--
Ticket URL: <https://trac.wxwidgets.org/ticket/18839#comment:8>