It sounds like you're proposing to replace event listeners with event
delegates. For example, say you have a function called "handleMarkerClick".
Event listener:
google.maps.event.addListener(marker, 'click', handleMarkerClick);
This allocates objects for each marker.
Event delegate:
marker.onclick = handleMarkerClick;
This does not allocate any objects.
We use event delegates internally, and this is how the change handlers like
marker.positionChanged work. But you're right that event delegates are not
exposed in the API. We'll think about exposing these.
Cheers
Ben
On Thu, Mar 3, 2011 at 3:17 PM, bratliff <[email protected]> wrote:
> On Mar 2, 8:53 pm, Ben Appleton <[email protected]> wrote:
> > > The use of "function closures" for event listeners might work for a
> > > few dozen markers but it does not scale well for many hundred or many
> > > thousand. Combining event listeners into a common function with
> > > something unique assigned to a property of the marker's "this" object
> > > is a step in the right direction. The redundant function code is
> > > reduced but each marker still requires its own event listener pointing
> > > to the same common function.
> >
> > It sounds like you're making a new function for each marker's listener.
> Note
> > that the event target is passed as 'this' to an event listener, so you
> can
> > reuse a single closure for a class of targets. This is what we do
> internally
> > for efficiency.
>
> I do not use API markers at all. Just a suggestion to improve event
> listeners without requiring hundreds or thousands of redundant
> pointers to the same common function. You could define the function
> once for an entire "class" of similar markers. The function would
> receive an argument identifying which marker was the target.
>
> > > CANVAS does not provide native mouse support. All event listeners
> > > must call some function to determine which of many candidates in a
> > > tile caused the mouse event. Instead of hundreds or thousands of
> > > pointers to a shared function, why not define the function once for an
> > > entire set of markers. Similarly, separate calls to the "setMap"
> > > method might be combined.
> >
> > We invert the control flow that you describe. On click a single function
> > computes which marker was hit, and triggers an event on the Marker
> object.
>
> But you have to maintain a zillion different pointers to the same
> common function. Inserting or removing markers means you must create
> or delete event listeners. If you do it once for a class of markers,
> you never have to do it again. Garbage collection is simplified.
>
> --
> 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.
>
>
--
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.
