blackfyre / svgweb

Automatically exported from code.google.com/p/svgweb
Other
0 stars 0 forks source link

Sizing of embedded SVG differs between Flash and Native when browser text zoom setting is different #163

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
If you go to
samples/javascript-samples/helloworld.html?svg.render.forceflash=true to
force the Flash renderer, and then view this using the native renderer with
samples/javascript-samples/helloworld.html?svg.render.forceflash=true the
sizing and placement is slightly different on both FF and Safari.

Original issue reported on code.google.com by bradneub...@gmail.com on 17 Jul 2009 at 10:00

GoogleCodeExporter commented 8 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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago

Original comment by bradneub...@gmail.com on 22 Jul 2009 at 6:50

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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:

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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