# \[solved\] Asking for a big file with lots of layers for testing (rewrote Unhide Layers plugin)

**URL:** https://forums.synfig.org/t/solved-asking-for-a-big-file-with-lots-of-layers-for-testing-rewrote-unhide-layers-plugin/13751
**Category:** Plugins
**Created:** [January 6, 2023, 10:16am UTC](https://forums.synfig.org/t/solved-asking-for-a-big-file-with-lots-of-layers-for-testing-rewrote-unhide-layers-plugin/13751 "2023-01-06T10:16:45Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![elegant.codes](https://forums.synfig.org/letter_avatar_proxy/v4/letter/e/e99b99/32.png) [@elegant.codes](https://forums.synfig.org/u/elegant.codes)
#### Post date: [January 6, 2023, 10:16am UTC](https://forums.synfig.org/t/solved-asking-for-a-big-file-with-lots-of-layers-for-testing-rewrote-unhide-layers-plugin/13751/1 "2023-01-06T10:16:46Z")

</div>

Hi,  
Does anybody have a really big file with a lot of layers to share?  
I rewrote Konstantin’s Unhide Layers plugin, using a more XML-oriented way: [https://github.com/3l3gant-cod3s/synfig/blob/3l3gant-cod3s-patch-plugin-unhide-with-xpath/synfig-studio/plugins/view-unhide-all-layers/view-unhide-all-layers.py](https://github.com/3l3gant-cod3s/synfig/blob/3l3gant-cod3s-patch-plugin-unhide-with-xpath/synfig-studio/plugins/view-unhide-all-layers/view-unhide-all-layers.py)  
Ice0 and mohamedAdhamc suggested to do some performance tests before accepting my [#2968 PR](https://github.com/synfig/synfig/pull/2968) but I’m new to Synfig. So I have no really big file at hand and didn’t find any online.  
Thanks in advance!  
E.C

---

<div class="post-metadata">

### Author: ![elegant.codes](https://forums.synfig.org/letter_avatar_proxy/v4/letter/e/e99b99/32.png) [@elegant.codes](https://forums.synfig.org/u/elegant.codes)
#### Post date: [January 6, 2023, 11:04am UTC](https://forums.synfig.org/t/solved-asking-for-a-big-file-with-lots-of-layers-for-testing-rewrote-unhide-layers-plugin/13751/2 "2023-01-06T11:04:44Z")

</div>

I have discovered the Synfig-examples .deb :-/  
its pirates.sif has 1726 layers, quite enough I think.

---

<div class="post-metadata">

### Author: ![BobSynfig](https://forums.synfig.org/user_avatar/forums.synfig.org/bobsynfig/32/175_2.png) [@BobSynfig](https://forums.synfig.org/u/BobSynfig)
#### Post date: [January 6, 2023, 11:28am UTC](https://forums.synfig.org/t/solved-asking-for-a-big-file-with-lots-of-layers-for-testing-rewrote-unhide-layers-plugin/13751/3 "2023-01-06T11:28:16Z")

</div>

Don’t worry, as it is a plugin, there is no problem of performances, even with big files.  
The only thing is that it needs to load a full tree in memory while the original was “quick-and-dirty”, for sure faster and less heavy.  
But it is attacking directly the file as text, which is not a good practice.  
Yours is done “the good way”  
I would like so bad a real scripting API 😛

If you need very big number of layers… Ask @Svarov 🤪

---

<div class="post-metadata">

### Author: ![elegant.codes](https://forums.synfig.org/letter_avatar_proxy/v4/letter/e/e99b99/32.png) [@elegant.codes](https://forums.synfig.org/u/elegant.codes)
#### Post date: [January 7, 2023, 10:15am UTC](https://forums.synfig.org/t/solved-asking-for-a-big-file-with-lots-of-layers-for-testing-rewrote-unhide-layers-plugin/13751/4 "2023-01-07T10:15:54Z")

</div>

Thank you @BobSynfig!  
I have “instrumented” both codes (K’s and mine) and mine is ~10× slower (3s versus .26s) for the core operation (changing the states of layers).  
But the whole operation takes ~12-15s. 🙂  
(it’s probably redrawing that bunch of layers that takes such a long time)  
E.C

---

<div class="post-metadata">

### Author: ![BobSynfig](https://forums.synfig.org/user_avatar/forums.synfig.org/bobsynfig/32/175_2.png) [@BobSynfig](https://forums.synfig.org/u/BobSynfig)
#### Post date: [January 7, 2023, 7:45pm UTC](https://forums.synfig.org/t/solved-asking-for-a-big-file-with-lots-of-layers-for-testing-rewrote-unhide-layers-plugin/13751/5 "2023-01-07T19:45:39Z")

</div>

This plugin is 11 years old and was mostly used as a proof of concept.  
It should be implemented “in hard” in C++ code (by walking the internal structure, as XML walking).  
The current plugin system is just doing:

- save the fille
- start python script on a temp copy
- reopen the temp file (and reload it)

It requires to know well the internal structure of .sif file.  
That’s the reason why I was writing “no problem of performances” because it is not efficient by nature 😛
