The HiDPI Issue
Locked
 
|
Hello, I know that others have posted about this before but I wanted to get the current status. I've recently had to buy a new laptop that came with a HiDPI display. Generally (especially on Linux systems) this makes Pharo unusable. Though there are font size increase and scaling options in the Pharo system settings, these do not work as a solution -- buttons are still tiny, there is inconsistent scaling behavior across morphic, etc. The overall problem can be described as: in Pharo, one pixel equals one "point," and so the interface is incredibly small on these HiDPI screens (3k etc). These HiDPI screens are becoming more common, both as laptop and as external displays. Their main advantage is that they can render text very crisply. In the HN post announcing the release of P7, there were one or two complaints about this issue. It does make it hard to demonstrate to others (as I do often) the power of developing in Pharo. Here are some questions I have about this issue: 1) What is the current state of affairs in dealing with this issue, if any? 2) Would this require VM changes (I assume it would)? If so, what might those entail? 3) If this does require VM changes, I assume the Squeak people would want in on it? 4) Is the current plan to wait for Bloc to resolve these issues and/or would switching to Bloc resolve these issues at all anyway? 5) Related -- where can one start to learn about current VM architecture and development practices? That said I'm not here to just bellyache. While I don't have any VM experience, I'm willing to jump in and try to work on it if someone can point me in the right direction. Or perhaps this is too specialized a task... Thanks -- Eric |
|
|
On Sat, 16 Feb 2019 at 00:53, Eric Gade <[hidden email]> wrote:
This is what I understand from observing mail list discussions... For a long time Pharo has been wanting to move windowing out of the VM and into the Image and utilise FFI for the library calls. The Pharo 8 roadmap (http://forum.world.st/Roadmap-for-Pharo-8-0-td5094949.html) includes using a true headless VM with zero windowing code as the standard Pharo VM and have windowing done from the Image. This should open up the possibility of you contributing by coding and debugging at the Image level. So stay tuned.
Yes. And, I don't know. Anyway, this question may end up mute if native-windowing is more exposed to Image-side as described above.
I'm sure they would broadly want the functionality. However Squeak is concerned more about backward compatibility than Pharo. They may be more conservative about following the same path as Pharo. Perhaps once Pharo has broken the ground and proved the concept Squeak could look at how to adopt it in a compatible way. For example, I wonder if its possible to isolate Squeak's VM side window initialization to a single function call that is invoked or not depending on a flag in the Image - which Pharo Images can have set moving forward, and remains unset for Squeak Images.
I'm not up to date on Bloc progress. But with the move to a headless VM, all old problems get thrown away (i.e. so we can make new problems ;) so HiDPI is likely to have the opportunity to be addressed this iteration.
Hopefully it will become less specialised soon. Would you volunteer for early testing of windowing driven from Image side of headless-VM ? cheers -ben |
|
|
In reply to this post by darth-cheney
Hi Eric
I will let esteban reply carefully :) Now my take on this is that we want to go via SDL and other backends to solve the problems (event dropping, display) Back in October, Esteban fixed the SDL/OSWindows so that Bloc people can get rid of the VM rendering and be free. This is the path to go. For Bloc I (personally and discussing with Alain) think that there is 4-6 months of work (if I would overselling it I would have said that this is 2 month work) to clean it and tight it up - (not talking about Widgets). I personnally do not want Design like Glamour or GT in the system (too many announcers). So we will take time to do real code review. So our roadmap is - make sure that Pharo can work headless - check the impact of SDL/OSWindow - focus on new spec version so that we can have our tools migrated and we do not have to rewrite them once more. Pharo 90 probably focus on Bloc. Stef > On 15 Feb 2019, at 17:52, Eric Gade <[hidden email]> wrote: > > Hello, > > I know that others have posted about this before but I wanted to get the current status. > > I've recently had to buy a new laptop that came with a HiDPI display. Generally (especially on Linux systems) this makes Pharo unusable. Though there are font size increase and scaling options in the Pharo system settings, these do not work as a solution -- buttons are still tiny, there is inconsistent scaling behavior across morphic, etc. The overall problem can be described as: in Pharo, one pixel equals one "point," and so the interface is incredibly small on these HiDPI screens (3k etc). > > These HiDPI screens are becoming more common, both as laptop and as external displays. Their main advantage is that they can render text very crisply. In the HN post announcing the release of P7, there were one or two complaints about this issue. It does make it hard to demonstrate to others (as I do often) the power of developing in Pharo. > > Here are some questions I have about this issue: > 1) What is the current state of affairs in dealing with this issue, if any? > 2) Would this require VM changes (I assume it would)? If so, what might those entail? > 3) If this does require VM changes, I assume the Squeak people would want in on it? > 4) Is the current plan to wait for Bloc to resolve these issues and/or would switching to Bloc resolve these issues at all anyway? > 5) Related -- where can one start to learn about current VM architecture and development practices? > > That said I'm not here to just bellyache. While I don't have any VM experience, I'm willing to jump in and try to work on it if someone can point me in the right direction. Or perhaps this is too specialized a task... > > Thanks > > -- > Eric |
|
|
Eric - I had the same feeling a few years ago when I got a retina laptop and found Pharo a bit fuzzy on the eyes (although it’s true that with time you start to notice it less).
Anyway - I’m not sure anyone has actually mentioned that you can download the latest Glamourous Toolkit (https://gtoolkit.com/#install - take the prebuilt image) and then open a playground (with all other windows closed) and evaluate: Bloc preferableHostClass: BlOSWindowHost Then try one of the examples in the GT menu (don’t go full screen in your image), and this will open a second native window rendered in retina quality. Its still a bit alpha - you get a warning dialog that you have to click ignore on 3 times - but then it keeps running. It is also obviously unoptimised at this point too. I think this gives a welcome glance of the future - so there is hope. Tim
|
|
|
Ben: Would you volunteer for early testing of windowing driven from Image side of headless-VM ? Yeah I would love to help test this. However, there's a good chance I'm going to return this new laptop for its lower resolution variant (I have a System76 Galago Pro). The HiDPI situation in Linux is, for the moment, not especially great. Some if it has to do with the whole X vs Wayland (vs NVIDIA) fiasco. But other than that, this is definitely something I'd be willing to help out with. Tim:
I think Apple has some secret sauce when dealing with scaling across different applications on their Retina displays. Xorg and friends do not have this magic on the Linux side. On a 3k 13/14inch screen, without switching my monitors resolution down in the settings, Pharo is downright microscopic (I don't have my new laptop with me otherwise I'd post a screenshot). The only way to deal with this is to completely switch my resolution and scaling factors at the system settings level every time I want to use Pharo. For other applications this might involve a restart, too, which is no bueno. The GToolkit stuff is promising and I had been waiting for this Bloc-in-external-window capability. With regard to the HiDPI stuff, it doesn't make a difference on Linux -- it's just as "small" as anything in the main Morphic window. Again, I think this is because Apple (maybe Windows too?) has more control over their whole graphics stack and can perform some kind of magic to deal with scaling across applications. Thanks for the replies, all. |
|
|
OT: Have a look at the „run_scaled“-script that uses xrpa.
I am using KDE5 (before that XFCE with a dpi setting of 192). Sometimes it resets scaling during a sleep, but it mostly works. Kind regards Markus |
|
|
Aha, interesting script. Related question: since I am a Launcher user, is there a way to modify how individual images are launched (for example, being able to use this script)? On Mon, Feb 18, 2019 at 8:52 AM Markus Fritsche <[hidden email]> wrote: OT: Have a look at the „run_scaled“-script that uses xrpa. -- Eric |
|
|
In reply to this post by darth-cheney
Hi Eric, On Fri, Feb 15, 2019 at 8:53 AM Eric Gade <[hidden email]> wrote:
In the CONTRIBUTING.md and README.md and the HowToBuild files in each build.??? directory in the repository (https://github.com/OpenSmalltalk/opensmalltalk-vm.git). On the opensmalltalk-vm mailing list (http://lists.squeakfoundation.org/mailman/listinfo/vm-dev). In several blog posts and papers on the VM.
No it is not :-). It is a learning task, but VM development is performed by humans for humans ;-)
_,,,^..^,,,_ best, Eliot |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |