Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support for higher resolutions #9

Open
Ali-Bueno opened this issue Dec 27, 2023 · 8 comments
Open

support for higher resolutions #9

Ali-Bueno opened this issue Dec 27, 2023 · 8 comments

Comments

@Ali-Bueno
Copy link

As the title say's. I have a screen resolution of 2560*1440, and to use this app I need to change my resolution to 1080p. however, I have other apps and scripts that doesn't run well if I keep my resolution to 1080p. So if possible, would be great if you can make this available for more resolutions

@Timtam
Copy link
Collaborator

Timtam commented Dec 27, 2023

I thought about this already as well, however there are some major obstacles that we most likely aren't able to tackle:

  • getting the screen resolution on the specific machine: that is rather easy, A_ScreenWidth and A_ScreenHeight will get us the resolution of the current screen.
  • just up/downscaling won't help, as most interfaces will start hiding specific elements if the resolution gets to low and show other elements as soon as the resolution exceeds a certain width/height, which will move the position of other elements, preventing us from simply up/downscaling the coordinates we're using to click certain elements
  • adding support for specific screens that do behave differently on other resolutions is especially tricky with higher resolutions. Lower resolutions are easier because any high-res screen can be changed to a lower res, but not the other way around. I right now only have a 1080 monitor and I cannot test any 1440 or 2160 res interfaces for the most obvious reason: money. If anyone was to contribute a proper monitor to me things would be different, but that is how it looks on my end right now. Dunno about @MatejGolian though.

@MatejGolian
Copy link
Owner

Unfortunately, my situation is the same as @Timtam's. Perhaps we could hack around it to some extent by relying more on ImageSearch and images made for more screen resolutions, but as we don't have access to higher resolution monitors at the moment ourselves, debugging things would probably be very very difficult. I'd personally prefer relying more on OCR, but the situation there might be very similar to that with mouse coordinates, as we also pass basic screen coordinates to OCR functions in order to get more reliable results.

@Timtam
Copy link
Collaborator

Timtam commented Dec 27, 2023

I'd suggest a different approach here if possible. Which apps/scripts rely on you having a higher res than 1080p configured on your machine? That seems rather weird to me to be honest, as full HD (1080p) is widely accepted as the current default and most apps are developed to look and feel good when used with this resolution. Since ReaHotkey is meant to be a toolbox of all kind of audio/music related scripts, maybe it is easier to add support for the tools which force you into a higher res to ReaHotkey but on 1080p instead of 1440p so that you can just run at 1080.

@MatejGolian
Copy link
Owner

@Ali-Bueno, if the script changed the screen resolution to 1920 × 1080 on startup automatically after a simple Yes/No dialog, would that improve your situation in any way? It would also be possible to revert back to your original resolution before quitting the script, but that could also potentially lead to some confusion, in case for example the user changed the screen resolution to something else while the script is running.
Another approach would be automatically changing the resolution to 1920 × 1080 whenever a supported program or plugin is active and switching the resolution back in every other case.
I'm not sure if it's entirely safe to go down this path, but this is what came to my mind as an alternative solution. @Timtam, what do you think?

@MatejGolian
Copy link
Owner

So far I've implemented a startup check/prompt that allows one to change the resolution automatically. The script does not check/change the resolution anywhere else, so if you answer 'Yes', your resolution will stay at 1920 × 1080 until you change it in Windows. This should be safe and I think that so far it could stay like this, but any other eventual seamless resolution switching will have to be discussed. I'm not really a fan of the idea, but I'd like to know what you guys think...

@Timtam
Copy link
Collaborator

Timtam commented Mar 17, 2024

I personally would like this script to be as intrusive as possible, means I don't like the idea of having a popup that comes up every time I launch the script which asks if you want to change your resolution. Plus, as you've already said, people could change resolution while running the script, causing all kinds of potential issues. I could think of a settings screen where you'd need to manually opt-in to changing res when running and resetting when closing the script but... well, it still doesn't feel right to me TBH, especially since we'd need to debug here since we can still run into machines which simply can't display 1080p, even without our routine getting applied, just because the screen can't do that. So this fix doesn't actually fix the cause of the problem, at least not the one with lower resolutions.

@MatejGolian
Copy link
Owner

So we agree that neither of us really likes the idea of tampering with the resolution. The question is, would you personally remove that startup check/prompt all together, or would you at least display a message if/when the resolution is incorrect? You are right that that prompt can not solve the case when the resolution just can't be set to what the script requires. So it only helps if the user can run at the required resolution, but he/she has it set either to a higher or lower value.

@MatejGolian
Copy link
Owner

I'll leave the resolution check in there for now, since there don't appear to be any objections...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants