pharo
pharo copied to clipboard
pharo-project
Fonts are blurry under high resolution screen
Bug description
Left ok. Right blurry
The issue appears at the same time than fixing #10319 and likely to be related to #8688.
To Reproduce Steps to reproduce the behavior:
- Go to huge screen where the scale of the screen is more than 100%
- Open Pharo
- See that the font is blurry
Expected behavior No blurry font and scaling correct
Screenshots See above
Version information:
- OS: Win10
- Pharo Version Pharo 9.0.0 Build information: Pharo-9.0.0+build.1573.sha.0e09d756fc99383cbb498565200d9e5e9841ce11 (64 Bit)
Expected development cost High
Additional context Lifeware tagged
@VincentBlondeau / @tesonep / @guillep
Yes - we had a solution originally:
- ISSUE: Pharo 9 looked bad on Windows HiDPI Devices (Microsoft Surface) https://github.com/pharo-project/pharo/issues/9715
- PR: it was fixed with a PR: https://github.com/pharo-project/pharo/pull/9716
Later it got reverted through
- ISSUE: OSSDL2BackendWindow>>#fetchDPI seems broken https://github.com/pharo-project/pharo/issues/10319
- PR: 10319-OSSDL2BackendWindowfetchDPI-seems-broken https://github.com/pharo-project/pharo/pull/10325
If you check the comments in https://github.com/pharo-project/pharo/pull/10325 I already pointed out that new proposed changes this will revert the original fix and @tesonep replied that there will be a setting. I guess this setting is still missing/pending.
By looking quickly it seems Pharo can't support HiDPI because OSWorldRenderer>>actualScreenSize takes into account screen scale, on HiDPI devices it means OSWorldRenderer>>actualScreenSize will return a too low value.
For example on my device OSWorldRenderer>>actualScreenSize returns (1920@1138) while the widow size (in pixels displayed on the physical screen) is (3840@2275)
Then the too small extent goes to OSWindowFormRenderer, and all the morphs are computed based on this value.
It's not that simple to fix it however, modifying OSWorldRenderer>>actualScreenSize to return the correct pixel number will break the mouse position and the scaling
From Lifeware side it's already better to have a correct scale but blurry screen (after https://github.com/pharo-project/pharo/pull/10325), than having a too small scale and still a blurry screen after setting a custom scale in Pharo appearance settings (before https://github.com/pharo-project/pharo/pull/10325)
The issue is that having a blurry screen is an incentive not to use Pharo
I also think this is an important and sensitive issue: it gives a really bad first impression.
May be adapting and providing a specific startup preferences can help. For the HDPI we need at least 6 months of work and we do not have them now.
@VincentBlondeau how did you get the non blurry example on the left of your image?
This is pharo 7, 8, 9, 10, they all look the same for me
The following patch works for me on 2K/1440p display as well as an older laptop with an 1080p FHD monitor: Not very well-versed in Pharo's code and I don't any Retina display to test with, so YMMV
--- orig/src/OSWindow-Core/OSWorldRenderer.class.st 2022-08-16 21:16:39.763266326 +0200
+++ src/OSWindow-Core/OSWorldRenderer.class.st 2022-08-16 21:20:33.905443917 +0200
@@ -278,7 +278,7 @@
{ #category : #'scale factor' }
OSWorldRenderer >> windowScaleFactor [
- ^ osWindow ifNil: [ 1 ] ifNotNil: [ osWindow screenScaleFactor max: 1 ]
+ ^ osWindow ifNil: [ 1 ] ifNotNil: [ osWindow screenScaleFactor min: 1 ]
]
{ #category : #accessing }
Nothing would make me happier and more willing to give Pharo (or Squeak) a real serious go.
Us too. Where can I find the code? Ok seriously this is not because we do not want that Pharo is not in HDPI. First this is a question of resources, second this is a question of resources and third this is a question of speed (because we have a running version but it is slow to move windows and we need to see how to optimise it). So the more the people help for other tasks the more chance we have that we can calmly have a look.
Where in the code needs a look? I can look for macOS, but know nothing about for Windows or Linuxes or BSDs. I suspect the handling will be more or less branching along those lines (if it does not already).
No we do not branch :) this is not like an case statement. Now we can ask Pablo and Carolina and you can try the version we have. @tesonep @carolahp
hmm, seems like things rely on SDL2 which is in C and I am sure supports HiDPI for a long time now :) Is Pharo using an FFI to interact with SDL2 calls?
Yes Pharo is using SDL2 as back-end. The key point is how to rerender an object trees fast enough so that you can move a window with animations inside and that animations are smooth.
Makes sense. part of me wonders if the abstraction layering is where some trouble is. Like if it were a true VM, all major OS platforms have hypervisor APIs today… that would streamline a lot be also limit other things and literally be an OS. If the classic SmallTalk image were not used but rather became more of a cross platform API using like Qt or Tk or something similar, it could also be a very powerful thing. but that’s me thinking out loud. Neither of those would be simple and really solve different problems.
indeed and doing is often more demanding :) You have to have an execution engine and this is what we are doing. And Pharo should be versatile.
Hello, I tried opening Pharo on a 3840x2160 screen with Windows scaling set to 150% and found out everything was blurry :
I don't open a new issue as I think this is related to this one, has a solution been found since then @Ducasse or should I switch to another screen for now ?
what is the status of this? I'm using Pharo 11 with 4K display and suffering blurry text.
We have the same problems. You can check and report two projects Rinzwind and form-scene-graph see below
Rinzwind
You can check the following check @Rinzwind
https://github.com/pharo-project/pharo/pull/15561 parts pasted below
I updated, and made two small improvements to, the ‘Retina display’ scaling experiment from earlier pull requests: commits 1cdeaf1, 0ff236a and 139a5bb (which are not included in this pull request).
If you want to try it out:
- Create an image in Pharo Launcher using Pharo 12 build 1128 as the template
- Close the ‘Welcome’ window
- Repair the repository ‘pharo’ by cloning from GitHub using ‘Rinzwind’ as the ‘Owner name’ and ‘pharo’ as the ‘Project name’
- Check out the branch ‘scaling-canvas-tryout-14’ from ‘origin’
- Close the ‘Repositories’ window (its icons will be broken at this point, but just click the usual location of the closing button)
- Open the extra world by doing OSWorldRendererScalingCanvas example; or, to use ScalingCanvas for drawing the main world:
-Do OSWorldRendererScalingCanvas isApplicable: true, and save and quit the image -Open the image again and do World scaleFactor: 0.5
To revert, do World scaleFactor: 1 and OSWorldRendererScalingCanvas isApplicable: false, then save and reopen the image
Form-scene-graph
You can also check the code of
- https://github.com/carolahp/form-scene-graph
- Check the comment of the original forked project https://github.com/desromech/form-scene-graph and report if it is working for you.
So we are concerned about it and the form-scene-graph was already a long effort that we paid with our team money.
Now if people want to put money on the table to change our effort we are all ears open.
GitHub
A Gtk Scene Graph inspired rendering framework for Pharo - GitHub - carolahp/form-scene-graph: A Gtk Scene Graph inspired rendering framework for Pharo
A Gtk Scene Graph inspired rendering framework for Pharo - GitHub - desromech/form-scene-graph: A Gtk Scene Graph inspired rendering framework for Pharo
Instead of following the instructions from pull request #15561 pasted above, in the latest Pharo 12 builds, in which pull request #15647 was merged, you can just set the ‘canvas scale factor’ setting:
Note that I use a MacBook and don’t have a Windows or Linux machine, except virtual ones, so I’m not entirely sure what the effect is on those platforms, but please do try it out!
There’s a setting now to let the canvas scale factor be set automatically (since Pharo 12 build 1494):
As mentioned in pull request #16479, it may need some further testing, especially on Windows and Linux, so please do leave some feedback when you’ve given it a try!
Trying to find that 1494 build to no avail. Not here yet right?: https://pharo.org/download
If you want to try build 1494 specifically, you can get ‘Pharo12.0-SNAPSHOT.build.1494.sha.6e47d25.arch.64bit.zip’ from the directory ‘120’ within ‘image’ on ‘files.pharo.org’. Later Pharo 12 builds include the setting as well, so you can also just get the latest one through Pharo Launcher using the template ‘Pharo 12.0 - 64bit (stable)’.
The link ‘64bit (default)’ for ‘Pharo image’ in the section ‘Pharo standalone’ on the website’s ‘Download’ page is currently broken, I have opened pharo-website pull request #71 to fix that.
Thanks! Also, ended up fetching the image using the New icon in the launcher. Btw, total newbie here. Anyways, font issue is fixed (macOS Sonoma here). Now I can get started with Pharo without my eyes hurting. 💯
Can this be closed now? There is a setting in Pharo 12 under - World renderer canvas scaling - Canvas Scale Factor.
Setting this to 2 on my mac with a retina screen makes it clear (and the same on a large screen).
