I'm not sure if I understand your bug-report correctly but it seems
you are aksing for two things:

(1) You want layers to be the size of the image or at least want the
    fact that they are smaller to be hidden in the user interface.
    Layers should enlarge automatically if needed.
(2) You want the Move tool to move the active layer, not the one that  
    the user clicks into.

Point 2 can easily be achieved by pressing Shift when using the Move
tool and we don't intend to change this.

Point 1 has been suggested before but I'm not sure if there's a
bug-report for it. Have you checked before you filed this report?

yes, maybe I was too verbose and didn't reach the point. The point two
is my lack (I didn't know I could do it using Shift as modifier)


The point one regards layer size policy:

    I think that the layer size should be dynamically determined by
GIMP depending on its contents and not specified by the user.
Consequently to this, there's no need for layer boundaries to be shown
and there's no need to specify the layer size when creating a new layer.

This way we can simply add contents to the layer which dynamically
resizes when we draw something in it. Of course this means that a
layer can be bigger in size than the canvas size. Parts of a layer
which are outside the canvas will be hidden but not cropped. Moving
the layer we can get them visible or not.

Point 2 (Moving transparent layers) should be marked as a duplicate of
bug #51108.  This feature is hidden in GIMP 1.2.x.  This will be solved
in GIMP 1.4 (fixed by Mitch on 2001-11-26).

Point 1 could be a good idea in some cases: most users do not care about
the size of the layers, they just want to be able to add something more
to the image.  But this may be annoying in some other cases, for example
when trying to optimize animations.  Also, even if the users should not
have to care about that (in an ideal world) it is probably better to
make the users aware of the size of the layer so that they can have an
idea of how much memory is used by the layers.

Summary:

 1. Layer mamagement should be as easy/fast as possible

 2. Possible solution: Draw layer boundaries but let GIMP dynamically
resize them

 3. User doesn't have to manage memory, s/he has to draw



Okay, I agree with you Raphaël. Let the user know how much memory GIMP
is using is good. I don't think doing this showing the layer boundary
is a good choice. I think that working with layers should be as easy
and less time consuming as possible so we can concentrate in drawing.

By the other side, I have no experience in animation with GIMP, but I
think the benefits of having layers working the actual way is not that
much. I belive that a feature is powerfull/usefull if it helps doing
the job. Current layer management doesn't help and is a job the user
should not do. Remember that the GIMP's target user doesn't
necessarily want to know how things works inside. 

A good solution could be to show layer boundaries but let the GIMP
resizes them. Boundaries should be less visible so they don't seem
like an unsurmountable barrier (not yellow-black but, for example,
grey-white). They can be automatically turned yellow-black when doing
animations.

I'm insiting because I think that this part of layer management should
really be done by the computer and not by the user. GIMP's goal is to
let us drawing and do photo editing (and doing simple animations) not
to manage memory.

Let the GIMP manages dynamically layer size also improve memory usage
cause they are always adapted to the image they contains. It is common
to have a layer filled in his 20%-50% area. With dynamic layer size we
could have always the best memory usage.

I have changed the title of this bug report so that it describes it a
bit better.

There are many issues to consider if we want the layers to grow
automatically and to have almost invisible boundaries:
- The size of the layers will still be important if the user tries to
  fill a layer with some color: only the layer will be filled, not the
  whole image.  So the boundaries will automatically be visible for
  the user.  Note that some layers can be smaller than the image but
  some of them can be larger, so changing the fill behavior to fill
  the area of the canvas would be bad for larger layers.
- Should the layers grow if the user is drawing with a paintbrush
  and moving towards the edge of the image?  This may not be easy to
  do (managing the scrolling in a smooth way, making sure that the
  brush strokes do not jump suddenly, etc.)
- If we allow the layers to grow automatically, we also have to find
  a way to allow the layers to shrink automatically.  Otherwise, the
  images will always consume more and more memory, even if the only
  thing that the user does is to accidentally add a single pixed far
  away from the center of the layer (enlarging that layer) and then
  erase it.
- But if the layers can shrink automatically, we loose one useful
  feature of the layer boundaries: it is useful to be have a layer
  with some transparent areas around an object if you use some guides
  to align the layer precisely.  This is especially useful if you
  have several frames of an animation (one frame per layer) and you
  want to align all layers in the same way, even if the object is in
  a different position in each layer.
So this problem raises a lot of interesting questions.  I don't think
that it can be solved easily.  We really have to think about all the
features of the user interface and see how they would interact with
each other.

Ok. Image Manipulation and Aminations are two different things. They
require two different interfaces to be done. Actually GIMP is used,
say, 70% for image manipulation and 30% for simple Animations. The
layer interface, as it is, is more useful for Animations than for
Image Manipulation.

Possible Solutions:
1. When you fill a void layer, the area filled will be the image size;
2. Layers grows dynamically but don't shrink until you save the image;
3. We need a different interface for Animations.

1. DRAWING POLICY
Try to think a layer as an infinite plane. We don't have boundaries.
It's logical, in this case, to fill only the visible area (where
visible is not the user visible area which could be zoomed, but the
image size area).
You cannot draw outside the image boundaries. To draw outside the
image boundaries you have to manually move the layer and than draw on
it. This mean no scroll is needed; of course this feature can be added
later.

2. DYNAMIC LAYERS
Layers could initially have the same size of the image and grow as
needed. GIMP doesn't need to dynamically shrink them. This can be done
when saving the image or automatichally when the memory gets full
(much like a garbage collector in interpreted programming languages)

3. INTERFACES
Boundaries are useful in Aminations. This is a "way of doing things"
or "best practice" but not a design goal. Probably the actual way of
doing animations in GIMP was influenced by the layer design. This does
not mean this is the only or the best way to align layers.
What do you think about introducing the concept of Frame? For the user
, a Frame is what a Layer is in the current version of GIMP. Inside
GIMP, Layers and frame are very different things. A Frame is a logical
rectangular boundary while a Layer is the phisical canvas for the
frame. Consequently, a Frame can be bigger or smaller than a Layer.
Its only purpose is to layout frames in the animation.

Hmmm...  I'm not sure that your suggestions would work well.  Here are
some potential problems:

> 1. When you fill a void layer, the area filled will be the image size;

What should happen for the layers that are partially outside the
canvas?  This can happen if you move a small layer partially outside
the canvas or if you create a layer that is larger than the canvas.
Currently, the layer is filled completely and its size is not changed.
With your proposal, I assume that you would have to enlarge the layer
so that it covers the whole canvas as well as the area that is
outside the canvas.  Then you have two choice: either fill the whole
layer (including the part that is not visible) or fill only the
visible part (canvas area).  In both cases, the user cannot ignore
that the layer has a limited size, because its boundaries will become
visible if the layer is moved again or if the canvas is enlarged.

> 2. Layers grows dynamically but don't shrink until you save the image;
> Layers could initially have the same size of the image and grow as
> needed. GIMP doesn't need to dynamically shrink them.

This would significantly increase the amount of memory required when
you work with multiple layers on a large image.  When I am creating an
image using some photos, text and so on, I frequently have more than
10 layers but most of them are (much) smaller than the full image.  If
all my text layers (for example) had to be the same size as the image,
then I would need more memory.  Some of it could fortunately be
optimized away with some copy-on-write tricks, but there would still
be a waste of memory compared to the current solution.

> 3. We need a different interface for Animations.
> Boundaries are useful in Aminations. This is a "way of doing things"
> or "best practice" but not a design goal. Probably the actual way of
> doing animations in GIMP was influenced by the layer design. This does
> not mean this is the only or the best way to align layers.

Layer boundaries are useful for other tasks than animations.  I cited
the animations because this was the first example that came to my
mind, but if you look around and read some GIMP tutorials, you will
see that the layer boundaries together with the guides are very useful
for other things, such as aligning several text layers in one image.
I agree that this may not be the only or the best way to do it, but
it is very convenient and it is not really related to animations.

Just to be clear: I think that your proposal is interesting, but we
should study all pros and cons carefully in order to have a consistent
user interface.

*** Bug 98776 has been marked as a duplicate of this bug. ***

I'll handle the point 2 first, because I think it's more important
than 1. Sorry for the length, but I'm not sure how to better express
my ideas... Hopefully this bug isn't forgotten even though there has
been some time since the last update.


2) automatic layer sizing

When I draw or manipulate an existing image, I'm not interested how
"big" or "small" a single layer is. I consider a layer as an infinite
2D layer and if I fill it with a gradient that gradient should go from
minus infinity to plus infinity, so to speak. However, I'm aware that
such infinite layer cannot be easily handled (one could save
procedural layer "edges" as all methods that could generate infinite
layers can be executed delayed. Required parts of the infinite layer
could be rendered on the needs basis. Only the part that the user
really has draw would be saved as pixels.)

So get rid of the layer edge (black-yellow dashed line) because that's
an implementation detail. As an end user, I'm not interested if a
single layer is saved as a huge array in the memory or as a linked
list of brush-sized small images positioned with vectors. I'm not
interested in the dimensions of the current memory buffer used for the
layer and GIMP must handle such issues under the surface. For example,
if I take airbrush tool and draw over the edge of the image my drawing
shouldn't be sent to bit heaven but it should be saved in the layer
and I can move the layer later if I need to access that part of the image.

