Set the active display's viewport as priority rectangle on the image.
Update the rectangle in the default implementations of
GimpDisplayShell::scaled(), ::scrolled() and ::rotated(), which isn't
entirely correct yet but much better than before, and the only "bad"
thing that can happen with a bogus priority rectangle is that the
image is updated as out-of-viewport as before, just differently.
Change gimp_get_display_name() to also return the screen, and its
implementation in the GUI to return the initial monitor during
startup. Retrieve that information in app.c using a weird callback
construct and pass the monitor to file_open_from_command_line().
Half-related, add screen and monitor parameters to GimpDisplayShell
and use these initial values for calculating the canvas's initial
extents.
The image windows still don't position themselves correctly though
because we have no mechanism for that whatsoever just yet, but we now
at least pass the needed monitor information to the right objects.
Add a "monitor" parameter and return something reasonable, instead
of a useless resolution average of all the screen's monitors. Also
require a screen to be passed now.
Along with this change, the snap preferences have been moved from
GimpDisplayConfig to GimpDisplayOptions, where it makes much more sense.
One of the consequences is that there is no need to duplicate these
values in GimpDisplayShell anymore to differenciate defaults and
current settings.
The main change is that even with only 1 image in single window mode,
there is now a tab.
Also whatever the number of images when you hide docks with Tab, no tabs
are shown.
This removes the obsolete check which makes the tool fail from
gimp_display_shell_set_mask(). Also change the foreground select tool
and the display mask from using GimpChannel to GeglBuffer, because
that's what it needs, simply buffers. Most changed files simply newly
include <gegl.h> because a GeglBuffer appeared in two headers.
First version of display rotation, inspired by gimp-painter.
The rotation always happens around the image's center.
The only "UI" for rotating is currently shift+middle-drag and
shift+space-drag. Control constrains the angle to 15 degrees
and is currently the only way to go back to "no rotation".
and don't use them for (un)transforming integer coordinates. Everything
seems to work fine, but this sort of change has caused off-by-one errors
before, please review.
Recent Cairo uses SHM transports when available, and exposes the ability
for its users to manage images shared between it and the display.
This allows us to eliminate copies, and if the architecture supports it
even to upload directly into GPU addressable memory without any copies
(all in normal system memory so we suffer no performance penalty when
applying the filters). The caveat is that we need to be aware of the
synchronize requirements, the cairo_surface_flush and
cairo_surface_mark_dirty, around access to the transport image. To
reduce the frequency of these barriers, we can subdivide the transport
image into small chunks as to satisfy individual updates and delay the
synchronisation barrier until we are forced to reuse earlier pixels.
Note this bumps the required Cairo version to 1.12, and please be aware
that the XSHM transport requires bug fixes from cairo.git (will be
1.12.12)
v2: After further reflections with Mitch, we realized we can share the
transport surface between all canvases by attaching it to the common
screen.
v3: Fix a couple of typos in insert_node() introduced when switching
variables names.
v4: Encapsulating within an image surface rather than a subsurface was
hiding the backing SHM segment from cairo, causing it to allocate
further SHM resources to stream the upload. We should be able to use a
sub-surface here, but it is more convenient to wrap the pixels in an
image surface for rendering the filters (and conveniently masking the
callee flushes from invalidating our parent transport surface).
Cc: Michael Natterer <mitch@gimp.org>
so it is just a bit more important than projection construction. Makes
initial image display show up in the right place much quicker, but
still after layouting the shell's widgets.
Sync GimpDisplayShell's properties with the default values when it's
emptied and turns into the empty display, so the default values used
when filling it with an image are displayed while it's empty.
- start_stroke()/finih_stroke() -> begin_stroke()/end_stroke()
- process_event_queue() -> process_stroke()
- GimpMotionBuffer::motion() -> GimpMotionBuffer::stroke()
- add GimpMotionBuffer::hover() and process_hover()
- remove push_event_history() and pop_event_queue() from API
The thing works like this:
- Motion events are continuously fed into the buffer using motion_event()
- begin_stroke()/end_stroke() correspond to BUTTON_PRESS/BUTTON_RELEASE,
the period between them is a "stroke"
- If motion_event() returns TRUE, we request "stroke" signals by calling
process_stroke() and "hover" signals by calling process_hover()
and emit the buffer's "motion" signal when a motion is supposed
to happen. In GimpDisplayShell, connect to GimpMotionBuffer::motion()
and call the tool.
This commit only adds the class and removes the members from
GimpDisplayShell, so everything looks more ugly than before, but
I wanted the member moving separate from any refactorings.
instead of turning it off unconditionally in gimp_canvas_init(), so we
have full control over buffering when we are rendering images, but let
GTK+ handle a flicker-free wilber itself.
Add a list of "track widgets" to GimpRuler and connect to their
motion-notify-event. Correctly translate the motion event's x/y to the
ruler's coordinate system when updating the marker.
which is supposed to set up a widget for tablet events and make sure
the context changes on device changes. "supposed" because everything
is currently horribly broken on GTK+ 2.x. Use the function for all
affected widgets except for the canvas.
