When clearing a channel, do nothing if the channel is already
empty; otherwise, align the cleared rectangle to the channel
buffer's tile grid, so that all affected tiles are dropped, rather
than zeroed. Furthermore, only update the affected region of the
channel.
In commit c71b4916af, I forgot to disconnect signals on the bucket fill
options at finalization, leading the software to crash on an
non-existing tool.
After discussion with Sébastien Fourey and David Tschumperlé, it was
decided that a better fix for the edge case raised in #2785 was to add a
keypoint anyway, even if the point and none of its neigbours have a
positive smoothed curvature, yet they have a positive raw curvature. In
such case, we use the local maximum raw curvature instead of the local
maximum smoothed curvature.
In the perofmance-log viewer, add header-bar buttons to clear and
invert the selection, and allow inverting the selection by ctrl-
right-clicking on the sample-selection area.
Update the docs.
Additionally to sample merge and active layer, now we can only use the
layer above or below the active layer as line art source.
The line art fill is meant to work on drawing lines. Though sample merge
still is ok in many cases, the more you fill with colors, the more the
line art computation becomes unecessarily complex. Also when you use a
lot of layers with some of them already filled with colors, it makes it
impossible to colorize some line art zones with the tool. Moreover you
just don't want to have to hide every layers out there to colorize one
layer (especially background layers and such as you may want to see the
result with your background).
Thus we want to be able to set the source as a unique layer, while it
not being necessarily the active one (because you want lines and colors
on different layers). In this case, I am assuming that the color and the
line layers are next to each other (most common organization).
In GimpTileBackendPlugin, change the default tile multiplier,
specifying the ratio between the backend tile-size, and GIMP's
tile-size, from 2 to 1. Since we're reading/writing each GIMP tile
using a separate command anyway, using a large multiplier doesn't
provide any benefits, while it does have drawbacks. In particular,
it reduces the chance that a write operation will affect an entire
tile, which allows us to avoid reading the tile data from GIMP.
Add an internal _gimp_tile_ref_noinit() function, which increases
the ref-count of a tile *without* initializing its data (in
particular, without reading its data from GIMP, or zeroing it.)
Use this function, instead of gimp_tile_ref(), when storing a tile
in GimpTileBackendPlugin, to avoid unnecessarily reading the tile
data from GIMP.
In gimp_projection_finish_draw(), clear the chunk iterator's
priority rect before finishing rendering, since it's not needed at
this point, and this is slightly more efficient.
In GimpFilterTool, when the filter uses an on-canvas controller,
provide a toggle in the tool's filter-options dialog allowing to
toggle the controller's visibility. This allows getting the
controller out of the way when unneeded.
Add mew gimp_tool_widget_{get,set}_visible() functions, which allow
setting the visibility of a tool widget. While the widget is
invisible, it ignores all events.
In GimpDrawTool, do nothing in the tool-widget signal handlers if
the draw-tool isn't active, to avoid CRITICALs due to a NULL
display. This can happen if a widget is set before the tool is
started.
Add a GimpToolWidget::message signal, which can be emitted by tool
widgets to display a message, instead of using the ::status signal.
Add corresponding gimp_tool_widget_message[_literal]() functions.
Several en_GB to en_US.
Also "Show a preview of the transform_grided image". "grided" should be
"gridded", but I also have a problem with the underscore. Should it be
"transform-gridded"? Even so, does it really make sense?
I chose to just read "Show a preview of the transformed image", which I
think is simpler and the most understandable (we don't need to leak the
implementation with a transform grid into the human read text IMO). If
anyone think that was not the right choice, feel free to propose
otherwise.
Thanks to Bruce Cowan for noticing these.
In gimp_projection_chunk_render_start(), when the current
projection rendering is complete, but not finalized yet, and no new
rendering is started (since the current update region is empty),
make sure to invalidate the projectable's preview, since it
normally happens when rendering is finalized, which doesn't happen
in this case.
In GimpTileBackendPlugin, return NULL when fetching z>0 tiles,
instead of simply ignoring the z coordinate, so that the mipmapped
tile is rendered locally. Likewise, avoid storing z>0 tiles.
Note that this is suboptimal, since all the necessary level-0 tiles
need to be sent to the buffer as a result. Ideally, we should
extend the wire protocol to handle mipmapped tiles.
In the gradient tool, halt the gradient editor before committing
the filter, so that its image-flush idle source is removed before
applying the operation, to avoid flushing the image, and hence
restarting its projection rendering, during application.
In gimp_tile_handler_validate_buffer_copy(), temporarily remove the
source buffer's validate handler, is exists, so that the subsequent
gegl_buffer_copy() can use fast tile copying, using the TILE_COPY
command. GEGL currently only uses TILE_COPY when the source buffer
doesn't have any user-provided tile handlers.
In gimp_gegl_apply_cached_operation(), replace the use of
GeglProcessor with GimpChunkIterator, so that we use the same
chunking logic as for rendering projections. This has the
advantage of better chunk alignment to the tile grid and dynamic
chunk sizing, which improve performance.
Use chunking even when there's no progress indication, since it
generally results in better cache locality.
Factor out the region-chunking logic of GimpProjection into a new
GimpChunkIterator type, providing a generic mechanism for iterating
over a cairo region in discrete chunks. The iterator doesn't
perform any processing itself, but rather dispenses rectangular
chunks, which the user then processes.
Iteration is broken into intervals, the duration of which is
configurable. Each iteration begins with a call to
gimp_chunk_iterator_next(), after which
gimp_chunk_iterator_get_rect() should be called in succession to
fetch a rectangle to process, until it returns FALSE, which marks
the end of the iteration. Updates to the UI should take place in
the interval between iterations, but not during an iteration. The
iterator dynamically adjusts the chunk size according to processing
speed, in order to match the target iteration interval.
The iterator can be given a priority rectangle, which is processed
before the rest of the region. It can also be given a
representative tile rectangle, defining a regular tile grid;
dispensed chunks are aligned to the tile grid as much as possible.
This is sometimes asked, and myself also need to find it from time to
time. I may as well put the link inside the code comments, where it is
just easy to find!
Request pixbufs in double size and cache the created surface instead
of the pixbuf. This affects rendering icons and image thumbnails.
All other rendering (which is most previews) is not ported yet, but
just lacks HiDPI quality, there are no actual bugs.
Ryuta Fujii