Yes, I'm interested in memory usage, but it should have nothing to do
with layer "size" (the layers are infinite, remember?). If layer is
indeed saved in memory without any optimizations as a bitmap array I
could use layer size as a thumb rule for memory usage but as an end
user, why should I make such assumptions? How about printing layer
memory usage in megabytes in the layers dialog instead? That way I
could immediatly see if a single layer takes huge amounts of memory
and perhaps command GIMP to "crop layer content to visible area", or
something, to reduce memory usage.

I'm afraid that doing this change well is far from easy. I think The
Right Thing(tm) to do this, is to always draw to a new temporary
buffer (fixed size layer) positioned somewhere near the cursor
position and merge that layer automatically with the real selected
layer (the user thought he was drawing to) immediately after the user
pauses drawing. If the user keeps drawing without pauses you probably
need to allocate additional temporary buffers. Default buffer size
could be user defined so one could decide to target good performance
or small memory usage. The minimum buffer size should probably be the
current brush size. You can approximate the real content area with
these temporary buffers and perhaps internally save layer as
collection of non-countinous buffers created with a merge of
overlapping temporary buffers (for example, one layer could be made of
one big buffer and two small ones where the big one contains most of
the image and two small ones contain two small details far from the
main image area). A layer should be considered as a tool for drawing
and not as a bitmap array or block of memory.


1) fill

Here's a thought: for single color fills, the fill indeed fills the
whole infinite layer. It could be implemented as a metainformation for
the layer: "background color". All pixels that the GIMP has no better
information for, would be rendered with that background color.
However, because it would be really hard to expand this feature to
procedural effects like gradients and filter generated content I think
the fills too should be limited to some boundary. Layer bounding box
could be a good choice, but perhaps allow user to select the fill size
relative to bounding box in the preferences: something like 110% of
the bounding box could be a nice choice for more advanced users.

One more thing, don't copy Photoshop in this as it only fills visible
part of the layer even though it otherwise does implement
automatically sized layers.


3) markers and/or guides

As I said above, layer shouldn't considered as a bitmap array but as a
layer in the sandwitch that makes up the image. It should be possible
to attach guides and perhaps some kind of markers to each layer in
addition to attaching those to the whole image. A marker could be a
cross positioned in some given pixel position. A "frame" could be just
another type of marker where the marker featured two (top-left and
bottom-right) pixel positions. It should be possible to hide all
markers, guides and frames for a given single layer.

Changes at the request of Dave Neary on the developer mailing list.  
I am changing many of the bugzilla reports that have not specified a target
milestone to Future milestone.  Hope that is acceptable.  

Well, now I am convinced that allowing layers to grow automatically
(and maybe making the layer boundaries invisible and irrelevant) can
be a good thing.  This is what Photoshop does and according to what I
read, it seems to be a significant improvement in usability.

In order to implement this, we may need to:
- Support "sparse layers", i.e., layers in which many tiles are simply
  not allocated because they are transparent.
- Be able to free some tiles after their contents have been deleted.
  This could be done after each operation that deletes some pixels
  (makes them transparent), but it is probably more efficient to do it
  only when the image is saved or when the user explicitely requests
  this to be done.
- Store the bounding box of the non-transparent area(s) in each layer
  separately from the tile/layer boundaries, so that it is still
  possible to use some reference for alignment, etc.  Or we could use
  some other kind of markers, as suggested in the previous comment.

I am still not sure about what to do for fills.  The Photoshop way of
doing it is easy (fill only the visible area) but may not be the best
solution if we want the layers to appear as having no limits.  Anyway,
the issue of fills can be revisited once we get a first implementation
of "layers without limits".  The target milestone is still "Future"...

Well having sparse layers that discard content after things become
transparent pretty much throws out the window discussion about keeping
around the RGB data of transparent pixels.

That aside, I have a pretty detailed idea as to exactly how to
implement this and am specifically looking at the features needed in
gegl to get something like this working.  It shouldn't be hard, and
should come about extremely naturally in gegl.

Basically, if we don't rely on a layer being a particular size, then
gegl is free to grow or shrink it as necessary.  Also, since layers
will be sparsly allocated, tiles will only be allocated if there is
something there to hold, and will not be allocated until needed.  This
includes tiles with some kind of default fill, as those can be
generated on the fly as needed just as easily as any other empty tile.
 This sparsness must be reflected in the file format.  So, the example
of drawing far away from the center will only allocate enough tiles to
hold that particular stroke, no more, no less.  As far as keeping the
"layer boundry" and the "layer bounding box" amounts to the have_rect
of the layer node and some relevent ROI that you are displaying (I am
not specificing if the ROI is due to some kind of "Frame" ui concept
or not).

This is another of the details I want to write up in my whitepaper on
gegl, which is due out as soon as I get some usable gegl/image stuff
in existance.

Sould we ever decide to implement this it IMHO absolutely needs
to be optional. Layer boundaries can be a very useful thing
for some use cases and again we cannot make the "painting"
use case easier to to for the price of disabling the feature
that GIMP is an excellent tool for aligning small pieces of
something to guides or the grid. I also doubt that photoshop
(with its automatic layer growing) allows layers to extent
beyond the border of the image, which is also a useful feature
we should not loose.

Also note that automatic growing is different from automatic
shrinking. as I said before, I'm against automatically
discrading areas or even treating transparent areas as
deleted (color wise).

I thought I had put in a bug/wish like this in the distant past, but #9 Mikko's 
comments are pretty much exactly my feelings on the subject.  The little yellow 
layer outline is an implementation detail, not an artist's concern.  If I paint 
past the point where we see a yellow outline today, I want it to just quietly 
expand that layer's extents to include my new artwork.

As for how to implement it, and what to do about erased tiles that still have 
useful RGB data, there are a couple of things that jump out at me.

(1) at some point, a sweep to optimize tile storage should be done.  The two 
suggestions were "continuously" and "at save."  A middle-ground would be to 
sweep whenever the user switches from one active layer to another, or whenever 
a plugin finishes its work.  The nice thing about sweeps is that it can be time-
limited (or background threaded?) to keep the interface responsive.  Sweep for 
dull tiles every once in a while, but don't spend more than 100ms on the task, 
for example.  Pick up where you left off on your next sweeping opportunity.

(2) I also agree that there is such a thing as "invisible but interesting" 
tiles.  Go ahead and store them.  But it's pretty quick to decide if a tile is 
both "invisible and un-interesting."  There is also room for 
optimizing "visible and un-interesting" tiles.  For example, if the whole tile 
consists of the same ARGB quad repeated for all pixels, then you can pretty 
much replace it with a tile marker that states such.  A scan for all-pixels-
identical is not too difficult.  I hereby coin the phrase "dull tile" to refer 
to all forms of tiles that can be easily represented by a simple duplication of 
a single color/alpha value.

(3) Tiles in the layer masks (and even the selection) could greatly benefit 
from such sparse storage.  Many times, a layer mask is a big bold black-to-
white gradient and huge expanses of dull tiles on each side of it.  Now we'd 
just be keeping the memory for those actual gradient tiles, and any other tiles 
where the user was hand-painting.

I was thinking about opening an enhancement request for this and saw it already
existed.
Well, despite the fac that not much has happened in this bug for a long time,
I'd like to adress one point:
It was was pointed that layer boundaries are important fot aligning layers,
since you can snap guides to them.
In photoshop, where there is no layer boundary, it is solved by allowing guides
to snap to the apparent edge of the layer contents - I suppose it works by doing
some sort of threshold operation on the layer alpha.

To move layer indepently from masks is a "must have" in gimp :-)

Putting on 2.10 milestone list since that's where we plan to implement this.

*** Bug 628162 has been marked as a duplicate of this bug. ***

We currently aim for 3.2, putting on Future for now

*** Bug 710524 has been marked as a duplicate of this bug. ***

*** Bug 648267 has been marked as a duplicate of this bug. ***

This is the key Photoshop killer feature gimp needs as soon as possible. Flexible layer boundaries is very important, even KRITA have this feature. Also when pasting a item it should be added as a new layer.

one case for Flexible layer is like this

case 1
you add a new layer
draw anything small on the centre
select the resize tool
at this point only the area of the layer with the drawing will be select for scaling. (just like photoshop)

case 2
you add a new layer
draw anything to the edge of the canvas
move the canvas and make some more space and continue drawing
select the resize tool
The whole layer area with the drawing (even the area outside the canvas area, if it got some drawing) will be select for scaling. (just like photoshop)

case 3
you paste an image smaller than the canvas size
it will be created as a new layer
select the resize tool
only the area with the new image will be selected for resizing

case 4
you paste an image larger than the canvas size
it will be created as a new layer
select the resize tool
the whole area with the new image (even the area outside the canvas) will be selected for resizing

This is how it works in photoshop and krita

Out of curiosity, how do the other applications deal with transparent areas which still have color information (i.e. their pixels are arbitrary RGB0 values?

*** Bug 796007 has been marked as a duplicate of this bug. ***

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/32.