Yes, I've thought about that too. But there will be a problem if the terrain sprite is not simply a rectangle but initially has transparent parts (like in my "cannons" project). So we'll need a "background" sprite too that wil be partly visible from the beginning. Thus we'll have to use complex condition to detect terrain impacts: cannonball NOT ("touching lookinglass" OR "touching background"), but this will cause errors in areas initially occupied by terrain sprite and background sprites: impacts in these areas won't be detected because "touching background" will be true there. Hope my explanation is clear.
Yes 
Unfortunately, its my lack of understanding of your native language makes its very tricky for me to play with your projects and modify them as I don't understand the variable and sprite names
Ok, I should have thought about that 
Translated both projects to english.
Thank you for your efforts!
What about this?
Click anywhere on the ground to punch a hole.
It's not instant, but maybe it's fast enough for your project...
that's pretty fast and beautiful, Bernat!
Thank you Bernat. That's an interesting idea to use "paste on" as an intermediate step!
But it's still very slow... Look, I've remixed your project a bit to match mine: https://snap.berkeley.edu/snap/snap.html#present:Username=pavelbel&ProjectName=Bernat%20holes
I've changed scene size, ground (brick wall, 800x600) and hole sprites (as in my project) and added a timer to measure hole printing time. On my system it takes about 1.5 secs to make a sigle hole.
And here's my variant with the same sprites and sizes:
https://snap.berkeley.edu/snap/snap.html#present:Username=pavelbel&ProjectName=holes%20demo
(do not forget to press green flag before making holes)
It gives ~100-400 ms per hole on my system.
And it's no suprise because your algo searches through ALL the pixels of the ground sprite ("blitz map" block), while mine just loops over a relatively small array of opaque points of the "hole" sprite. And still it is slow enough (and strangely becomes slower and slower the more holes I make).
I'm sure it is quite possible to make these operations waaaay faster using "print on" logic that takes transparent pixels into account.
Wow! Your method works really fast and, in my computer, it doesn't get slower at all with more holes.
Yes, my method is way slower than that. We'll have to keep thinking
A bit of speed gain
Yes, a small bit
The real bottle neck of the algorithm is this:
Everyting else works fast enough (if the hole pixels array is not veeeeery long).
So, here's another approach using a buffer:
The trick is that you first paste the hole shape with the sky background into the ground sprite, then compute the hole in a separate sprite that has the same costume as the ground, then tell the ground to wear that costume once the hole has been calculated.
To the user it feels like the hole is punched immediately, but the actual costume is being rendered in the background.
If cannon balls take longer to land than what it takes to compute the previous hole (or if you add some artificial wait, like a "loading ball" animation or something), then this method is simple enough and takes no code at all.
and here's yet another approach using hyperblocks:
But - I really think @cymplecy's solution is by far the most elegant one
Maybe a hybrid approach
Use my idea - which is really @Jens and Jadga's from the course to visually make the hole quickly and then afterwards, actually change the costume pixels?
I completely missed Bernat's post 
Nice to think we both came up with the same solution 
It seems that the "current costume pixels" list is mutated in a way that makes "switch to costume" extremely ineffective.
Right after start...
After a single "pressed" event
It gets worse with every click
hmm... I've tested this extensively with various costumes, but performance seems to be consistent for me:
(those are milliseconds, btw)
There is OP project with measurements: https://snap.berkeley.edu/snap/snap.html#present:Username=dardoro&ProjectName=holes%20demo&editMode
"current costume pixel" is a ~300k list. Every iteration modifies ~3k elements.
Yes, I have exactly the same impression: switching to costume becomes slower and slower the more "holes" I make. And even if I do not make any more holes - switching to the same costume remains slow.
I've used @dardoro's time measuring routine to estimate switching to costume time (just switching, without modification):
- Switching to costume with no holes: 4 ... 12 ms
- Switching to costume with 1 hole: 40 ... 60 ms
- Switching to costume with 20 holes: ~140 ms
- Switching to costume with 50 holes: 200 - 350 ms
- Switching to costume with 100 holes: 200 - 400 ms
I didn't understand your idea at first (I never used JS before), but then I've taken a look at Snap! sources and finally understood what are these 'source-over', 'destination-in' etc. mean. Yes, these modes of "globalCompositeOperation" would be super useful! They allow a totally new level of graphic effects. And it is very fast and easy to implement.