Closed GoogleCodeExporter closed 9 years ago
This actually only happens in FF. I've seen it before but am not sure how to
find a
workaround. It seems like a FF native bug.
Original comment by bradneub...@gmail.com
on 17 Jul 2009 at 10:22
I figured out the root of this. Both Firefox and Opera correctly scale the size
of an
SVG object to the setting in View > Zoom. For example, if I zoom into or out of
the
page the SVG will zoom and get larger or smaller. Safari incorrectly has a bug
around
this.
Currently, the Flash part of SVG Web is not scaling (because the scaleMode is
set to
noScale). I believe it should actually be set to noBorder scaleMode, so that
things
will scale, but can potentially get cropped. I know though that Rick set the
scaleMode to noScale on purpose I believe. Rick, if I change the scaleMode in
SVGViewerWeb to noBorder will this break things I'm not aware of? I will
experiment
for now and see if it fixes the visual glitch documented in this bug.
Original comment by bradneub...@gmail.com
on 18 Jul 2009 at 12:47
This might be related to Issue 166, or they have similar roots.
Original comment by bradneub...@gmail.com
on 20 Jul 2009 at 8:44
Rick suggests that this work should probably move up to SVGViewer.as instead of
SVGViewerWeb.as, which is probably correct. I need to move on to hitting some
other
issues, so I'm going to table this bug for now. I've made quite alot of
progress in
terms of fixing scaling for SVG files that specify width and/or height. I still
need
to find a solution when no width and height are specified, as well as move much
of
this code up to the SVGViewer class out of SVGViewerWeb. Other tasks for this
bug
that remain:
* When the zoom size is made very small, the photos.svg file correctly shows
small
but the mouse events seem a bit wonky. Investigate what is up.
* Do another full round of QA on all target browsers to make sure the changes
from
this bug don't break things, and that changing the text zoom size now works
correctly.
* Investigate what correct behavior should be if a viewBox is specified, as
well as
how this might interact with preserveAspectRatio if specified.
I'm attaching the changes I've made for this bug as a patch file instead of
checking
it into Subversion for now.
To replicate this bug for testing, in Firefox go to demo.html?name=scim.
Dynamically
change the zoom size by pressing cmd/cntrl-+ or -; make sure that things scale
correctly. Make the zoom size the smallest, then reload the page and make sure
the
image gets drawn correctly. The scimitar file has explicit widths and heights;
to
check the case where none are present, do the above test for the Droid Sans
file as
well, which has no width or height specified (demo.html?name=droid%20font1)
Original comment by bradneub...@gmail.com
on 22 Jul 2009 at 6:49
Attachments:
Original comment by bradneub...@gmail.com
on 22 Jul 2009 at 6:50
One thing I forgot; in the demo.html file, there was also an issue with this
patch
related to setting the viewBox after rendering the SVG OBJECT. Make sure that
works
correctly as well.
Original comment by bradneub...@gmail.com
on 22 Jul 2009 at 7:01
[deleted comment]
Hi Brad,
Excuse me if this isn't exactly related to the issue, but I'm trying to figure
out
one thing: when you change zoom the and position of the example's viewbox
(http://codinginparadise.org/projects/svgweb/samples/demo.html) do svgweb render
*every* shape inside the document or it renders only the shapes that will be
visible
inside the new viewbox (considering zoom, viwebox position, etc)?
I've attached one example about what I'm trying to do, I want to make an
autocad like
zoom tool (for those familiar with autocad, the "zoom window" function).
Original comment by pedro.sa...@gmail.com
on 3 Aug 2009 at 4:56
Attachments:
I've done an example of what I need, but it's not using SVGWeb, and is done
actionscript1 (yeah, I still use as1, lol).
If everything is redrawn when you zoom, it can be a fast way to avoid rendering
unnecessary shapes, by simply analysing every shape's bounding boxes and then
ignoring those wich should not be rendered.
Original comment by pedro.sa...@gmail.com
on 3 Aug 2009 at 3:57
Attachments:
Hi Pedro, that's a good question. I'm not sure; Rick will have to answer that.
That's
a good idea though on not redrawing anything outside the viewbox, which could
lead to
quite a performance improvement for certain images, such as zooming into an
Autocad
like mechanical illustration.
Original comment by bradneub...@gmail.com
on 3 Aug 2009 at 5:12
Fixed in r783.
To answer the question in comment #9: We currently do not filter out rendering
for
elements outside the viewBox. That would be a separate issue.
Original comment by grick23@gmail.com
on 6 Sep 2009 at 8:36
Original issue reported on code.google.com by
bradneub...@gmail.com
on 17 Jul 2009 at 10:00