Skip to content

fixes pixel ration on macos #458

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

Merged
merged 6 commits into from
Jun 30, 2022
Merged

fixes pixel ration on macos #458

merged 6 commits into from
Jun 30, 2022

Conversation

pchampio
Copy link
Member

@pchampio pchampio commented Jun 2, 2020

No description provided.

@pchampio pchampio requested a review from GeertJohan June 2, 2020 09:31
Copy link

@etx etx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Working on MacOS 10.15.5! Thanks!

@pchampio
Copy link
Member Author

pchampio commented Jul 7, 2020

On linux (and in my setup), this method of handling the pixel ratio works better than the current one.
I have xrandr configured likeso: xrandr --output "$external" --scale 1.6x1.6 --mode 2560x1440

@GeertJohan
Copy link
Member

On linux/X11 the fix/contentscale branch is broken. Everything is way too large.

It is the same value for both of my monitors now; 2.6458333.
On the master branch I have a pixelRatio of 1.595812 for the primary monitor (which then displays properly), and 0.682625 for the secondary monitor (which displays the app too small)

I don't think we can ever use glfw's content scale directly as flutters pixelRatio because flutter bases it's pixelRatio on the 160dpi standard. It's related to the Android Display Pixel calculations.

So at the very least there needs to be some formula calculating from one to the other.

@pchampio
Copy link
Member Author

pchampio commented Jul 7, 2020

2020-07-07_16-11

I don't think we can ever use glfw's content scale directly as flutters pixelRatio because flutter bases it's pixelRatio on the 160dpi standard. It's related to the Android Display Pixel calculations.

The current implementations of the DPI calculations is done by querying the window.GetFramebufferSize and Monitor.GetPhysicalSize this doesn't take into account users configured DPI option. In my setup (above screen), I have everything set to 203DPI which window.GetContentScale() does properly query (= 2.114 in golang)

@pchampio
Copy link
Member Author

pchampio commented Jul 7, 2020

The --scale 1.6x1.6 trick is only a X11 workaround for not having the per monitor DPI scaling option. 😢 (Other OS might have it and correctly report the window.GetContentScale)
So if you are basing your conclusion on a workaround, (that don't imply to other people on the same OS or other OS), we might be missing something.

@pchampio
Copy link
Member Author

pchampio commented Jul 7, 2020

Looking at the code in https://github.com/flutter/engine/blob/175a92b467e988649d642193e864189f88430524/shell/platform/glfw/flutter_glfw.cc
The GLFW impl match ours.
Still, I thinks we might be missing something.

@GeertJohan
Copy link
Member

I think the two maybe should be combined or something like that...

@Aurora12
Copy link

Hey guys! What's the status of this fix?

We are using this branch for MacOS builds because otherwise, it's all too small on retina displays. Is there any new info on this so this could get merged?

@Aurora12
Copy link

We needed this fix for retina displays and it seemed to work just fine for all platforms... Apart from the fact that it crashed on some Macs before we got it merged with the current master head!

We tested it in laptops and iMacs running OSX 10.15.6, 10.15.5, 10.12.6 and 10.13.6 and found no stable pattern in where it worked and where it didn't. When we merged with the head of master it stopped crashing for everybody.

This is what the system log had to say about the crash:

default 16:32:16.257822 +0200 kernel process worldr[1114] caught waking the CPU 45002 times over ~43 seconds, averaging 1045 wakes / second and violating a limit of 45000 wakes over 300 seconds.
default 16:32:16.258014 +0200 symptomsd Received CPU wakes trigger:
  worldr[1114] () woke the CPU 45002 times over 43.04 seconds (average 1045/sec), violating a CPU wakes limit of 45000 over 300 seconds.

At first, we blamed the scaling callback for not debouncing as the position callback does. But after we merged the master in everything works fine with or without debouncing. We were not able to get to the bottom of the problem.

@etx
Copy link

etx commented Aug 13, 2020

We had to switch off go-flutter due to this so I stopped looking into it. We're using the native desktop embedder and calling Go from a shared library now.

@JanezStupar
Copy link

Any progress on this?

@pchampio
Copy link
Member Author

@JanezStupar does hover run -b '@fix/contentscale' works ?

@JanezStupar
Copy link

@JanezStupar does hover run -b '@fix/contentscale' works ?

Looks great on Macos - both retina and external display.
Looks great on Linux - both built in and external display.
Looks acceptable on Windows - I don't have two different DPI displays available for that one. But the fonts seem a bit jagged. But is likely due to other causes.

@pchampio
Copy link
Member Author

pchampio commented Oct 20, 2020

Looks great on Macos - both retina and external display.
Looks great on Linux - both built in and external display.
Looks acceptable on Windows - I don't have two different DPI displays available for that one. But the fonts seem a bit jagged. But is likely due to other causes.

Awesome, does hover run looks good on Linux ?

@JanezStupar
Copy link

Awesome, does hover run looks good on Linux ?

With hover 0.43.0 yes. With hover 0.44.0 no as it throws a sefgault during build (I haven't looked into it, I just downgraded hoping that somebody else is on it already.

@pchampio
Copy link
Member Author

pchampio commented Oct 20, 2020

If you update hover.
GO111MODULE=on go get -u -a github.com/go-flutter-desktop/hover does this fix this other issue (are you able to run go-flutter 0.44.0)

@provokateurin
Copy link
Member

The segfault maybe happens, because an old engine is used and not the new AOT engines. Doing a flutter clean and rm -rf ~/.cache/hover/engine (linux) should fix that

@JanezStupar
Copy link

I tried all your suggestions the result is the same. I have created a new ticket for that as to not clutter this discussion.

@JanezStupar
Copy link

JanezStupar commented Oct 21, 2020

So what is the recomendation for my issue? To use the @fix/contentscale until it gets merged?

@pchampio
Copy link
Member Author

@JanezStupar yes, I'll get this merge for MacOS and Windows this week.

@pchampio
Copy link
Member Author

pchampio commented Nov 1, 2020

@GeertJohan I've compiled all cases and came out with this code. Is it good for you ?

This work for me on linux.
with: 2020-07-07_16-11
and xrandr --output "$external" --scale 1.6x1.6 --mode 2560x1440

@pchampio
Copy link
Member Author

pchampio commented Nov 1, 2020

fixes #84
fixes #461

@pchampio pchampio linked an issue Nov 1, 2020 that may be closed by this pull request
@pchampio
Copy link
Member Author

@GeertJohan Can you look at this.
This should fix macos scaling issue: #461 (comment)

@GeertJohan
Copy link
Member

GeertJohan commented Jan 22, 2021

I tried to use this branch locally with the latest version of hover, but the resulting release binary failed instantly:

~/s/g/i/d/g/b/o/linux-release :master ✱
$ ./invition-dashboard
[ERROR:flutter/runtime/dart_vm_data.cc(18)] VM snapshot invalid and could not be inferred from settings.
[ERROR:flutter/runtime/dart_vm.cc(250)] Could not setup VM data to bootstrap the VM from.
[ERROR:flutter/runtime/dart_vm_lifecycle.cc(84)] Could not create Dart VM instance.
[FATAL:flutter/shell/common/shell.cc(264)] Check failed: vm. Must be able to initialize the VM.
SIGABRT: abort
PC=0x7f8c98a8d18b m=0 sigcode=18446744073709551610
signal arrived during cgo execution

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0x606110, 0xc0001498d8, 0xc0001360e0)
	/home/geertjohan/go/src/runtime/cgocall.go:133 +0x5b fp=0xc0001498a8 sp=0xc000149870 pc=0x42947b
github.com/go-flutter-desktop/go-flutter/embedder._Cfunc_runFlutter(0xc00001c1e0, 0xc000122140, 0xc0001360e0, 0x0)
	_cgo_gotypes.go:737 +0x4d fp=0xc0001498d8 sp=0xc0001498a8 pc=0x5667ed
github.com/go-flutter-desktop/go-flutter/embedder.(*FlutterEngine).Run.func5(0xc00001c1e0, 0xc000122140, 0xc0001360e0, 0x6e)
	/home/geertjohan/src/github.com/go-flutter-desktop/go-flutter/embedder/embedder.go:150 +0xd0 fp=0xc000149908 sp=0xc0001498d8 pc=0x568bf0
github.com/go-flutter-desktop/go-flutter/embedder.(*FlutterEngine).Run(0xc000122140, 0xc00001c1e0, 0xc00007e2d0, 0x3, 0x3, 0x0, 0x0)
	/home/geertjohan/src/github.com/go-flutter-desktop/go-flutter/embedder/embedder.go:150 +0x337 fp=0xc000149b48 sp=0xc000149908 pc=0x5674f7
github.com/go-flutter-desktop/go-flutter.(*Application).Run(0xc000136000, 0x0, 0x0)
	/home/geertjohan/src/github.com/go-flutter-desktop/go-flutter/application.go:250 +0x985 fp=0xc000149ec0 sp=0xc000149b48 pc=0x58b6c5
github.com/go-flutter-desktop/go-flutter.Run(0xc000072080, 0x7, 0x8, 0xc00005ff68, 0x2)
	/home/geertjohan/src/github.com/go-flutter-desktop/go-flutter/application.go:26 +0x4d fp=0xc000149ef0 sp=0xc000149ec0 pc=0x58a38d
main.main()
	/home/geertjohan/src/gitlab.com/invition/dashboard/go/cmd/main.go:24 +0x17d fp=0xc000149f88 sp=0xc000149ef0 pc=0x5ee6fd
runtime.main()
	/home/geertjohan/go/src/runtime/proc.go:204 +0x209 fp=0xc000149fe0 sp=0xc000149f88 pc=0x45d829
runtime.goexit()
	/home/geertjohan/go/src/runtime/asm_amd64.s:1374 +0x1 fp=0xc000149fe8 sp=0xc000149fe0 pc=0x48ed81

rax    0x0
rbx    0x7f8c98905b80
rcx    0x7f8c98a8d18b
rdx    0x0
rdi    0x2
rsi    0x7ffdc92453e0
rbp    0xa
rsp    0x7ffdc92453e0
r8     0x0
r9     0x7ffdc92453e0
r10    0x8
r11    0x246
r12    0x7ffdc9246bd0
r13    0x7ffdc92464a8
r14    0x7ffdc9245da8
r15    0x7ffdc9246470
rip    0x7f8c98a8d18b
rflags 0x246
cs     0x33
fs     0x0
gs     0x0

@pchampio
Copy link
Member Author

pchampio commented Jan 22, 2021

What I can tell is that the following error:

[ERROR:flutter/runtime/dart_vm_data.cc(18)] VM snapshot invalid and could not be inferred from settings.
[ERROR:flutter/runtime/dart_vm.cc(250)] Could not setup VM data to bootstrap the VM from.
[ERROR:flutter/runtime/dart_vm_lifecycle.cc(84)] Could not create Dart VM instance.
[FATAL:flutter/shell/common/shell.cc(264)] Check failed: vm. Must be able to initialize the VM.

is a building error. And isn't related to this PR. (the diff wasn't complete on github)

