Workload of ViewBox vs. ClipPath

Skip to first unread message


Apr 18, 2013, 1:38:33 PM4/18/13
Hello Lukas, all,

how's that implemented with ViewBox and ClipPath.

I use ViewBox for scrolling in between a large dynamic svg grafic.
Unless the scrolling of/in the svg grafic is very smooth - the scrolling in my parent application -
i have the svg in one of plenty application windows which are horizontally scrollable - is extremely laggy.

Am i right that in my case (using ViewBox) the whole grafic is rendered - also not the whole grafic is shown ?
this would be better if i use a rectangular ClipPath instead of the ViewBox (or additionally) ?
In means - only the part in between the ClipPath would be rendered ?

Thanks in regard - yours sincerely,
Sam Reciter

Lukas Laag

Apr 25, 2013, 3:04:20 AM4/25/13
Have you tried using CSS overflow (ie: not try to clip anything at the SVG level and let the browser do the work). This is the approach I have used in my drawing app and it has worked fine for me.


You received this message because you are subscribed to the Google Groups "lib-gwt-svg" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
For more options, visit


Apr 25, 2013, 3:34:17 AM4/25/13
Hey, thanks for the reply.

Yes i have - or rather i do anyhow. 
I think it's the image itself - or more precisely - presumably a huge compressed text line in one of the images.
At least - i could not recognize any difference in the lagging with ViewBox or ClipPath - overflow:hidden is anyway given by the parent element.

One other thing - i stumbled over on this work. I have a funky effect with ClipPath in Chrome.
If i define a ClipPath and change the position and size afterwards - it does nothing.
Then - when i use the Chrome DeveloperTool - choose the SVG image - go edit as HTML - change nothing - go back to the open application  - it works.
Only in Chrome - Firefox here no problem.

It's not directly of interest any more - so i probably will not have any time to dig deeper - but funky effect.
Only can assume that it forces a kind of redraw that forceRedraw() can't do =).

Well then - greets and thanks for your great lib.
Reply all
Reply to author
0 new messages