discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improved and Fixed Screen Math For Parity With Mac OS and Squashing


From: dr_clow
Subject: Re: Improved and Fixed Screen Math For Parity With Mac OS and Squashing Bugs
Date: Sat, 9 Sep 2023 14:59:13 -0500

For those of you following, the bug that I was noticing that was causing certain windows to load at the wrong size, is now fixed on my improved-screen-maths branch. It was just due to our overlooking setMinSize and setMaxSize on NSWindow. I simply needed to ensure that I sent pixel sizes to back. 

NOTE: This bug is currently in the OFFICIAL GWorkspace using the OFFICIAL libs-gui because of the assumptions that developers make/overlook when sending metrics to back (e.g pixels rather than points). Again, my changes fix this so one no longer matters about pixels vs points. And since it appears that in almost all instances developers were assuming that back would take care of this, they never bothered to multiply. The impacts of my changes should be minimal and in-fact fix a lot of exiting bugs when using a GSScaleFactor other than 1.

You can view my adjustments to both libs-back, libs-gui below. 

(1) libs-back https://github.com/austintatiousness/libs-back/tree/improved-screen-maths

I want to also note that the solutions I implemented solved a lot of the issues related to GSScaleFactor in other apps like GWorkspace that were loading windows at incorrect sizes, the desktop at the wrong size. Or windows having their content shifted. 

If y'all notice any other GSScaleFactor bugs, please let me know. I am very motivated to get all those bugs squashed. 

On Sep 8, 2023, at 11:27 PM, dr_clow@me.com wrote:

Thanks for checking. I'm sure I fixed it with out noticing as I was going along. I appreciate your taking the time. 

A question for those who are familiar with the Wayland backend. Firstly, making the changes for Wayland, was easy. I only had to adjust the NSEvent call sites there as well. But I did this under the assumption that Wayland presents window surfaces the same way X11 did, in pixels instead of points. Is this assumption still correct? If so, then I did the Wayland changes as well. Really quick job. 

I haven't tested it yet as I don't have a VM set up for it. 

Over the last few days I have been continuing to test the changes I made in my fork, and they work great. I am still trying to solve the issue with some windows being 1/2 the size in both directions. If anyone has any insights there, I would appreciate it!

Thanks!

On Sep 7, 2023, at 2:46 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:

It is gone now, maybe I was looking at an old version of the code? In the git history you can still see it on line 546.

On the road

Am 07.09.2023 um 01:38 schrieb dr_clow@me.com:

So I read the code again, and I just wasn't able to find where I was dividing twice. I set a rule that I only preformed division at the NSEvent construction site (to ensure that all the math that happens up until that point was surly in pixels. Would you mind showing me the line. I assume it it's in XGServerEvent.m. I might just be tired, or I confused myself. Thanks!

On Sep 6, 2023, at 3:37 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:

This looks a lot better, though I only looked at the back part. There are a few typos and at one place (mouse events) you are doing the division twice.

Cheers,
Fred

On the road

Am 06.09.2023 um 04:31 schrieb dr_clow@me.com:

Hello All, 

I just finished rebasing my code on the current libs-gui and libs-back and cleaning it up so it follows the current indentation conventions for GNUStep. I compiled it, and it all works (except for one bug that I am trying to track down that may be unrelated). The links below should work with the better re-based code. 

(1) libs-back https://github.com/austintatiousness/libs-back/tree/improved-screen-maths
(2) libs-gui https://github.com/austintatiousness/libs-gui/tree/improved-screen-maths

Bug: 
There is one bug that I am still trying to track down that I believe is from GORM files or deferred windows. In a 2x scale factor, they display still at half the height. No idea why. It might have to do with the order the the screen gets attached to the window? Maybe they are deferred? Something I notice was that when the affected windows are allocated and first set up, the correct sizes are reported to libs-gui and libs-base (i tracked this with a bunch of NSLogs), but at some points libs-base sends another NSEvent with it half the size causing the window to resize to half the size. Maybe there is a rect cached somewhere that it is using and math is preformed on it to cut it in half. I just can't figure where the event is originating form. 

Thanks for reading!



On Sep 5, 2023, at 9:17 AM, dr_clow@me.com wrote:

