This way, we would queue a lot less canvas region unnecessary redraws.
We still remake the time-before-last-draw check in the draw() signal
handling before we want to update the marching ants index for draw
events coming for other reasons (canvas updates, moving/zooming on
canvas, exposition changes, etc.).
… displayed.
We should use the dimensions from the GimpDisplayShell not the the
GimpCanvas. Indeed the canvas is shorter when rulers are visible, hence
the selection next to the extreme sides (bottom and right sides of the
canvas) was not drawn.
As suggested in a comment (itself coming from an IRC discussion), we
should not use gdk_window_(begin|end)_draw_frame() functions as this
works on X, but not on Wayland anymore. Instead draw directly during
draw() call of the shell widget, and force it to happen regularly, to
update the marching ants, via gtk_widget_queue_draw_region().
This is tested and works on Wayland. Please everyone, test thoroughly to
make sure it works well in all situations, and also that we don't get
any unexpected slowdowns.
Since the symptoms are very similar, it is highly possible that it also
fixes the issue #5952 too, for selection not showing on macOS since Big
Sur 11 (maybe they changed the same way as Wayland did). Unfortunately I
can't check this myself. Please test, whoever has access to a macOS Big
Sur and can build GIMP!
This new job resulted in a package which allows to run GIMP on Windows
(as tested in a VM; at least it starts, I can create a new canvas and
paint). Of course I think this will need to be tweaked a little bit
more, as I'm sure we miss things here and there.
At the very least, even though I add the Python and Luajit binaries,
GIMP on Windows didn't find them. This will need to be investigated.
Also it looks like opening from a remote location may not work. Not sure
if this about a missing GIO module or maybe something which works
differently on Windows (I was not even able to drag'n drop from the
browser!). Anyway this needs to be looked at as well.
Note that gdk-pixbuf-query-loaders is apparently unneeded when GIMP is
built this way (unlike with our crossroad build).
All this to say that this is still an early attempt to full CI build for
Windows.
It doesn't invalidate the crossroad build, because cross-compilation
builds from Linux will always stay very important for Linux developers
to be able to easily fix Windows bugs too; yet the crossroad build has 2
major issues:
1. We haven't figured out yet how to run GObject Introspection tools for
cross-builds, so the crossroad builds are not full-featured (and this
is quite a major feature we are missing!).
2. Also I will want to run the installer in the CI at some point and the
one we use can only run on Windows itself AFAIK. We could try to run
it through Wine, but still anyway the point 1. is already quite a
blocker, let's do the simple thing.
Note that we will likely want to move to meson for this build, because
autotools is very slow on Windows. But as long as the few blocker meson
bugs are not fixed, let's stick to the slow yet good build.
These are interesting and may find very specific bugs from time to time,
but the usefulness is rare enough not to warrant to run at each commits.
This is just a waste of resources.
For scheduling finesse (in case we want to separate these in separate
scheduling), also rely on the existence of variables during scheduling.
Finally make sure that the non-scheduled builds are not run in schedule
pipelines (they are already run far enough).
In particular add the need to wait a bit for installers before actually
publishing news. Also add a few usage examples for the gimp-web helper
tools for binary file publishing (torrent creation and mirror checking).
Without this, the native Windows GIMP build fails in CI with:
> make[2]: *** No rule to make target '_install\include\gegl-0.4\gegl.h', needed by '../libgimpcolor/gimpadaptivesupersample.lo'. Stop.
Even though `gegl.h` is present (as checked through artifacts). It's
just so weird.
The build rules were highly inspired by other projects on GNOME's
Gitlab. All of them used to build with ccache. It worked fine for the
main build, but completely broke GObject Introspection build on both
babl and GEGL. And the worse thing is that meson was absolutely not
displaying the error, just saying it failed (even in verbose mode). A
lot of time wasted trying to debug.
Therefore let's get rid of ccache, but only for babl and GEGL. Keep it
for GIMP itself as it works fine there.
Other minor changes:
* Build from the build dir, rather than source. The other way around
works too, but I actually find commands simpler this way.
* Adding artifacts.
Ok so this is horrible, but this is the only way I found to get past
some errors. The build would break randomly (sometimes it would,
sometimes not, with the same gitlab-ci rules) because of existing files.
The errors would be the following when trying to install dependency
packages with pacman:
> mingw-w64-x86_64-glib2: /mingw64/bin/libglib-2.0-0.dll exists in filesystem
At first I thought it was a bug in Pacman or MSYS2, but on some runners,
I had such warnings at the very start of the runner (note: on some
runners, the warnings would not be displayed even though the final
conflicting files error would still happen at the end of the logs):
> warning: failed to remove mingw64/bin/libglib-2.0-0.dll: Invalid argument
It looks like it might be related to this Gitlab bug where a runner
would fail to clean its environment:
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1839
In any case, the only way I found so far is to manually remove the
conflicting files before installing the packages supposed to install
these. This is completely horrible (and I sure hope it won't come up
again with different files each time) but really the only workaround I
found so far (I think a real solution will have to come from Gitlab code
or from the GNOME admins, not sure what is the exact source of the
problem).
Just an initial test to get a hang of the thing, mostly inspired from
GTK gitlab-ci rules adapted to our build.
All in one job (deps, babl, GEGL, GIMP itself) for now, for simplicity
of debugging. We'll see later to break this into CI sub-jobs.
Simply it should free only GimpProgressDialog as these would be
dedicated dialog (with no meaning once progression is done), and leave
alone other GimpProgress widgets. In any case, it should not output
CRITICAL errors on these.
Fixing the following CRITICAL:
> GIMP-CRITICAL: gui_free_progress: assertion 'GIMP_IS_PROGRESS_DIALOG (progress)' failed
When dropping an image on the toolbox.
Exporting to psd could result in very large files which often failed to
load in both GIMP and PS when a group layer with a layer mask
was present.
Reported on our IRC channel with a sample xcf which made it
possible to figure out the problem.
The port had a slight error, because in gimp-2-10, the display_ID
actually had 3 states: 0 when gimp_export_image() kept the original
image to which we just add a preview layer, -1 when it created a new
image which we wanted to put in its own display, and the display ID
itself when created.
With the new API where display variable is an object, we can only have 2
cases. So I create an additional variable separate_display to make the
distinction.
Jernej Simončič