(with the latest version of hover, the -b flags need to be used with: go env -w GOPROXY=direct)

@pchampio
Copy link
Member Author

pchampio commented Jan 22, 2021

I think a rebase is needed!

diff --git a/accessibility.go b/accessibility.go
index 386e943..97a280f 100644
--- a/accessibility.go
+++ b/accessibility.go
@@ -9,7 +9,7 @@ var defaultAccessibilityPlugin = &accessibilityPlugin{}
 
 func (p *accessibilityPlugin) InitPlugin(messenger plugin.BinaryMessenger) error {
 	channel := plugin.NewBasicMessageChannel(messenger, "flutter/accessibility", plugin.StandardMessageCodec{})
-	// Ignored: go-flutter doesn't support accessibility events
+	// Ignored: go-flutter dosn't support accessibility events
 	channel.HandleFunc(func(_ interface{}) (interface{}, error) { return nil, nil })
 	return nil
 }
diff --git a/application.go b/application.go
index 14422e7..6e1a684 100644
--- a/application.go
+++ b/application.go
@@ -320,6 +320,9 @@ func (a *Application) Run() error {
 			})
 		})
 	})
+	a.window.SetContentScaleCallback(func(window *glfw.Window, x float32, y float32) {
+		windowManager.glfwRefreshCallback(window)
+	})
 
 	// Attach glfw window callbacks for text input
 	a.window.SetKeyCallback(
diff --git a/embedder/build.go b/embedder/build.go
index eef0dcd..9f185b0 100644
--- a/embedder/build.go
+++ b/embedder/build.go
@@ -1,5 +1,3 @@
-// +build !no_engine_tags
-
 package embedder
 
 // #cgo linux LDFLAGS: -lflutter_engine -Wl,-rpath,$ORIGIN
diff --git a/embedder/embedder.go b/embedder/embedder.go
index 81cf529..2aa94a6 100644
--- a/embedder/embedder.go
+++ b/embedder/embedder.go
@@ -132,17 +132,17 @@ func (flu *FlutterEngine) Run(userData unsafe.Pointer, vmArgs []string) error {
 	}
 
 	if C.FlutterEngineRunsAOTCompiledDartCode() {
-		elfSnapshotPath := C.CString(flu.ElfSnapshotPath)
-		defer C.free(unsafe.Pointer(elfSnapshotPath))
+		// elfSnapshotPath := C.CString(flu.ElfSnapshotPath)
+		// defer C.free(unsafe.Pointer(elfSnapshotPath))
 
-		dataIn := C.FlutterEngineAOTDataSource{}
+		// dataIn := C.FlutterEngineAOTDataSource{}
 
-		C.createAOTDataSource(&dataIn, elfSnapshotPath)
-		res := (Result)(C.FlutterEngineCreateAOTData(&dataIn, &flu.aotDataSource))
-		if res != ResultSuccess {
-			return res.GoError("C.FlutterEngineCreateAOTData()")
-		}
-		args.aot_data = flu.aotDataSource
+		// C.createAOTDataSource(&dataIn, elfSnapshotPath)
+		// res := (Result)(C.FlutterEngineCreateAOTData(&dataIn, &flu.aotDataSource))
+		// if res != ResultSuccess {
+		// return res.GoError("C.FlutterEngineCreateAOTData()")
+		// }
+		// args.aot_data = flu.aotDataSource
 	}
 
 	args.struct_size = C.size_t(unsafe.Sizeof(args))
@@ -167,10 +167,10 @@ func (flu *FlutterEngine) Shutdown() error {
 	}
 
 	if C.FlutterEngineRunsAOTCompiledDartCode() {
-		res := (Result)(C.FlutterEngineCollectAOTData(flu.aotDataSource))
-		if res != ResultSuccess {
-			return res.GoError("engine.Shutdown()")
-		}
+		// res := (Result)(C.FlutterEngineCollectAOTData(flu.aotDataSource))
+		// if res != ResultSuccess {
+		// return res.GoError("engine.Shutdown()")
+		// }
 	}
 	return nil
 }

@pchampio
Copy link
Member Author

Fixed:
(and also tested in release mode)

image

@pchampio
Copy link
Member Author

pchampio commented Jan 24, 2021

fixes: #563

@xkeyC
Copy link

xkeyC commented Feb 18, 2021

When will it be merged? After testing the fix/contentscale branch solved my problem.

@pchampio
Copy link
Member Author

After many report from the community, this branch fixes the problem for the majority of the users.

I'll merge this branch as a step in the right direction but not a complete solution. (IMHO, it's good enough of linux windows and macos users)

@pchampio pchampio merged commit 729801f into master Jun 30, 2022
@pchampio pchampio deleted the fix/contentscale branch June 30, 2022 20:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

[Windows] Changing DPI Scaling does not scale app pixelRatio wrong on built in MacOS display Wrong PixelRatio calculation (based on DPI scaling)
7 participants