Loading ...
Sorry, an error occurred while loading the content.

Swapping attribute values on large numbers of elements

Expand Messages
  • simonshutter
    Hi, I have a scenario where I need to plot hundreds of rectangles and each rectangle has two possible y values but all other attributes are static. To save
    Message 1 of 23 , Jan 23, 2007
    • 0 Attachment
      Hi,

      I have a scenario where I need to plot hundreds of rectangles and
      each rectangle has two possible y values but all other attributes are
      static. To save space I was hoping to add two attributes that could
      be swapped in response to events. Does this make sense and what do
      you suggest as a method for swapping the two y attribute values?
      Would I have to loop over each element sequentially or is there a
      faster way?

      Thanks, Simon

      The markup would be something like this :

      <?xml version="1.0" encoding="utf-8"?>
      <svg id="rects"
      width="100%" height="100%"
      xmlns="http://www.w3.org/2000/svg"
      xmlns:swap="http://www.xxx.com/ns">
      <rect attrib:title="R1" attrib:y1="20" attrib:y2="35" x="14" y="50"
      width="3" height="31"/>
      <rect attrib:title="R2" attrib:y1="30" attrib:y2="35" x="12" y="20"
      width="3" height="11"/>
      <rect attrib:title="r1" attrib:y1="20" attrib:y2="30" x="140"
      y="20" width="3" height="21"/>
      <rect attrib:title="R3" attrib:y1="40" attrib:y2="30" x="21" y="10"
      width="3" height="1"/>
      <rect attrib:title="Rn" attrib:y1="20" attrib:y2="30" x="140"
      y="20" width="3" height="21"/>.
      </svg>


      The script could be something like :

      var r=document.getElementById('rects')
      var coll=r.getElementsByTagNameNS
      ('http://www.w3.org/2000/svg', 'rect')
      var i=0
      var elm;
      while(elm=coll.item(i++)){
      elm.setAttributeNS(null,'y',elm.getAttributeNS
      ('http://www.xxx.com/ns,'y'));
      }
    • simonshutter
      Seems to work but I made a bunch of syntax errors in my original post
      Message 2 of 23 , Jan 23, 2007
      • 0 Attachment
        Seems to work but I made a bunch of syntax errors in my original post

        <?xml version="1.0" encoding="utf-8"?>
        <svg id="rects"
        width="100%" height="100%"
        xmlns="http://www.w3.org/2000/svg"
        xmlns:swap="http://www.xxx.com/ns">
        <rect swap:title="R1" swap:y1="20" swap:y2="35" x="14" y="50"
        width="3" height="31"/>
        <rect swap:title="R2" swap:y1="30" swap:y2="35" x="12" y="20"
        width="3" height="11"/>
        <rect swap:title="r1" swap:y1="20" swap:y2="30" x="140" y="20"
        width="3" height="21"/>
        <rect swap:title="R3" swap:y1="40" swap:y2="30" x="21" y="10"
        width="3" height="1"/>
        <rect swap:title="Rn" swap:y1="20" swap:y2="30" x="140" y="20"
        width="3" height="21"/>
        </svg>

        var r=document.getElementById('rects')
        var coll=r.getElementsByTagNameNS
        ('http://www.w3.org/2000/svg', 'rect')
        var i=0;
        var elm;
        while(elm=coll.item(i++)){
        elm.setAttributeNS(null,'y',elm.getAttributeNS
        ('http://www.xxx.com/ns','y1'));
        }



        --- In svg-developers@yahoogroups.com, "simonshutter" <simon@...>
        wrote:
        >
        > Hi,
        >
        > I have a scenario where I need to plot hundreds of rectangles and
        > each rectangle has two possible y values but all other attributes
        are
        > static. To save space I was hoping to add two attributes that
        could
        > be swapped in response to events. Does this make sense and what do
        > you suggest as a method for swapping the two y attribute values?
        > Would I have to loop over each element sequentially or is there a
        > faster way?
        >
        > Thanks, Simon
        >
        > The markup would be something like this :
        >
        > <?xml version="1.0" encoding="utf-8"?>
        > <svg id="rects"
        > width="100%" height="100%"
        > xmlns="http://www.w3.org/2000/svg"
        > xmlns:swap="http://www.xxx.com/ns">
        > <rect attrib:title="R1" attrib:y1="20" attrib:y2="35" x="14"
        y="50"
        > width="3" height="31"/>
        > <rect attrib:title="R2" attrib:y1="30" attrib:y2="35" x="12"
        y="20"
        > width="3" height="11"/>
        > <rect attrib:title="r1" attrib:y1="20" attrib:y2="30" x="140"
        > y="20" width="3" height="21"/>
        > <rect attrib:title="R3" attrib:y1="40" attrib:y2="30" x="21"
        y="10"
        > width="3" height="1"/>
        > <rect attrib:title="Rn" attrib:y1="20" attrib:y2="30" x="140"
        > y="20" width="3" height="21"/>.
        > </svg>
        >
        >
        > The script could be something like :
        >
        > var r=document.getElementById('rects')
        > var coll=r.getElementsByTagNameNS
        > ('http://www.w3.org/2000/svg', 'rect')
        > var i=0
        > var elm;
        > while(elm=coll.item(i++)){
        > elm.setAttributeNS(null,'y',elm.getAttributeNS
        > ('http://www.xxx.com/ns,'y'));
        > }
        >
      • Erik Dahlström
        ... One alternative is to not specify a y -attribute at all (defaults to 0), and instead group the elements in a element. Then you give the element a
        Message 3 of 23 , Jan 23, 2007
        • 0 Attachment
          On Wed, 24 Jan 2007 06:58:29 +0100, simonshutter <simon@...> wrote:

          > Hi,
          >
          > I have a scenario where I need to plot hundreds of rectangles and
          > each rectangle has two possible y values but all other attributes are
          > static. To save space I was hoping to add two attributes that could
          > be swapped in response to events. Does this make sense and what do
          > you suggest as a method for swapping the two y attribute values?
          > Would I have to loop over each element sequentially or is there a
          > faster way?

          One alternative is to not specify a 'y'-attribute at all (defaults to 0),
          and instead group the elements in a <g> element.
          Then you give the <g> element a 'transform'-attribute to translate all the
          child elements to whatever y-value you want.

          The benefit is that you then change one attribute instead of hundreds, but
          depending on how your svg looks it may or may not be possible to group the
          elements in this way.

          Cheers
          /Erik

          --
          Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
        • simonshutter
          Thanks Eric but each of the elements needs its own transform so I either have to add a transform to each or change y. ... are ... could ... do
          Message 4 of 23 , Jan 24, 2007
          • 0 Attachment
            Thanks Eric but each of the <rect> elements needs its own transform
            so I either have to add a transform to each <rect> or change y.

            --- In svg-developers@yahoogroups.com, Erik Dahlström <ed@...> wrote:
            >
            > On Wed, 24 Jan 2007 06:58:29 +0100, simonshutter <simon@...> wrote:
            >
            > > Hi,
            > >
            > > I have a scenario where I need to plot hundreds of rectangles and
            > > each rectangle has two possible y values but all other attributes
            are
            > > static. To save space I was hoping to add two attributes that
            could
            > > be swapped in response to events. Does this make sense and what
            do
            > > you suggest as a method for swapping the two y attribute values?
            > > Would I have to loop over each element sequentially or is there a
            > > faster way?
            >
            > One alternative is to not specify a 'y'-attribute at all (defaults
            to 0),
            > and instead group the elements in a <g> element.
            > Then you give the <g> element a 'transform'-attribute to translate
            all the
            > child elements to whatever y-value you want.
            >
            > The benefit is that you then change one attribute instead of
            hundreds, but
            > depending on how your svg looks it may or may not be possible to
            group the
            > elements in this way.
            >
            > Cheers
            > /Erik
            >
            > --
            > Using Opera's revolutionary e-mail client:
            http://www.opera.com/mail/
            >
          • Jeff Schiller
            in response to events - what does this mean? What event? Does the event give you any indication of which element needs to be swapped? Can each rectangle s
            Message 5 of 23 , Jan 24, 2007
            • 0 Attachment
              "in response to events" -> what does this mean? What event? Does the
              event give you any indication of which element needs to be swapped?

              Can each rectangle's two y values be different from any other rectangle?

              Jeff

              --- In svg-developers@yahoogroups.com, "simonshutter" <simon@...> wrote:
              >
              > Hi,
              >
              > I have a scenario where I need to plot hundreds of rectangles and
              > each rectangle has two possible y values but all other attributes are
              > static. To save space I was hoping to add two attributes that could
              > be swapped in response to events. Does this make sense and what do
              > you suggest as a method for swapping the two y attribute values?
              > Would I have to loop over each element sequentially or is there a
              > faster way?
              >
              > Thanks, Simon
              >
              > The markup would be something like this :
              >
              > <?xml version="1.0" encoding="utf-8"?>
              > <svg id="rects"
              > width="100%" height="100%"
              > xmlns="http://www.w3.org/2000/svg"
              > xmlns:swap="http://www.xxx.com/ns">
              > <rect attrib:title="R1" attrib:y1="20" attrib:y2="35" x="14" y="50"
              > width="3" height="31"/>
              > <rect attrib:title="R2" attrib:y1="30" attrib:y2="35" x="12" y="20"
              > width="3" height="11"/>
              > <rect attrib:title="r1" attrib:y1="20" attrib:y2="30" x="140"
              > y="20" width="3" height="21"/>
              > <rect attrib:title="R3" attrib:y1="40" attrib:y2="30" x="21" y="10"
              > width="3" height="1"/>
              > <rect attrib:title="Rn" attrib:y1="20" attrib:y2="30" x="140"
              > y="20" width="3" height="21"/>.
              > </svg>
              >
              >
              > The script could be something like :
              >
              > var r=document.getElementById('rects')
              > var coll=r.getElementsByTagNameNS
              > ('http://www.w3.org/2000/svg', 'rect')
              > var i=0
              > var elm;
              > while(elm=coll.item(i++)){
              > elm.setAttributeNS(null,'y',elm.getAttributeNS
              > ('http://www.xxx.com/ns,'y'));
              > }
              >
            • simonshutter
              Hi Jeff, Say I had a gui element that toggled the state of my svg by capturing the click event and swapped y values. An example data set could comprise
              Message 6 of 23 , Jan 24, 2007
              • 0 Attachment
                Hi Jeff,

                Say I had a gui element that toggled the state of my svg by capturing
                the click event and swapped y values. An example data set could
                comprise absolute and cumulative values:

                X Yabsolute Ycumulative
                1 3 3
                2 5 8
                3 2 10
                4 4 14

                Hope this help explain a little more clearly what I'm trying to do.

                Thanks, Simon


                --- In svg-developers@yahoogroups.com, "Jeff Schiller"
                <jeff_schiller@...> wrote:
                >
                > "in response to events" -> what does this mean? What event? Does
                the
                > event give you any indication of which element needs to be
                swapped?
                >
                > Can each rectangle's two y values be different from any other
                rectangle?
                >
                > Jeff
                >
                > --- In svg-developers@yahoogroups.com, "simonshutter" <simon@>
                wrote:
                > >
                > > Hi,
                > >
                > > I have a scenario where I need to plot hundreds of rectangles and
                > > each rectangle has two possible y values but all other attributes
                are
                > > static. To save space I was hoping to add two attributes that
                could
                > > be swapped in response to events. Does this make sense and what
                do
                > > you suggest as a method for swapping the two y attribute values?
                > > Would I have to loop over each element sequentially or is there a
                > > faster way?
                > >
                > > Thanks, Simon
                > >
                > > The markup would be something like this :
                > >
                > > <?xml version="1.0" encoding="utf-8"?>
                > > <svg id="rects"
                > > width="100%" height="100%"
                > > xmlns="http://www.w3.org/2000/svg"
                > > xmlns:swap="http://www.xxx.com/ns">
                > > <rect attrib:title="R1" attrib:y1="20" attrib:y2="35" x="14"
                y="50"
                > > width="3" height="31"/>
                > > <rect attrib:title="R2" attrib:y1="30" attrib:y2="35" x="12"
                y="20"
                > > width="3" height="11"/>
                > > <rect attrib:title="r1" attrib:y1="20" attrib:y2="30" x="140"
                > > y="20" width="3" height="21"/>
                > > <rect attrib:title="R3" attrib:y1="40" attrib:y2="30" x="21"
                y="10"
                > > width="3" height="1"/>
                > > <rect attrib:title="Rn" attrib:y1="20" attrib:y2="30" x="140"
                > > y="20" width="3" height="21"/>.
                > > </svg>
                > >
                > >
                > > The script could be something like :
                > >
                > > var r=document.getElementById('rects')
                > > var coll=r.getElementsByTagNameNS
                > > ('http://www.w3.org/2000/svg', 'rect')
                > > var i=0
                > > var elm;
                > > while(elm=coll.item(i++)){
                > > elm.setAttributeNS(null,'y',elm.getAttributeNS
                > > ('http://www.xxx.com/ns,'y'));
                > > }
                > >
                >
              • ddailey
                simonshutter wrote: Say I had a gui element that toggled the state of my svg by capturing the click event and swapped y values. An example data set could
                Message 7 of 23 , Jan 25, 2007
                • 0 Attachment
                  simonshutter wrote:

                  Say I had a gui element that toggled the state of my svg by capturing
                  the click event and swapped y values. An example data set could
                  comprise absolute and cumulative values:

                  X Yabsolute Ycumulative
                  1 3 3
                  2 5 8
                  3 2 10
                  4 4 14

                  Hope this help explain a little more clearly what I'm trying to do.

                  Thanks, Simon
                  ------------------

                  If I understand what you're asking, then you'll have to loop through the rows of your dataset to accomplish the task. I don't think hundreds of points would be a problem, though thousands might be, and tens of thousands probably would be.

                  Take a look at http://srufaculty.sru.edu/david.dailey/svg/swapY.svg as an example. It's a bit terse so holler if something doesn't make sense.

                  Another approach would be to render both functions f(x)=Yabsolute and f(x)=Ycumulative when you first do any plotting, but to put the chart of the second function in an invisible group. Then you could just merely toggle the visibility of that group. This would save during run-time but cost at startup time. If you had more than two functions, like say dozens, then this technique would become unwieldy.

                  Hope this helps,
                  David

                  [Non-text portions of this message have been removed]
                • simonshutter
                  David, That s a wonderful example for me and for the knowledge base in this group. I learnt several things about the DOM as well. The loop I used in my second
                  Message 8 of 23 , Jan 25, 2007
                  • 0 Attachment
                    David,

                    That's a wonderful example for me and for the knowledge base in this
                    group. I learnt several things about the DOM as well.

                    The loop I used in my second post to this thread
                    (http://tech.groups.yahoo.com/group/svg-developers/message/57931) ran
                    surprisingly fast for 3000 nodes.

                    Thanks again,

                    Simon

                    --- In svg-developers@yahoogroups.com, "ddailey" <ddailey@...> wrote:
                    >
                    > simonshutter wrote:
                    >
                    > Say I had a gui element that toggled the state of my svg by
                    capturing
                    > the click event and swapped y values. An example data set could
                    > comprise absolute and cumulative values:
                    >
                    > X Yabsolute Ycumulative
                    > 1 3 3
                    > 2 5 8
                    > 3 2 10
                    > 4 4 14
                    >
                    > Hope this help explain a little more clearly what I'm trying to do.
                    >
                    > Thanks, Simon
                    > ------------------
                    >
                    > If I understand what you're asking, then you'll have to loop
                    through the rows of your dataset to accomplish the task. I don't
                    think hundreds of points would be a problem, though thousands might
                    be, and tens of thousands probably would be.
                    >
                    > Take a look at http://srufaculty.sru.edu/david.dailey/svg/swapY.svg
                    as an example. It's a bit terse so holler if something doesn't make
                    sense.
                    >
                    > Another approach would be to render both functions f(x)=Yabsolute
                    and f(x)=Ycumulative when you first do any plotting, but to put the
                    chart of the second function in an invisible group. Then you could
                    just merely toggle the visibility of that group. This would save
                    during run-time but cost at startup time. If you had more than two
                    functions, like say dozens, then this technique would become unwieldy.
                    >
                    > Hope this helps,
                    > David
                    >
                    > [Non-text portions of this message have been removed]
                    >
                  • Andre M. Winter - Carto.net
                    hi, in a situation like this: i expected to get a mouseup-event only when finishing dragging. but
                    Message 9 of 23 , Feb 1, 2007
                    • 0 Attachment
                      hi,

                      in a situation like this:

                      <svg ... onmouseup="myDrag(evt)" onclick="myClick(evt)".../>

                      i expected to get a mouseup-event only when finishing dragging. but i
                      get a click-event too, no matter how long i dragged my stuff around.
                      ASV, FF and Opera do so, hence i expect this to be the clean behavior.
                      but how differentiating those two events? think about an overview map
                      where dragging the extent is possible and also clicking in order to set
                      a new one...

                      thx
                      andré

                      --
                      ___________________________________________________________________
                      andre m. winter,
                      cartography for internet and multimedia applications
                      schiessstand 4/1, a6091 goetzens, tyrol, austria
                      tel.: ++43.5234.32732
                      email: ml.winter@...

                      new svg book with actual scripting samples out now!
                      check http://svg.carto.net/
                    • "André M. Winter - Carto.net"
                      hi, i was just testing a map interface with FF2 and was disappointed while unloading a map and reloading another form the local filesystem. it took around
                      Message 10 of 23 , Feb 13, 2007
                      • 0 Attachment
                        hi,

                        i was just testing a map interface with FF2 and was disappointed while
                        unloading a map and reloading another form the local filesystem. it took
                        around 15sec. now FF3 (feb. 8th) does it in around 1sec and this over
                        the web. this is faster than IE6/ASV3. mouse interactions work smooth,
                        pages (also html) load at an amazing speed :-)

                        give it a try with your own files, here you go:
                        http://www.mozilla.org/projects/firefox/3.0a2/releasenotes/#download

                        andré

                        --
                        ___________________________________________________________________
                        andre m. winter,
                        cartography for internet and multimedia applications
                        schiessstand 4/1, a6091 goetzens, tyrol, austria
                        tel.: ++43.5234.32732
                        email: <winter@...>

                        <http://www.vectoreal.com/> SVG consulting and development
                        <http://www.geotrace.net/> geo-localized high quality photographs
                        <http://www.carto.at/> print and online touristic map solutions
                      • T Rowley
                        ... Some information about the SVG capabilities in 3.0a2 are listed in the following URL. Note that a number of SVG applications will have problems due to
                        Message 11 of 23 , Feb 13, 2007
                        • 0 Attachment
                          On 2/13/07 8:32 AM, André M. Winter - Carto.net wrote:
                          > i was just testing a map interface with FF2 and was disappointed while
                          > unloading a map and reloading another form the local filesystem. it took
                          > around 15sec. now FF3 (feb. 8th) does it in around 1sec and this over
                          > the web. this is faster than IE6/ASV3. mouse interactions work smooth,
                          > pages (also html) load at an amazing speed :-)
                          >
                          > give it a try with your own files, here you go:
                          > http://www.mozilla.org/projects/firefox/3.0a2/releasenotes/#download

                          Some information about the SVG capabilities in 3.0a2 are listed in the
                          following URL. Note that a number of SVG applications will have
                          problems due to regressions caused by some tree-wide gecko changes. The
                          good news is that we now have a handle on these issues and have patches
                          in hand to fix them.

                          One thing I forgot to mention in the following is that we now have
                          incremental loading of XML, so you'll see progressive rendering of SVG
                          files as they load.

                          http://weblogs.mozillazine.org/tor/archives/2007/02/gran_paradiso_alpha_2_and_svg.html

                          -tor
                        • Antoine Quint
                          Hi there, As an additional note, I d like to say that I get to work every day with the latest (give or take a couple of weeks) trunk of Gecko, which is also
                          Message 12 of 23 , Feb 13, 2007
                          • 0 Attachment
                            Hi there,

                            As an additional note, I'd like to say that I get to work every day
                            with the latest (give or take a couple of weeks) trunk of Gecko,
                            which is also used in Mozilla, for Joost and that the progress in SVG
                            support and mixing with other XML grammars supported natively in
                            Gecko has been truly amazing. Not surprised that André is already
                            benefiting from it. Firefox 3.0 should be a significant milestone for
                            SVG development, just like FF 1.5 and Opera 9 have been before it.

                            Antoine
                            --
                            Blog — http://the.fuchsia-design.com
                          • "André M. Winter - Carto.net"
                            hi tor, ... well, i reported my experience from a user perspective. i took a file out of my actual interface development (sorry not public yet) and it worked
                            Message 13 of 23 , Feb 13, 2007
                            • 0 Attachment
                              hi tor,

                              > Some information about the SVG capabilities in 3.0a2 are listed in the
                              > following URL. Note that a number of SVG applications will have
                              > problems due to regressions caused by some tree-wide gecko changes.


                              well, i reported my experience from a user perspective. i took a file
                              out of my actual interface development (sorry not public yet) and it
                              worked out of the box. it's not a simple static file (html-frameset with
                              overview map, current.scale/translate-based zoom&pan-controls, change of
                              the iframe-src of the main map, re-population of the overview (DOM
                              manips) and DOM-interaction with the HTML around. and it is ASV3-compliant.

                              if such a beast works with no problems in FF3, this is near from water
                              proof for me.


                              > One thing I forgot to mention in the following is that we now have
                              > incremental loading of XML, so you'll see progressive rendering of SVG
                              > files as they load.

                              didn't notice that yet in practice. but the last years we learned to
                              build small small and smaller files, that may be the reason...

                              --
                              ___________________________________________________________________
                              andre m. winter,
                              cartography for internet and multimedia applications
                              schiessstand 4/1, a6091 goetzens, tyrol, austria
                              tel.: ++43.5234.32732
                              email: <winter@...>

                              <http://www.vectoreal.com/> SVG consulting and development
                              <http://www.geotrace.net/> geo-localized high quality photographs
                              <http://www.carto.at/> print and online touristic map solutions
                            • TheMountainScene
                              In a FF test I ve created, a mouseover of Canada 364 Kb, it has improved from 6 seconds to 2 seconds. 2 Seconds is still much too slow compared to the Adobe
                              Message 14 of 23 , Feb 13, 2007
                              • 0 Attachment
                                In a FF test I've created, a mouseover of Canada 364 Kb, it has improved
                                from 6 seconds to 2 seconds. 2 Seconds is still much too slow compared
                                to the Adobe viewer, but it is an improvement. I submitted this as a bug
                                some time ago. For my purposes, it still falls short, and given the
                                snail's pace anything svg is moving, I see flash in my future. I keep my
                                fingers crossed, but my optimism wanes with each passing day.

                                Sean

                                André M. Winter - Carto.net wrote:
                                >
                                > hi tor,
                                >
                                > > Some information about the SVG capabilities in 3.0a2 are listed in the
                                > > following URL. Note that a number of SVG applications will have
                                > > problems due to regressions caused by some tree-wide gecko changes.
                                >
                                > well, i reported my experience from a user perspective. i took a file
                                > out of my actual interface development (sorry not public yet) and it
                                > worked out of the box. it's not a simple static file (html-frameset with
                                > overview map, current.scale/translate-based zoom&pan-controls, change of
                                > the iframe-src of the main map, re-population of the overview (DOM
                                > manips) and DOM-interaction with the HTML around. and it is
                                > ASV3-compliant.
                                >
                                > if such a beast works with no problems in FF3, this is near from water
                                > proof for me.
                                >
                                > > One thing I forgot to mention in the following is that we now have
                                > > incremental loading of XML, so you'll see progressive rendering of SVG
                                > > files as they load.
                                >
                                > didn't notice that yet in practice. but the last years we learned to
                                > build small small and smaller files, that may be the reason...
                                >
                                > --
                                > __________________________________________________________
                                > andre m. winter,
                                > cartography for internet and multimedia applications
                                > schiessstand 4/1, a6091 goetzens, tyrol, austria
                                > tel.: ++43.5234.32732
                                > email: <winter@... <mailto:winter%40carto.net>>
                                >
                                > <http://www.vectoreal.com/ <http://www.vectoreal.com/>> SVG consulting
                                > and development
                                > <http://www.geotrace.net/ <http://www.geotrace.net/>> geo-localized
                                > high quality photographs
                                > <http://www.carto.at/ <http://www.carto.at/>> print and online
                                > touristic map solutions
                                >
                                >
                              • Guy Morton
                                I wish I could report the same happy news. Unfortunately, GranParadiso (on MacOSX at least) fails to render *anything* for me. It even seems buggy in doing
                                Message 15 of 23 , Feb 13, 2007
                                • 0 Attachment
                                  I wish I could report the same happy news. Unfortunately,
                                  GranParadiso (on MacOSX at least) fails to render *anything* for me.
                                  It even seems buggy in doing normalish browser things like resizing
                                  framesets (the toolbar has half disappeared under the window title in
                                  my testing).

                                  Have a look at http://bct2.webtrak-lochard.com/ and see.

                                  It's not generating anything in the error logs that gives any
                                  indication of what it might be taking exception to either.

                                  I hope that whatever is wrong can be ironed out, as having a fast FF
                                  implementation would be a real shot in the arm for SVG, whereas a
                                  buggy implementation would just about be the kiss of death for SVG as
                                  far as this project is concerned.

                                  Guy


                                  On 14/02/2007, at 1:32 AM, André M. Winter - Carto.net wrote:

                                  > hi,
                                  >
                                  > i was just testing a map interface with FF2 and was disappointed while
                                  > unloading a map and reloading another form the local filesystem. it
                                  > took
                                  > around 15sec. now FF3 (feb. 8th) does it in around 1sec and this over
                                  > the web. this is faster than IE6/ASV3. mouse interactions work smooth,
                                  > pages (also html) load at an amazing speed :-)
                                  >
                                  > give it a try with your own files, here you go:
                                  > http://www.mozilla.org/projects/firefox/3.0a2/releasenotes/#download
                                  >
                                  > andré
                                  >
                                  > --
                                  > ___________________________________________________________________
                                  > andre m. winter,
                                  > cartography for internet and multimedia applications
                                  > schiessstand 4/1, a6091 goetzens, tyrol, austria
                                  > tel.: ++43.5234.32732
                                  > email: <winter@...>
                                  >
                                  > <http://www.vectoreal.com/> SVG consulting and development
                                  > <http://www.geotrace.net/> geo-localized high quality photographs
                                  > <http://www.carto.at/> print and online touristic map solutions
                                  >
                                  >
                                  > -----
                                  > To unsubscribe send a message to: svg-developers-
                                  > unsubscribe@yahoogroups.com
                                  > -or-
                                  > visit http://groups.yahoo.com/group/svg-developers and click "edit
                                  > my membership"
                                  > ----
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                • T Rowley
                                  ... Assuming you re talking about the Canada map in bug 319990, the version you have online right now has a JS error. Correcting that, removing the alert, and
                                  Message 16 of 23 , Feb 13, 2007
                                  • 0 Attachment
                                    On 2/13/07 2:24 PM, TheMountainScene wrote:
                                    > In a FF test I've created, a mouseover of Canada 364 Kb, it has improved
                                    > from 6 seconds to 2 seconds. 2 Seconds is still much too slow compared
                                    > to the Adobe viewer, but it is an improvement. I submitted this as a bug
                                    > some time ago. For my purposes, it still falls short, and given the
                                    > snail's pace anything svg is moving, I see flash in my future. I keep my
                                    > fingers crossed, but my optimism wanes with each passing day.

                                    Assuming you're talking about the Canada map in bug 319990, the version
                                    you have online right now has a JS error. Correcting that, removing the
                                    alert, and moving in/out right near the border (which defeats our
                                    early-reject hit detection), the major hotspots in the profile all
                                    appear inside the cairo 2D graphics library:

                                    57.20% checking if a point is inside the path
                                    99.7% of this time is spent tesselating the path to trapezoids

                                    14.83% painting paths
                                    99% of this time is spent tesselating the path to trapezoids

                                    14.51% getting screen path extent
                                    99.9% of this time is spend tesselating the path to trapezoids
                                    The reason this appears in the profile is because the style change
                                    information Gecko gives us is a general "things changed" rather than
                                    detail which would let us realize that only the fill changed and the
                                    extent didn't need to be recalculated.

                                    It seems that if cairo improved their point-in-path functionality using
                                    one of the techniques that doesn't need a whole trapezoid list, things
                                    would be a fair bit faster.

                                    Changing the style system to give detailed information is a larger scope
                                    item, though maybe something gecko would want to do as it could help
                                    other sorts of content.

                                    It does seem as though this map is a bit of a torture case for cairo's
                                    tesselator - I've passed on the URL to the cairo developers.

                                    -tor
                                  • Guy Morton
                                    Aha...well that s the problem for me. I resized the window and it appeared. Good to know you know what is causing it. And I ll add my Wow to Andre s...FF
                                    Message 17 of 23 , Feb 13, 2007
                                    • 0 Attachment
                                      Aha...well that's the problem for me. I resized the window and it
                                      appeared. Good to know you know what is causing it.

                                      And I'll add my "Wow" to Andre's...FF used to use 70% of my CPU
                                      playing this file. Now it's using about 7%. There are some screen
                                      redrawing issues though still, which you'll see if you look at the
                                      link I sent (the planes are leaving translucent colour over the map).

                                      Guy




                                      On 14/02/2007, at 2:24 AM, T Rowley wrote:

                                      > On 2/13/07 8:32 AM, André M. Winter - Carto.net wrote:
                                      >> i was just testing a map interface with FF2 and was disappointed
                                      >> while
                                      >> unloading a map and reloading another form the local filesystem.
                                      >> it took
                                      >> around 15sec. now FF3 (feb. 8th) does it in around 1sec and this over
                                      >> the web. this is faster than IE6/ASV3. mouse interactions work
                                      >> smooth,
                                      >> pages (also html) load at an amazing speed :-)
                                      >>
                                      >> give it a try with your own files, here you go:
                                      >> http://www.mozilla.org/projects/firefox/3.0a2/releasenotes/#download
                                      >
                                      > Some information about the SVG capabilities in 3.0a2 are listed in the
                                      > following URL. Note that a number of SVG applications will have
                                      > problems due to regressions caused by some tree-wide gecko
                                      > changes. The
                                      > good news is that we now have a handle on these issues and have
                                      > patches
                                      > in hand to fix them.
                                      >
                                      > One thing I forgot to mention in the following is that we now have
                                      > incremental loading of XML, so you'll see progressive rendering of SVG
                                      > files as they load.
                                      >
                                      > http://weblogs.mozillazine.org/tor/archives/2007/02/
                                      > gran_paradiso_alpha_2_and_svg.html
                                      >
                                      > -tor
                                      >
                                      >
                                      > -----
                                      > To unsubscribe send a message to: svg-developers-
                                      > unsubscribe@yahoogroups.com
                                      > -or-
                                      > visit http://groups.yahoo.com/group/svg-developers and click "edit
                                      > my membership"
                                      > ----
                                      > Yahoo! Groups Links
                                      >
                                      >
                                      >
                                    • T Rowley
                                      ... Correction - gecko does have a mechanism for splitting style information into repaint/reflow, SVG just isn t using it yet. The fun of depreciated APIs
                                      Message 18 of 23 , Feb 13, 2007
                                      • 0 Attachment
                                        On 2/13/07 3:37 PM, T Rowley wrote:
                                        > Changing the style system to give detailed information is a larger scope
                                        > item, though maybe something gecko would want to do as it could help
                                        > other sorts of content.

                                        Correction - gecko does have a mechanism for splitting style information
                                        into repaint/reflow, SVG just isn't using it yet. The fun of
                                        depreciated APIs floating around...

                                        -tor
                                      • T Rowley
                                        ... This appears to be one of the SVG applications having a regression of the onload behavior. It is fixed in my local tree which contains the patch from
                                        Message 19 of 23 , Feb 13, 2007
                                        • 0 Attachment
                                          On 2/13/07 2:58 PM, Guy Morton wrote:
                                          > I wish I could report the same happy news. Unfortunately,
                                          > GranParadiso (on MacOSX at least) fails to render *anything* for me.
                                          > It even seems buggy in doing normalish browser things like resizing
                                          > framesets (the toolbar has half disappeared under the window title in
                                          > my testing).
                                          >
                                          > Have a look at http://bct2.webtrak-lochard.com/ and see.
                                          >
                                          > It's not generating anything in the error logs that gives any
                                          > indication of what it might be taking exception to either.

                                          This appears to be one of the SVG applications having a regression of
                                          the "onload" behavior. It is fixed in my local tree which contains the
                                          patch from bug 370210.

                                          -tor
                                        • T Rowley
                                          ... In your case, this is probably largely due to the background image you re using and changes in how we implement internally. ... I don t see
                                          Message 20 of 23 , Feb 13, 2007
                                          • 0 Attachment
                                            On 2/13/07 3:41 PM, Guy Morton wrote:
                                            > Aha...well that's the problem for me. I resized the window and it
                                            > appeared. Good to know you know what is causing it.
                                            >
                                            > And I'll add my "Wow" to Andre's...FF used to use 70% of my CPU
                                            > playing this file. Now it's using about 7%.

                                            In your case, this is probably largely due to the background image
                                            you're using and changes in how we implement <svg:image> internally.

                                            > There are some screen
                                            > redrawing issues though still, which you'll see if you look at the
                                            > link I sent (the planes are leaving translucent colour over the map).

                                            I don't see redraw problems on linux here. If you could send me a
                                            screenshot I can look into the problem a bit.

                                            -tor
                                          • TheMountainScene
                                            It was fine until two days ago when I played with it a bit. I ll put the old one back up. Thanks!
                                            Message 21 of 23 , Feb 13, 2007
                                            • 0 Attachment
                                              It was fine until two days ago when I played with it a bit. I'll put the
                                              old one back up. Thanks!

                                              T Rowley wrote:
                                              >
                                              > On 2/13/07 2:24 PM, TheMountainScene wrote:
                                              > > In a FF test I've created, a mouseover of Canada 364 Kb, it has
                                              > improved
                                              > > from 6 seconds to 2 seconds. 2 Seconds is still much too slow compared
                                              > > to the Adobe viewer, but it is an improvement. I submitted this as a
                                              > bug
                                              > > some time ago. For my purposes, it still falls short, and given the
                                              > > snail's pace anything svg is moving, I see flash in my future. I
                                              > keep my
                                              > > fingers crossed, but my optimism wanes with each passing day.
                                              >
                                              > Assuming you're talking about the Canada map in bug 319990, the version
                                              > you have online right now has a JS error. Correcting that, removing the
                                              > alert, and moving in/out right near the border (which defeats our
                                              > early-reject hit detection), the major hotspots in the profile all
                                              > appear inside the cairo 2D graphics library:
                                              >
                                              > 57.20% checking if a point is inside the path
                                              > 99.7% of this time is spent tesselating the path to trapezoids
                                              >
                                              > 14.83% painting paths
                                              > 99% of this time is spent tesselating the path to trapezoids
                                              >
                                              > 14.51% getting screen path extent
                                              > 99.9% of this time is spend tesselating the path to trapezoids
                                              > The reason this appears in the profile is because the style change
                                              > information Gecko gives us is a general "things changed" rather than
                                              > detail which would let us realize that only the fill changed and the
                                              > extent didn't need to be recalculated.
                                              >
                                              > It seems that if cairo improved their point-in-path functionality using
                                              > one of the techniques that doesn't need a whole trapezoid list, things
                                              > would be a fair bit faster.
                                              >
                                              > Changing the style system to give detailed information is a larger scope
                                              > item, though maybe something gecko would want to do as it could help
                                              > other sorts of content.
                                              >
                                              > It does seem as though this map is a bit of a torture case for cairo's
                                              > tesselator - I've passed on the URL to the cairo developers.
                                              >
                                              > -tor
                                              >
                                              >
                                            • TheMountainScene
                                              The original is back up. Online, the version is still much faster, 2 vs 7 or 8 seconds. If it can get to Adobe performance, I d be happy as a clam.
                                              Message 22 of 23 , Feb 13, 2007
                                              • 0 Attachment
                                                The original is back up. Online, the version is still much faster, 2 vs
                                                7 or 8 seconds. If it can get to Adobe performance, I'd be happy as a clam.

                                                T Rowley wrote:
                                                >
                                                > On 2/13/07 2:24 PM, TheMountainScene wrote:
                                                > > In a FF test I've created, a mouseover of Canada 364 Kb, it has
                                                > improved
                                                > > from 6 seconds to 2 seconds. 2 Seconds is still much too slow compared
                                                > > to the Adobe viewer, but it is an improvement. I submitted this as a
                                                > bug
                                                > > some time ago. For my purposes, it still falls short, and given the
                                                > > snail's pace anything svg is moving, I see flash in my future. I
                                                > keep my
                                                > > fingers crossed, but my optimism wanes with each passing day.
                                                >
                                                > Assuming you're talking about the Canada map in bug 319990, the version
                                                > you have online right now has a JS error. Correcting that, removing the
                                                > alert, and moving in/out right near the border (which defeats our
                                                > early-reject hit detection), the major hotspots in the profile all
                                                > appear inside the cairo 2D graphics library:
                                                >
                                                > 57.20% checking if a point is inside the path
                                                > 99.7% of this time is spent tesselating the path to trapezoids
                                                >
                                                > 14.83% painting paths
                                                > 99% of this time is spent tesselating the path to trapezoids
                                                >
                                                > 14.51% getting screen path extent
                                                > 99.9% of this time is spend tesselating the path to trapezoids
                                                > The reason this appears in the profile is because the style change
                                                > information Gecko gives us is a general "things changed" rather than
                                                > detail which would let us realize that only the fill changed and the
                                                > extent didn't need to be recalculated.
                                                >
                                                > It seems that if cairo improved their point-in-path functionality using
                                                > one of the techniques that doesn't need a whole trapezoid list, things
                                                > would be a fair bit faster.
                                                >
                                                > Changing the style system to give detailed information is a larger scope
                                                > item, though maybe something gecko would want to do as it could help
                                                > other sorts of content.
                                                >
                                                > It does seem as though this map is a bit of a torture case for cairo's
                                                > tesselator - I've passed on the URL to the cairo developers.
                                                >
                                                > -tor
                                                >
                                                >
                                              • ddailey
                                                I ve got a few dozen examples that work fine in FF1.5, Opera 9 and IE/ASV3, but not in Gran Paradiso. The stuff that does work in Gran Paradiso, though, is
                                                Message 23 of 23 , Feb 14, 2007
                                                • 0 Attachment
                                                  I've got a few dozen examples that work fine in FF1.5, Opera 9 and IE/ASV3, but not in Gran Paradiso.
                                                  The stuff that does work in Gran Paradiso, though, is very much faster to load, and in some cases, to run script than what I'm accustomed to.
                                                  It appears that if there is any SMIL whatever, then Gran Paradiso doesn't render the file. I think FF1.5 displays the static image.

                                                  Is this the appropriate place to post examples?

                                                  regards
                                                  David

                                                  [Non-text portions of this message have been removed]
                                                Your message has been successfully submitted and would be delivered to recipients shortly.