Gtk window contents not rendering on MacOS (Mojave) #414
Comments
|
I have not routinely seen that with ImageView and "straightforward" image series (e.g., stored as mmapped files). You can play with |
|
@timholy It seems I should've checked the basics first! Images aren't rendering in the window for me JuliaImages/ImageView.jl#175 |
IanButterworth
changed the title
|
This issue seems to stem from Cairo Gtk using Gtk
win = GtkWindow("My First Gtk.jl Program", 400, 200)
b = GtkButton("Click Me")
push!(win,b)
showall(win)
GtkReactive using GtkReactive, Gtk.ShortNames, Graphics, Test
c = canvas(208, 207)
win = Window(c)
Gtk.showall(win)
sleep(0.1)
@test Graphics.width(c) == 208
@test Graphics.height(c) == 207JuliaGizmos/GtkReactive.jl#87 |
|
Since OSX worked at one point, in the absence of better ideas I'd recommend checking out older versions and testing them. |
|
In search of reasons... It looks like my julia> Homebrew.brew(`reinstall gtk+3`)
==> Reinstalling gtk+3
==> Downloading https://download.gnome.org/sources/gtk+/3.24/gtk+-3.24.8.tar.xz
Already downloaded: /Users/ian/Library/Caches/Homebrew.jl/downloads/e962619b2823e9ecdba6611331876cf0daa34bebcfaa921eb61d03d300b1c22b--gtk -3.24.8.tar.xz
==> ./configure --enable-debug=minimal --prefix=/Users/ian/.julia/packages/Homebrew/s09IX/deps/usr/Cellar/gtk+3/3.24.8 --disable-glibtest --enable-introspection=yes --disable-schemas-compile --enable-qua
==> make install
Last 15 lines from /Users/ian/Library/Logs/Homebrew/gtk+3/02.make:
CC libgdk_3_la-gdkenumtypes.lo
CC libgdk_3_la-gdkmarshalers.lo
CC libgdk_3_la-gdkresources.lo
GEN gdkconfig.h
CC deprecated/libgdk_3_la-gdkcolor.lo
CCLD libgdk-3.la
GISCAN Gdk-3.0.gir
gdkversionmacros.h:35: Warning: Gdk: multiple comment blocks documenting 'GDK_DISABLE_DEPRECATION_WARNINGS:' identifier (already seen at gdk.c:106).
GICOMP Gdk-3.0.gir
Could not find GIR file 'GdkPixbuf-2.0.gir'; check XDG_DATA_DIRS or use --includedir
error parsing file Gdk-3.0.gir: Failed to parse included gir GdkPixbuf-2.0
make[3]: *** [Gdk-3.0.typelib] Error 1
make[2]: *** [install-recursive] Error 1
make[1]: *** [install] Error 2
make: *** [install-recursive] Error 1
READ THIS: https://docs.brew.sh/Troubleshooting
ERROR: failed process: Process(`/Users/ian/.julia/packages/Homebrew/s09IX/deps/usr/bin/brew reinstall gtk+3`, ProcessExited(1)) [1]
Stacktrace:
[1] error(::String, ::Base.Process, ::String, ::Int64, ::String) at ./error.jl:42
[2] pipeline_error at ./process.jl:785 [inlined]
[3] #run#515(::Bool, ::Function, ::Cmd) at ./process.jl:726
[4] run at ./process.jl:724 [inlined]
[5] #brew#4(::Bool, ::Bool, ::Bool, ::Bool, ::Bool, ::Function, ::Cmd) at /Users/ian/.julia/packages/Homebrew/s09IX/src/API.jl:19
[6] brew(::Cmd) at /Users/ian/.julia/packages/Homebrew/s09IX/src/API.jl:11
[7] top-level scope at none:0Running |
|
And I tried rolling back to all v1.0 compatible |
|
I am on OSX Mojave and Gtk.jl is working fine here. |
|
Ah.. @damiansp is experiencing the same issue over at JuliaImages/ImageView.jl#175 so at least I'm not alone.. |
|
Perhaps the Lines 47 to 56 in 636d0fe How should Line 386 in 636d0fe |
|
I have the same issue on OSX Mojave. This happened three days ago. I had Gtk running, but drawing on Canvas was about factor 10 slower than on Linux machine. So I updated and rebuild Gtk, which produced exactly the same error of canvas not rendering. Yesterday I tried to go to older Gtk version but then Cairo has build errors. That is, I removed all julia packages and did Btw, I my case ENV["XDG_DATA_DIRS"] is defined after build to ".julia/packages/Homebrew/s09IX/deps/usr/share" |
|
Ok, I managed to get it working on OSX Mojave. [email protected] depends on [email protected] Following the hints in these issues, I downgraded glib from v.2.6 to 2.58.3 (both on systemwide homebrew and on julia's local Homebrew), after which I could build Cairo 0.5.6 and then Gtk 0.56. Note though, that I again experience the performance issues: rendering some images on Canvas is about a factor 10 slower than on a comparable Linux machine. |
|
ok. Good to know, but the slowdown you see is concerning. I had initially thought that Gtk v0.17.0 was just a Project.toml & travis update, from the release tag notes, but it seems the release notes missed a lot of other changes. @tknopp I'm wondering why you don't experience this. Is your homebrew up to date etc.? I would assume that breaks it, if you aren't. |
|
I am not sure if my Homebrew setting is up to date. Currently, I need a working environment and will therefore not update in the next couple of weeks. |
|
@tknopp Hey! I think this is still and issue. I cannot get anything to show up on Mojave. |
|
I have upgraded to Mojave and it still works. |
|
I should rephrase, a window renders, but that is all. What version of homebrew are you using? I will check mine and report back tonight. @ianshmean are you able to get the example on the Gtk.jl docs to render a functional button? |
|
@tknopp I am also having this issue. I am running Julia 1.0.1 on Mojave. I have tried to download both my Cairo and Gtk packages, but they keep defaulting to the #master package even when I try to add an older version. Attached is my code below. (v1.1) pkg> add [email protected] julia> Pkg.status() |
|
the Gtk.jl version does not matter, see #421 (comment) what matters. |
|
I can confirm that downgrading glib to 2.58.3 fixes the issue: using Homebrew
Homebrew.brew(`unlink glib`)
Homebrew.brew(`install https://raw.githubusercontent.com/Homebrew/homebrew-core/b27a055812fe620e0d3dbe67f2a424ed3a846ecf/Formula/glib.rb`)Quit and relaunch Julia afterwards. (Took a while to hunt down that URL, mainly due to having to download the entire non-shallow Git repository of Homebrew, Github not providing access to it. I don't know what the Homebrew devs are smoking having removed an easy way to install old versions. Git, nuts, and bolts, probably!) |
|
I can confirm that downgrading glib to 2.58.3 fixes the issue: |
|
Testing now! |
|
Sorry but… you call #435 a fix? Just pushing the ball to the user who is still going to run into an error and then supposed to hunt around the web, now hopefully finding your |
|
(I guess I'll just use external viewers, avoiding the plague-that-killed-Linux of Gtk that way as well. Julia has the same problems that Octave always had and which is why it never took over Matlab: absolutely shoddy and fragile graphics system. Just things put together with duct tape and cable ties… which closing this issue with #435 proves.) |
|
I agree that #435 is not fixed but please stop ranting over a project that is made by volunteers. Gtk.jl is currently more or less maintainer-less, so what do you expect? |
|
@vomout just trying to do what I can to help as many people as I can. I wish I had a better solution. Sorry if I made it seem like I “solved” the issue rather than just finding a workaround. |
|
I suppose I can write a custom script that checks the os and if you’re on a certain OS, it gives a warning and tells you to go run the file... @tknopp do you think this will help at all or no? |
|
There's renewed efforts into getting the deps of Cairo and Gtk built through BinaryBuilder. It's no small task, but if working should resolve this issue properly. In the mean time, fixes like you suggest @logankilpatrick seem like a good idea, but implementing user warnings in |
|
I'll take a look tonight @ianshmean |
|
As indicated in JuliaGraphics/Cairo.jl#229 (comment), the solution could be a BinaryProvider with existing binaries. This would be much easier than the BinaryBuilder solution. Its just that somebody needs to make this. Until now, nobody had bandwidth. |
|
Indeed. But also, check out the |
|
@vomout to be clear this issue was closed automatically when merging because of the "close" keyword in the PR, it doesn't necessarily mean it's fixed. But having a workaround in the doc is better than not. We can reopen it if needed though. |
|
And what is that BinaryBuilder supposed to do? Distribute an obsolete version of glib just for JuliaGraphics? If so, how about actually figuring out what the real problem is and fixing it? Why does a newer version of glib not work? 2.58.3 is the last before 2.60.xx in Homebrew, so what happened between those? Did the glib authors completely change how functions are parameterised? If not, does Glib.jl directly access some data structures that were changed? If they did not change parameterisations/data structure contents, then was some function removed that Glib.jl is using? But shouldn't in that case Julia at least complain about it as a missing function? If it's API binary incompatibility, then—while a fix is being worked on—why does something not detect it? Can't test cases be implemented (possibly in C) to check that the API is what is expected? Can't Glib.jl at least check the version and fail with a complaint if it's known not to be binary-compatible? If it's not API incompatibility, and just on MacOS, then why is it just on MacOS? That would be very odd, Glib shouldn't be particularly OS-related at all. And, please, everyone, complain to Homebrew devs about how they were smoking some seriously strongly iPhone-infused herbal things when they removed support for easily installing/requesting older versions. Wouldn't it be nice if—while support for latest versions of glib is being implemented—Glib.jl could simply ask for a specific version? It really gets me at least once month, having to dive into the histories and manually constructing URLs where to get old versions. (hg-git—the sane user interface to git, via Mercurial—is rarely compatible with latest Mercurial, and pinning in Homebrew is not reliable.) (No, I'm not going to use serious amount of my time to learn and figure out Glib and whatever. If I use a lot of time it is better spent implementing something that doesn't depend on G-land.) |
|
Disclaimer: I have no idea what was the problem discussed here, I'm only going to reply to one point.
The goal of BinaryBuilder/BinaryProvider is to provide a single tested version of the library, pre-built for as many platforms as possible. When wrapping a library, it's important to target a specific version, it's going to be a mess if on a platform you have vX.Y.Z and on another one vA.B.C, because of API changes. Regarding glib, currently we build v2.59.0 which is 8-month old (see https://github.com/JuliaPackaging/Yggdrasil/blob/1d5bfb92562a583988e630875d6ad5b6fcbe2873/G/Glib/build_tarballs.jl), just because it's the last one that can be built with Autotools. As soon as we get support for Meson in BinaryBuilder, we can move on to build more recent versions. |
|
@vomout Do you volunteer to work on it and do answers to your questions speed up the process? Or do you just want to complain about the experimental state of providing binary dependencies in julia? Because the second one has been done already a few times by a lot of people - incl. myself. There was no BIG change in glib, but afair (in BinDeps/Homebrew and Mojave there are more problems) BinDeps opens libglib.so two times - the first time to check if it exists and the second time to work with it. Unfortunately libglib has some own memory management that is setup at opening time and surprise, surprise strange things start to happen if you open it a second time. These libs have not been designed to be reopened or initialized at runtime, but rather to be loaded by ld.so - so at the time of process initialization. Afaiu this is already true for long time and just by sheer luck never showed up as problem in julia/BinDeps on all plattforms. |
|
@lobingera oh, that could explain some other issues as well (high idle CPU usage after a while and occasional crashes with the whole G-land loaded as required by ImageView). Probably not #437, though, which I think is another similar fundamental error with how the G-land is being used. As said in my earlier post, I won't waste my time on G-land, but I could possibly lend a hand with other more generally useful things—if it does not involve touching Git, doing rebase rubbish instead of standard merges, etc. (In other words, if I can work with the history-preserving non-garbage-collecting Mercurial and hg-git without messing things up.) |
|
@vomout The high CPU i'd rather put on the (missing) integration of the Gtk event loop into the uv basis of the REPL. |
So that would probably be the same as #437: window content is not refreshed in a computational loop (drawing results on each iteration of an algorithm) until returning to the command line or unless an (initial) sleep call is performed. That somehow seems to pass control to the Gtk event loop. Probably |
Is the error we're seeing here a bug or misuse issue via
VideoIOorImageView?JuliaIO/VideoIO.jl#150
@kmsquire
The text was updated successfully, but these errors were encountered: