On Dec 3, 6:07 pm, John Mick <[email protected]> wrote:
> No problem Berry - I'm actually pleased to finally touch base with
> somebody who has some experience working on a similar issue as I have
> so running a test is the least I can do!
>
> Nothing crashed, though IE8 did crash when I closed it - which I
> wouldn't really worry about.
>
> It's really a pain to know if the garbage-collector was going to come
> around or not in Chrome in FF - but I usually assume that I catch it
> when you see a huge peak in memory usage and then it drops down.
>
> I had explored this issue a lot a when I was developing on V2 about 2
> years ago - browsers have changed a lot since then - and I strayed
> away from using CANVAS because it seemed like Garbage Collectors had a
> harder time reclaiming memory used on CANVAS objects after a redraw
> compared to SVG objects.
You could be right. I am willing to scrap CANVAS if it is failing to
release its memory. I implemented CANVAS first because I could
combine a lot of polys in the same element. SVG requires "path" sub-
elements. CANVAS does not. CANVAS dragging, panning & zooming is
fast but mouse events are not supported.
You can see the performance differences in several of the
"experimental" demos at:
http://www.polylib.us
Click the "Examine" button to observe changes in the DOM structure.
> Also, I figured SVG objects would use less memory than CANVAS objects
> for especially large Polygons - since they are Vector based as opposed
> to bitmap based.
But it still has to render individual pixels. For CANVAS, the bitmap
is displayed directly.
> I noted that V3 creates SVG and VML for their Polygon objects - but
> they create a series of Viewboxes - one for each 256 x 256 grid on the
> map. I guess that makes sense since the map will only draw the
> portions of the SVG/VML that it needs (and from a purely design
> principle it seems to fit in with the rendering of everything else on
> the map ) - but I think it also could be a source of the leaking,
> since the implementation has to create events for each square grid
> viewpoint and constantly remove and create new ones as the map is
> dragged around.
PolyCluster also builds tiles. It is to improve performance during
dragging, panning & zooming. Individual tiles are built on demand
depending on what is in view. An internal cache reduces the grunt
work.
> I'll be leaving for the weekend in a few hours - when I leave today
> I'll clear out all my cache and make sure I am loading your SVG
> version test and let that run over the weekend, so we'll have several
> days of usage to look at on Monday.
>
> At this point I've completely given up on using Google's Polygon
> objects (at least in the state they are in now) - but I'm happy to
> continue our conversation on custom implementations of this.
I agree. The use of the "new google.maps.LatLng()" constructor for
every point is absurd. The use of MVC arrays also seems to be
overkill except for interactive editing. Rebuilding a poly one point
at a time is very inefficient.
--
You received this message because you are subscribed to the Google Groups
"Google Maps JavaScript API v3" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-maps-js-api-v3?hl=en.