You're not wrong it is currently messy code. I had tried so many different things before I fully understood the drawing system and the Back->GUI interactions. Though, I thought I did pull out all of the code that I used to mitigate the issue before as with my adjustments, they were no longer needed. It was a LOT of learning. I started on a copy that was a few weeks old, but I thought that I re-synced those changes in before I moved the code back in. May I didn't. 

So, what I will do is clone it again and add back each change so the code matches better and you can see the changes more clearly and try not to adjust any of the indentation. It might look like more changes were made when you do a code comparison because I had modified and changed back so many things and then back when I realized it wasn't needed. To be honest, in the end, it really ended up just being som minor changes in Back and changing how NSWindow adjusted the base decoration view and adding a new method to scale drawing. 

I will post an update soon to clean up some of the code to make the code comparison cleaner in both back and base. 

Thanks! 

On Sep 5, 2023, at 3:37 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:

I had a short look at your changes and sadly these don’t resemble the clear idea you expressed in your mail. There are many leftovers from your previous attempts to tackle the issue. You also missed out on the changes that happened to GNUstep since you forked off your branch. A simple rebase would help here. On the other hand, you are using an unmatched indentation pattern and added plenty of empty newlines. Maybe it would be best if you start anew from the current GNUstep code and just implement your idea?

Hope this helps,
Fred

On the road

Am 05.09.2023 um 09:17 schrieb Fred Kiefer <fredkiefer@gmx.de>:


Hi,

This approach sounds sensible to me. But as you said, it will take some more effort to spread it through the whole library, especially all the different backends. And there is also the case where GNUstep does the window decoration drawing.
I am currently travelling and wont be able to review your code in detail before I am back home. But I will try to have a quick look to maybe point out some further difficulties.

Cheers,
Fred


On the road

Am 05.09.2023 um 01:29 schrieb dr_clow@me.com:

Hello Friends, 

As you may have read I have been working on getting some of the ScreenFactor bugs squashed. One of my theories is that a lot of GNUStep developers are assuming screen scaling of 1. This creates a problem where the values coming in from NSEvent, NSScreen are in pixels and not points. I noticed that apps like GWorkspace used the screen resolution (in pixels) to generate its desktop and center its dock which cause the dock and desktop items to disappear. Originally, I fixed this by going in my version and dividing by the correct scale. I then noticed that these little bugs were everywhere. I also noticed that sometimes the NSString value of a NSRect saved to Plists were in pixels as well, creating a problem when screen scaling would change. Suffices to say, I wanted a fix that would allow all these other projects to display correctly with out having to go to each one and divide by scale factor for the offending views. 

There are two libraries that this affects (my version of the projects are here)

To fix this, I proposed that we allow AppKit to assume that all geometry is in points instead of pixels according to the screen the window is on. This required only some minor changes actually. 

1) When libs-back constructs NSEvents that pertain to an NSWindow, it needs to ensure that all the math is scaled by the screen factor of that window. 
2) When libs-gui sends data to back, back knows that it will be in points and fixes it. 
3) NSWindow needed some minor changes to its drawing routines because the assumption is no longer that that decoration view (_wv) is scaled, but instead a theoretical layer just below it is. So no longer do we to a transform on the view, but instead just do a transform right before drawing. You will see a method added to NSView - (NSAffineTransform*) _baseMatrixForDrawing , that handles the math for each view so they draw at the correct scale. 

When I finished fixing all of this, some of the other changes that I had previously proposed were no longer needed. 

Some caveats: In my tests, I only changed the X11 code, I am only using frames drawn by GNUSteap instead of the window manager. 

I have compiled and tested the code against GNUStep Desktop, and it all is working great. There are still a few bug fixes (I cannot figure out why items loaded from gorm sometimes are divided by the screen factor), but some of the issues I encountered in other apps are now fixed when I change my screen resolution. 

I would really love it if my code could be reviewed and possibly taken into consideration to being added to the official reposatory.

As it is right now, I'm not going to be using an old monitor for my work, and I am working on a Swift bridge so I can port some of my software. I will be using my version of the frameworks for this project because unfortunately, as the bugs currently are, my ports wouldn't work correctly. 

Lastly, I am hoping that I copied all the code back into my repository, please let me know know if something doesn't build. 

Thanks!






reply via email to

[Prev in Thread] Current Thread [Next in Thread]