Hi Alexander,
May I suggest that there is the possibility that you misinterpreted Peter Sorotokin's paper at the "SVG scrollbar" paragraph? It reads: "Simpler example can be found here - compare perfomance of simply dragging letters around and doing the same thing with the Shift key pressed." When you compare performance you can see that while pressing the Shift key the scroll does seem smoother at a first glance but then you discover the horizontal scroll is anarchic and vertically it soon loses track of the mouse, the offset becoming quickly embarassing, all this making the use of this method quite problematic and, in fact, unusable ((re)tested on vaio laptop win xp 2.2Ghz). From what Peter states a couple of lines above, one can earnestly assume that with the Shift key pressed the script is using the transform attribute while, without the Shift key pressed, it's using the currentTranslate attribute. If you take a close look you can see that it's actually the opposite. One kind of drags, true, but currentTranslate is unusable in this situation and even more so in a more complex one, as you experienced within your own work. Hopefully Peter Sorotokin would want to clarify the misleading phrase in the paper. Should I also point out that Andreas Neumann also opted for the viewbox solution in his Vienna work. If you decide to stick with the currentTranslate solution then you should follow Andr�'s suggestions and good luck. Andr� also pointed out that all this is not necessarily true in the absolute, but rather a peculiar behavior of ASV, and I have a tendency to trust what he says. > But this is a viewBox-solution and viewBox-solutions are much slower > than currentScale- and currentTranslate-solutions... If we admit both visual experience and what Andr� says then this is not true or proven, and your statement can mislead other users, taking away from them the opportunity to benefit from the potential of the scripts in the library, which were written with the intention of providing optimized and easy to implement routines. One capital goal was also highest possible execution speed, especially to partially palliate display and rendering limitations. I think the goal was achieved, as a simple visual test can prove. One falloff is that the code may not be academic, but I definitely give priority to pragmatic coding, as long as it proves faster. Anyway, it seemed to me that you were seeking a better solution for zoom and pan to integrate into your work, the solution I pointed you to is, to put it very simply, efficient, without wanting to make any comparisons. But then you say viewBox-solutions are much slower!? I don't understand. I sincerely hope you'll understand that, being an artist, my talk is not and will never be politically correct, so I need to make a preventive apology saying that it's not intended to hurt your or anyone else's feelings. Ciao, <g-7> Domenico --- In [email protected], Alexander Vipach <[EMAIL PROTECTED]> wrote: > Hello Domenico, > > thank you very much for your message. > > >try here: > >http://www.dotuscomus.com/svg/lib/library.html > > > >you shouldn't get that annoying effect anymore while scrolling > >diagonally. > > But this is a viewBox-solution and viewBox-solutions are much slower > than currentScale- and currentTranslate-solutions... > > Ciao > > Alex ----- To unsubscribe send a message to: [EMAIL PROTECTED] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ---- Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
