Bug 428259 - Unnecessary transparent areas in layers take rooms in the layer size.
Summary: Unnecessary transparent areas in layers take rooms in the layer size.
Status: RESOLVED DUPLICATE of bug 457562
Alias: None
Product: krita
Classification: Applications
Component: Layer Stack (show other bugs)
Version: 4.4.0
Platform: Compiled Sources Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-26 07:41 UTC by acc4commissions
Modified: 2022-09-19 17:38 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Case 1 (1.43 MB, video/mp4)
2020-10-26 07:41 UTC, acc4commissions
Details
Case 2 (2.42 MB, video/mp4)
2020-10-26 07:41 UTC, acc4commissions
Details

Note You need to log in before you can comment on or make changes to this bug.
Description acc4commissions 2020-10-26 07:41:04 UTC
Created attachment 132746 [details]
Case 1

SUMMARY
Layer size expands when you're painting, but it doesn't shrink when you're erasing areas. I'm not sure this is intentional, but imo it makes it slower to move/manipulate layers for no reason. (Kinda reminds me of memory leak;)

*********What is odd is that, when you try to move the layer after erasing its parts, the 'border' of move tool (which indicates how big the layer is) appears around the actual size the the layer as if it properly shrinked. But on the layer thumbnail in the layers docker it's still expanded and the moving speed is still slow.

Case 1
STEPS TO REPRODUCE
1. Draw something small on a corner of the canvas.
2. Draw something small on the other side of the canvas, on the same layer.
---(note:2 is much slower to move compared to 1)---
3. Erase the part you drew in step 2 completely with a brush.
4. Check how the layer thumbnail isn't shrinked and how it is still slow to move the layer. It behaves as if its size stays expanded, although the border of move tool indicates differently.

Case 2
STEPS TO REPRODUCE
1. Draw something small and put it in a group layer.
2. Put a filter layer or filter mask inside the group layer.
---(note:the layer size expands into maximum at this point)---
3. Remove the filter layer or filter mask.
4. Check how the layer thumbnail isn't shrinked and how it is still slow to move the layer. It behaves as if its size stays expanded, although the border of move tool indicates differently.

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Is it impossible to make layer operations unaffected by the layer size in the first place? (e.g Firealpaca)
Comment 1 acc4commissions 2020-10-26 07:41:26 UTC
Created attachment 132747 [details]
Case 2
Comment 2 Tiar 2020-12-11 17:27:07 UTC
NOTE: Transform Tool also shows correct bounds.

Difference between Move Tool visible bounds and the slowness and the thumbnail is probably caused by some different ways of calculating the boundaries...

> Is it impossible to make layer operations unaffected by the layer size in the first place? (e.g Firealpaca)

Can you please elaborate? What layer operations? Using the Move Tool?
Comment 3 acc4commissions 2021-02-15 04:23:23 UTC
(In reply to Tiar from comment #2)
> NOTE: Transform Tool also shows correct bounds.
> 
> Difference between Move Tool visible bounds and the slowness and the
> thumbnail is probably caused by some different ways of calculating the
> boundaries...
> 
> > Is it impossible to make layer operations unaffected by the layer size in the first place? (e.g Firealpaca)
> 
> Can you please elaborate? What layer operations? Using the Move Tool?

Yes, using the move tool, transform tool etc. But nevermind. Just fixing the original issue would be enough (for now).
Comment 4 acc4commissions 2021-06-07 09:52:23 UTC
Any chance that this will get fixed for 5.0?
Comment 5 Halla Rempt 2021-06-07 12:33:46 UTC
Sorry, no. We had at one point a hack that would check whether all pixels in a tile were blank and transparent and then delete the tile, but that caused a lot of bugs, so we dropped that idea. The only thing we kept was the option to cut off layer data outside the image boundaries on saving.
Comment 6 acc4commissions 2021-06-07 14:23:02 UTC
(In reply to Halla Rempt from comment #5)
> Sorry, no. We had at one point a hack that would check whether all pixels in
> a tile were blank and transparent and then delete the tile, but that caused
> a lot of bugs, so we dropped that idea. The only thing we kept was the
> option to cut off layer data outside the image boundaries on saving.

How about in the future after 5.0? 

This bug has been giving me a lot of pain in the ass ;-;
Comment 7 Halla Rempt 2022-09-19 13:50:36 UTC

*** This bug has been marked as a duplicate of bug 457562 ***
Comment 8 acc4commissions 2022-09-19 17:38:46 UTC
It's not just a cosmetical issue. It affects the actual performance. Just so you know.