On Jan 11, 5:09 pm, John Mick <[email protected]> wrote: > Hello again! > > I have been making progress since the last time we discussed the > issue. I believe I have solved my issue by finishing the development > of a JavaScript Abstraction Library for SVG and VML. With the library > I designed I am able to generate either SVG/VML polygons and then > change whatever attributes I'd like on them once they have been > rendered on the map.
CANVAS cannot change attributes in place because it does not have a "path" or a "shape" sub-element to tweak, just one CANVAS element per tile. For many polys, it is advantageous because of the light weight DOM. For just a few polys, it is less flexible. I have figured out a way to process mouse events which CANVAS does not support directly. It is quicker than the built-in support for SVG. I am trying to deal with a different situation - hundreds of polys with thousands of vertices. I am trying to make dragging / panning / zooming fast enough to replace tile layer overlays. Google has the resources to build tiles for many different zoom levels but few developers do. > My initial tests suggest that this does at the very least > significantly slow the rate at which memory usage increases in > browsers, (and may in some cases stop leaks all-together), because I > am able to take an approach where I create just the elements that I > need then only modify attributes on them. It seems removing, > creating, and then adding elements (with no events or any > complications) still isn't perfect in terms of having memory > reclaimed. I am not sure how you determine memory leakage except by running the application for a long period of time in different browsers. Garbage collection works within a range just like the thermostat in your home. The actual memory usage fluctuates. If it runs for hours without crashing, it is good enough for me. I do not have a working Internet Explorer installation to test. > Anyhow I have a test application hosted here: > http://www.nstb.tc.faa.gov/v3jsvgvml/ > > It generates 10 Polygons on the map, then after 2 seconds begins to > change the points on the polygons randomly every second. The test > also has a slider which allows the user to change the opacity value on > all of the polygons while this is happening. I have tested this to at > least render and work in IE6, IE7, IE8, Safari 5, Opera 11, Chrome 8, > and FF 3. Tonight I intend to begin examining specifically how much > this approach helps with memory usage, by allowing the browsers to run > this page for extended periods of time. > > I'd love to share my source code for the library, but unfortunately > I'm not able to. But Bratliff, thank you for your insights, our > conversation definitely helped reinforce my motivation that this was > something that I needed to complete, because the V3 API is not going > to do what I need. I protect mine too but mainly to prevent others from mangling my code. I have recently added "light weight" markers. Unfortunately, I do not have a demo ready. I discovered a bug I introduced several months ago which broke internal caching. I fixed it yesterday. -- 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.
