On Mar 16, 4:52 pm, Andrew Leach <
andrew.leac...@gmail.com> wrote:
> Actually I'm rather surprised it's that easy to add and use custom
> properties. Using the markerOptions object to do so is undocumented,
> it appears, and it might break.
It is just a property of the "this" object which is available to the
event listener. Microsoft has invented a silly name for it like
"expando"
I believe the documentation is providing bad advice. I believe people
have to be educated.
"Functions closures" are an incredably BAD IDEA. Each marker requires
a distinct "function clusure". Each must be parsed, "pseudo-compiled"
& have separate space allocated for it. Each has its own unique stack
frame containing local variables. The code is identical but since it
is produced at run-time, it cannot be shared. It has to be
replicated. One local variable might be different for each duplicate
copy of the "function closure" but everything else is redundant.
Using a common function with a unique value assigned to each instance
is an improvement but it is still too much redundancy. For every
marker, the application must execute the
"google.maps.events.addEventListener" method. It consumes cycles &
wastes space. All event listeners point to the same function. For a
few dozen markers, who cares ? For hundreds or thousands of similar
markers, it is very wasteful.
I am trying to encourage Google to depreciate their event listener
model. It could be replaced with a single common function shared by a
group of similar markers. The same could be done for redundant styles
(color / opacity / shape).
If you check out:
http://www.polylib.us/polycluster/airports
you will see approximately 14,000 similar markers sharing just two
event listeners, one for "click", another for "mousemove". You will
also notice it is trivial to deal with multiple overlapping markers.
With Google's event listener model, the common function must be called
once per marker with a different "this" argument. In the "airports"
demo, the event listeners are called once with an array containing all
marker names. The array is in LIFO order to preserve zIndex.
Array[0] is always the element with top priority.