Workload of ViewBox vs. ClipPath

[SamReciter]

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 ?
and
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]

Hi,

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.

Lukas

--
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 lib-gwt-svg...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[SamReciter]

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.

Sam