Why aren't displayProperties optimized like contentDisplayProperties?

[Dave Porter]

SC.ContentDisplay applies a single observer on content, and another on content.* – this means that you can have as many contentDisplayProperties as you want without adding any new observer overhead.

Why isn't it a good idea to do displayProperties the same way? Add a * observer on self, and queue up displayDidChange if the changed property is in the list.

Thoughts from a client. Blew my mind. Is there something obvious I'm missing?

Dave

[Topher Fangio]

Can you very briefly describe how it is currently being done?

--

Topher Fangio

Director of Software Development
Pharos Resources

office: 325.216.2908
mobile: 325.660.7141

--
You received this message because you are subscribed to the Google Groups "SproutCore Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sproutcore-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave Porter]

displayProperties are set up with observers on each, one for each displayProperty. See core_foundation/views/view/statechart.js line 1095. contentDisplayProperties meanwhile are hooked up as a single * observer on the content item, which then checks each property change notification against the contentDisplayProperties list.

My hunch now that I think through it is that single-property observers are expensive to create, but cheap to operate going forward, whereas * property observers are cheap to create (since there can only be one), but expensive to operate going forward (since any property change triggers a scan). That means that for long-lived, relatively static views, displayProperties wins because you only do the setup once, while for fast-moving views (i.e. the canonical fast-scrolling-ListView example), the fast-to-setup * observer wins.