ProfileView.jl
ProfileView.jl copied to clipboard
Gtk4 port
This is ready to try now.
Codecov Report
Attention: Patch coverage is 81.66667%
with 11 lines
in your changes missing coverage. Please review.
Project coverage is 87.37%. Comparing base (
fef1437
) to head (896e0fc
). Report is 4 commits behind head on master.
Files | Patch % | Lines |
---|---|---|
src/ProfileView.jl | 81.66% | 11 Missing :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## master #223 +/- ##
==========================================
+ Coverage 87.24% 87.37% +0.12%
==========================================
Files 1 1
Lines 298 301 +3
==========================================
+ Hits 260 263 +3
Misses 38 38
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
I don't see those warnings on Fedora, but they're basically harmless. I wish GTK had a mechanism to silence stuff like that.
What's the status of this?
On MacOS it seems to work (though the text on the canvas is a little blurry?) and I see no terminal warnings.
I wonder if the low resolution issue I'm seeing is related to the failure of this test on MacOS.. perhaps the range of sz is too small https://github.com/timholy/ProfileView.jl/blob/f3754d0d50344f0d708e20e61a4d0588eac59582/test/runtests.jl#L151-L159
I get the warning:
(process:31294): Gtk-WARNING **: 17:38:16.184: No IM module matching GTK_IM_MODULE=ibus found
when opening the viewer, and the following when saving or opening a "testdata.jlprof" file.
(process:31294): Gtk-WARNING **: 17:46:52.667: Attempting to add 'file:///home/nathan/github/ProfileView.jl/testdata.jlprof' to the list of recently used resources, but no name of the application that is registering it was defined
The second of these warnings should be gone in the most recent version of Gtk4.
~~On the resolution issue, I wonder if the scaling should be modified for HiDPI displays?~~ Never mind, the text doesn't look tiny. Like you said, it's blurry.
Test failed for me locally on MacOS but with a different error. Adding additional sleep fixed it, and the CI error too.
Seems like the blurry text rendering is a known and unsolved issue https://gitlab.gnome.org/GNOME/gtk/-/issues/3787
If you think this is ready, I say we go ahead.
Oh, actually, we're on GTK v4.12 and it's claimed this got better in v4.14 https://www.phoronix.com/news/GTK-4.14-Crisper-Font-Rendering
https://blog.gtk.org/2024/03/07/on-fractional-scales-fonts-and-hinting/
Sorry for my inattention (too many updates needed for Julia 1.11 in the Revise/Cthulhu/SnoopCompile etc stack).
I'll start playing with this, but @jwahlstrand feel free to merge whenever you are ready (you have an invite now).
Thanks, I'll check one more thing this evening. The weird thing about the font issue is, we're not using GTK to draw the text, it's all Cairo. For me, it's still quite readable, so I think it's worth going ahead.
I'll try to update Yggdrasil to GTK 4.14 soon.
The CI error came back and I think it was happening because the Profile didn't contain much of anything on MacOS, for some reason. Increasing the number of iterations in the profiled function seems to have fixed it.
I'm seeing an issue locally, only on my Mac. When ProfileView precompiles, using it right away doesn't work. Sometimes the windows don't appear, sometimes I see the following error, no matter what I try to profile:
Warning: There were no samples collected.
│ Run your program longer (perhaps by running it multiple times),
│ or adjust the delay between samples with `Profile.init()`.
But if I quit Julia and restart it, ProfileView works fine. So it seems like precompiling is having some sort of side effect. It's puzzling because ImageView has similar precompile code and works fine. I want to look into this a bit more before merging.
Thanks for your careful work here! I don't have a Mac, nor any good ideas except to wonder if Mac isn't using COW across forked processes? https://softwareengineering.stackexchange.com/questions/244664/global-variable-in-a-linux-shared-library
I think there's a bigger issue on macOS. See https://github.com/JuliaLang/julia/issues/53816#issuecomment-2283798709
I commented out the precompile code that causes issues on my Mac (which involves observable handlers). I don't notice any difference in performance so I'm going to merge this PR and investigate later.
Thank you @jwahlstrand ! You're a true hero!