Update DragSurfaceSvg to not repaint on drag

[tmickel]

@picklesrus
Our blocks currently repaint on drag, but this demo doesn't seem to:
https://jsfiddle.net/zaaex6bx/

What's going on? Can we avoid repaint?

[tmickel]

Ah! One potential difference. In my drag surface, the block group inside the SVG is being translated, instead of the actual SVG itself. That would make sense why it would repaint the SVG. This is a potential big performance hit for no reason.

[tmickel]

I've got a basic demo where it's not repainting during drag using the idea from above. Exciting

[picklesrus]

Super neat! So did you turn your drag group into its own svg? I would love to see the demo or the code. I've been playing with nesting svgs too, though with a goal of making panning and zooming work as well as the overflow div trick did. So far it isn't winning as much as I hoped, but I might be able to apply your approach to that too.

[tmickel]

The drag group is already its own SVG. Just need to apply the translation on the SVG itself rather than inside it :)

Hopefully should have a really working demo by the end of the day - I had a basic one but all the coordinates are broken...

Curious about what you've been doing also. By nesting SVGs, do you mean using a foreign object?

[picklesrus]

Mine isn't proving to be that interesting yet. I'm playing with the viewbox attribute to see if it helps with panning and zooming.
My demo currently has a structure that looks something like this:


shapes/blocks in here

The idea is that when interacting with the scroll bars, I just change the viewbox and the inner svg shifts or scales appropriately. I haven't gotten the repaints to be as infrequent as I'd like though. Changing the viewbox seems to repaint the whole interior of that blocks svg. I'm not quite ready to give up though. I'll let you know if anything useful comes of it.

[tmickel]

Merged into develop, @picklesrus

That's an interesting idea with the viewbox. I'd guess that it's not as optimized as browser scrolls, so I don't know. It would be cool if you get results!

[tmickel]

@picklesrus

Have you tried this:
-Move everything out of the Blockly svg except for the block canvas and other things that translate with it.
-instead of applying the translations and scales to the block canvas group, apply the transform on the outer svg tag

My understanding based on this issue and results would be that the browser likely won't repaint the svg if you do a translation on the outer element. Then we should get perf as good as the div trick maaaaybe? Although maybe the browser is doing extra tricks with scrolling...

Just a thought and might save a lot of work.

[picklesrus]

Doh! Yes, I had been trying something like that after mostly giving up on viewBox, but now looking back at my example, I think maybe I've been confusing the svg transform attribute and the css one all day today. Couple that with the fact that you can't apply a transform to an tag (in some browsers anyway) and I took a nice journey down the rabbit hole. But, I just read your drag surface CL and realized my mistake. Thanks! I should have a real answer to whether this works tomorrow.

[tmickel]

Ah! Yeah this has been very tricky, I've done similar things wrong many, many times. I hope it works!!

[picklesrus]

I may have some good news! I may have figured out a way to do this without changing too much.
I can have multiple s sitting directly on top of each other if I set them to position:absolute. Then, I can apply transforms to each of them independently and the block canvas doesn't repaint. The scrollbars can move up while the blocks move down. Amazing stuff here ;) I can't do this if the s are nested (well, except for in browsers that have started supporting svg2.0 features like firefox).

If I do it this way, I don't have to move things in and out of the svgs and I think the code might be relatively simple. I only have this working in a toy example so I'm going to try and apply it to mainline blocky first and see what problems I run into. I believe it will be easier to apply to scratch-blockly if mainline doesn't work.

[picklesrus]

And I threw the toy example up on a webserver. It isn't that exciting since I cheated by adding buttons to move things around rather than adding scroll bars, but if you're curious about the dom structure, this is it: http://blocktests-1261.appspot.com/bt/tests/layeredsvgtest.html

[tmickel]

@picklesrus Awesome yes!!! This looks great and the demo is exciting.

Basically are you thinking, all absolutely positioned:
-One SVG that contains blocklyBlockCanvas and blocklyBubbleCanvas - this is the one you transform on pan/scale
-One SVG that contains the scrollbars, zoom buttons, trash can
-One SVG that contains the flyout somehow?
-One SVG for the drag layer (in scratch-blockly - maybe in mainline eventually?)

In doing the drag layer, I put the two absolute-positioned SVGs inside a container div that is position:relative - just a trick that might help you with the layout stuff.

Based on how good of performance with even very large stacks with the drag layer, I'd buy that this will give us really good workspace panning on mobile.

I'm a little worried that the above might still not be easy. Even splitting out the dragging block to a separate SVG was tricky because there were some assumptions being made in the code about relative coordinates. Hopefully there will be less of an issue with this though because the components seem mostly independent. The main place where it seems to me there may seem to be risk of breaking is flyout vs. workspace coordinates, but Rachel also just worked on that so if you run into problems she might be able to help.

One more related note: as a stretch goal -- I really don't think this is necessary -- it may be cool to apply the same trick to the flyout workspace as well. The scrolling of the flyout is definitely not 60fps (less important since you use it less), but it seems like it could be with this trick. Since the flyout itself is just a workspace, you may get it for free if you structure so all workspaces are added flatly to the container div, not nesting the flyout inside the parent SVG, or something like that.

I'm very excited to see this in action and I'm glad it's going to be simpler than the div solution!