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

Scaling factor fix #8

Merged
merged 2 commits into from
Jun 19, 2020
Merged

Conversation

dkondor
Copy link

@dkondor dkondor commented Jun 19, 2020

See issue reported here: thjaeger#10 (comment)

currently, this addresses the simplest case: one monitor, integer scaling, tested on Ubuntu 18.04, only with the "Default" method to display strokes (not with the "XShape" method)

TODO:
-- do not use deprecated functions: gdk_screen_width(), gdk_screen_height()
-- handle multiple monitors separately: this should be possible based on the GdkScreen and GdkMonitor API; it is unclear to me how to find out which monitor a point belongs to if GDK thinks in scaled coordinates
-- handle fractional scaling: this seems complicated, the gdk_monitor_get_scale_factor() API returns an integer, maybe there is a different API that can return fractional scale

It would be great to have this tested more :)

currently, this addresses the simplest case: one monitor, integer scaling, tested on Ubuntu 18.04, only with the "Default" method to display strokes (not with the "XShape" method)

TODO:
  -- do not use deprecated functions: gdk_screen_width(), gdk_screen_height()
  -- handle multiple monitors separately: this should be possible based on the GdkScreen and GdkMonitor API; it is unclear to me how to find out which monitor a point belongs to if GDK thinks in scaled coordinates
  -- handle fractional scaling: this seems complicated, the gdk_monitor_get_scale_factor() API returns an integer, maybe there is a different API that can return fractional scale
@roooots
Copy link

roooots commented Jul 27, 2020

Hi Daniel,

sorry for the late feedback - and thanks for your efforts to fix this.
I have just downloaded and tried the version under https://github.com/dkondor/easystroke but it did not fix the issue. I then recognized that the latest change in the above files is of May 2020, whereas your changes should have been in June 2020.
Did I miss something?

Cheers,
r.

@roooots
Copy link

roooots commented Jul 27, 2020

Errm...nevermind, I just figured the patched code is located under https://github.com/markdstjohn/easystroke.

And there's good news - your patch fixes the issue for me! However, I'm not sure what exactly you mean with integer scaling.
With my system, under settings - appearance - fonts - details, I can only set integer DPI values. I've tried 100, 150, 151, 200 and my default 170. If I issue

xrdb -query | grep dpi

the value returned is half of the DPI value set as described above. That is, 75.5 if I set DPI to 151. Still, your patched easystroke version is working flawlessly in terms of scaling. Please let me know if you want me to check further settings & details.

Thanks,
r.

@roooots
Copy link

roooots commented Aug 5, 2020

After using your version for more than a week I have to report that it suffers from a strange bug: Every now and then when a gesture is drawn, it does appear on screen, but the corresponding action is not executed. This happens sometimes with every second gesture, sometimes ten or more gestures are working fine before the bug occurs again. If it occurs, it may take up to two repetitions of the gesture to have the corresponding action executed successfully. This behaviour appears to be independent of the specific gesture and the corresponding action, it occurs with gestures for browser navigation, for opening various applications and for initiating shutdown or suspend scripts. After switching GPU and corresponding drivers from AMD to NVidia I can confirm that the bug occurs with both.

Due to this bug I reverted back to my dirty-hack version, which is working flawlessly for me.

Cheers,
r.

@dkondor
Copy link
Author

dkondor commented Aug 6, 2020

Hi,

thanks for reporting back! This problem looks very strange, since I only modified drawing code (which seems to be separated from the stroke handling logic as far as I can tell). Maybe there is a connection, or maybe these modifications trigger a bug somewhere? I'll try to investigate (actually I'm not using scaling on my screen normally) or add more diagnostic messages. How easy is it to reproduce this behavior? Does it happen after every few strokes?

For the integer vs float scaling factor, what I mean is not the DPI, but a separate setting. For me (I'm still on Ubuntu 18.04), there are two separate, related settings: in "Settings" (gnome-control-center), under Devices->Displays, beside resolution, I have a setting for "Scale", that is 100% by default and I can set it to only 200% and 300% which doubles or triples the size of everything. As far as I can understand, this setting makes GDK report a smaller screen size to programs (e.g. 1280 pixels wide instead of 2560). My understanding is that this scaling factor is only integer on Ubuntu 18.04, but can be a fractional / float value on newer versions. There is a separate scaling factor for fonts that I can access under gnome-tweaks ("Fonts" tab), which I can set to a float (I'm using 1.25 normally), but I believe this only affects font sizes. So my concern was mainly about the first setting, and how it would behave if fractional values are selected, but then it does not seem to be a problem so far.

@dkondor
Copy link
Author

dkondor commented Aug 6, 2020

One question that came to my mind: when a stroke does not work, does it still show up on the "History" tab of the easystroke window? If yes, does it match correctly?

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

Successfully merging this pull request may close these issues.

3 participants