Hey sorry for the delay - I ended up getting pretty sick over the weekend and haven't been back into the office until today.
I was all setup to run your test on Friday under IE8 - Chrome - and Firefox, but the interval on calling Cycle was changed from the previous 3 seconds to 0 ms. Opening the test in those 3 browsers (each full-screen on one of 3 monitors) had my CPU usage hanging out at around 60%+. I didn't really want to tax the work machine that badly over the weekend so I elected to not run the test. Anyhow I am glad that our discussions helped you find some ways to improve your library - it is a very impressive. I definitely recommend using SVG as a default over CANVAS. Though both SVG and CANVAS require the browser to render the individual pixels when they are displayed - CANVAS, being bitmap based, has to store a value for what it is that it is going to draw on every point - unlike SVG which uses a more mathematical vector approach. In testing - I found that very very very large CANVAS objects took significantly more memory to render than SVG objects of the same size. I also found that increasing the scale of an SVG object doesn't necessarily increase the memory usage - if we are only talking about rendering - when the SVG object falls outside of the viewpoint of the browser itself (if the object was being drawn off-screen). I am going to continue working on tweaking my own custom solution - which overlays very large SVG objects over the map once - then alters those objects directly whenever data changes, instead of deleting and re-creating new ones. Time to refresh my memory on how to embed those VML script and namespace tags. Thanks again for your help as well - it feels significantly better knowing that somebody else out there has some real experience with problems like this. (I've felt so alone for awhile! Haha) On Dec 6, 12:05 pm, bratliff <[email protected]> wrote: > On Dec 3, 6:07 pm, John Mick <[email protected]> wrote: > > > 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. > > Did anything crash ? > > I added five copies of each poly to the test case. I ran it overnight > on a very old computer. It was still running in the morning with no > change in speed. > > I have made several improvements. SVG is the default. I might > discard CANVAS. > > Your application is fairly unique. It helped me isolate & fix some > bugs. It is not safe to simply rebuild dirty tiles. It causes the > zIndex order to change. Adjacent tiles with different zIndex orders > are apparent. If a poly changes position, I have to do a full > rebuild. I believe it is working now. > > Your custom solution will provide the best performance. Both > PolyCluster & the API build tiles to expedite dragging, panning & > zooming. Since you are doing none, tiles are overkill for you. > PolyCluster builds an internal cache to reduce the effort to rebuild > tiles previously in view. Again, because you quickly discard your > polys, an internal cache is overkill for you. > > Thanks again for your help. -- 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.
