On 04/21/2018 03:16 PM, Øyvind Kolås wrote:
>
> Updating the display as quick as possible after receiving motion
> events, rather than rendering everything and updating at a low
> frame-rate, is a known feature - not a bug. Until things are fast
> enough to do 15fps of the entire viewport - for
I'm not the qualified person to respond to this, but: my understanding
was that App-Image versions use that directory so as not to mess with
normal installs, which is exactly how I would hope it would work... e.g.
they're supposed to be 'portable' etc. but need to store their user
settings some
Brush (and selection) outlines are based on a 50% threshold -- anything inside
the area receives over 50% of the effect and anything outside receives less.
For low-sharpness ("blurred") brushes this can indeed create some ambiguity
about exactly which areas are affected how much, and currently
On Sat, Apr 21, 2018 at 05:12:45PM +0200, rich404 wrote:
>
> I do not suppose any of you mailing list guys ever even think of looking at
> the
> gimpusers forum, after all why should you.
>
> but similar question came up a few days ago
>
> http://www.gimpusers.com/mailmsg.php?89758%40forums.gim
Thanks a bunch, Rich -- that script works without error and much faster,
too, and the masks are in the proper order when done.
But it seems a lot less aggressive; meaning, the "LLL" mask still
includes much of the image, not just the brightest parts. It's working,
just doesn't generate as stro
>Yeah it was a couple years ago, so it's lost to the fog of memory. :-)
>I
>think I was updating an old script to be compatible with the more
>recent
>versions of gimp. I think I just edited the text file directly.
>Anyway,
>guess I'll dive back in again.
>
>I reported it as a bug instead of just d
On Sat, Apr 21, 2018 at 8:52 PM, Steve Kinney wrote:
>> Some caveats I noticed:
>>
>> - The size of the image canvas, layer in question, and current zoom level
>> seem to have no impact on redraw times; only the actual size of the image
>> window whose area is being redrawn.
>>
>> - Visual artif
On 04/20/2018 08:08 PM, Richard wrote:
> If you have the ability to record your steps on video then that could be more
> helpful than static screenshots and verbal explanations. But as a quick
> experiment, I can confirm that moving layers can result in slow redraw times,
> potentially creati
Just to follow up -- Michael Natterer has fixed this... turns out the
script was working fine but the error dialog was unnecessary. Thanks all!
https://bugzilla.gnome.org/show_bug.cgi?id=795418
-c
On 04/20/2018 04:14 PM, Pat David wrote:
I’ll have a look at it when I get a moment. Might just n
If you have the ability to record your steps on video then that could be more
helpful than static screenshots and verbal explanations. But as a quick
experiment, I can confirm that moving layers can result in slow redraw times,
potentially creating general visual mess (but the move operation ot
On 04/19/18 20:58, TerryEA wrote:
3. Some of the tools have very weak affects. EXAMPLE-1: clone barely paints area
and takes a lot of passes to cover properly.
Check the Opacity setting for that tool, likely not at 100%
___
gimp-user-list mailing list
On Debian.
I am trying to build RC2 and as far as I can determine I have all the
correct versions of the prerequisites installed. But building it fails
with
/usr/bin/gegl: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libgegl-0.3.so.0: undefined symbol:
babl_process_rows
and
/usr/lib/x86_64-l
12 matches
Mail list logo
