bsnes/hiro/windows/monitor.cpp

55 lines
1.5 KiB
C++
Raw Normal View History

#if defined(Hiro_Monitor)
namespace hiro {
struct MonitorInfo {
Update to v104r13 release. byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
uint monitor = 0;
uint primary = 0;
Geometry geometry;
Update to v104r13 release. byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
uint index = 0;
};
static auto CALLBACK MonitorEnumProc(HMONITOR hMonitor, HDC hdcMonitor, LPRECT lprcMonitor, LPARAM dwData) -> BOOL {
MonitorInfo& info = *(MonitorInfo*)dwData;
MONITORINFOEX mi{};
mi.cbSize = sizeof(MONITORINFOEX);
GetMonitorInfo(hMonitor, &mi);
string displayName = (const char*)utf8_t(mi.szDevice);
Update to v104r13 release. byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
if(displayName.beginsWith(R"(\\.\DISPLAYV)")) return true; //ignore pseudo-monitors
if(mi.dwFlags & MONITORINFOF_PRIMARY) info.primary = info.index;
if(info.monitor == info.index) {
info.geometry = {lprcMonitor->left, lprcMonitor->top, lprcMonitor->right - lprcMonitor->left, lprcMonitor->bottom - lprcMonitor->top};
}
info.index++;
Update to v104r13 release. byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
return true;
}
Update to v104r13 release. byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
auto pMonitor::count() -> uint {
return GetSystemMetrics(SM_CMONITORS);
}
Update to v104r13 release. byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
auto pMonitor::dpi(uint monitor) -> Position {
HDC hdc = GetDC(0);
auto dpiX = (float)GetDeviceCaps(hdc, LOGPIXELSX);
auto dpiY = (float)GetDeviceCaps(hdc, LOGPIXELSY);
ReleaseDC(0, hdc);
return {dpiX, dpiY};
Update to v104r13 release. byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
}
auto pMonitor::geometry(uint monitor) -> Geometry {
MonitorInfo info;
info.monitor = monitor;
EnumDisplayMonitors(nullptr, nullptr, MonitorEnumProc, (LPARAM)&info);
return info.geometry;
}
Update to v104r13 release. byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
auto pMonitor::primary() -> uint {
MonitorInfo info;
Update to v104r13 release. byuu says: Changelog: - nall/GNUmakefile: build=release changed to -O2, build=optimize is now -O3 - hiro: added Monitor::dpi(uint index) → Position [returns logical DPI for x, y] - Position is a bad name, but dpi(monitor).(x,y)() make more sense than .(width,height)() - hiro: Position, Size, Geometry, Font changed from using signed int to float - hiro: Alignment changed from using double to float - hiro: added skeleton (unused) Application::scale(), setScale() functions Errata: - hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues with macOS' automatic scaling. - hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI scaling - hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this, but I still use Qt 4.x) - and just to get global DPI, hiro/qt's DPI retrieval has to use undocumented functions ... fun The goal with this WIP was basically to prepare hiro for potential automatic scaling. It'll be extremely difficult, but I'm convinced that it must be possible if macOS can do it. By moving from signed integers to floats for coordinates, we can now scale and unscale without losing precision. That of course isn't the hard part, though. The hard part is where and how to do the scaling. In the ideal application, hiro/core and hiro/extension will handle 100% of this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware of what's going on, but ... to even make that possible, things will need to change in every per-platform core, eg the per-platform code will have to call a core function to change geometry, which will know about the scaling and unscale the values back down again. Gonna be a lot of work, but ... it's a start.
2017-09-08 06:06:21 +00:00
EnumDisplayMonitors(nullptr, nullptr, MonitorEnumProc, (LPARAM)&info);
return info.primary;
}
}
#endif