Tim, I would need to test it out, but off the top of my head I don't think
binding would do the job. Let's say Sprite A was scaled up. Even though
Sprite C's coordinates in relation to UIComponent B have changed, its actual
coordinates in relation to Sprite B (its parent) have not changed, theref
If you can use a subclass of Sprite that dispatches the events you need, that
will be the least expensive solution in terms of CPU usage. If you can't use a
subclass or you won't have so many Sprites that polling will matter, polling
will probably be sufficient.
Alex Harui
Flex SDK Developer
A
What would be invalidating UIComponent A's display list? It's my
understanding that if Sprite B were to be scaled (which is likely--it is
a graphic editing app afterall) but not Sprite A, the display list of
UIComponent A would never be invalidated, so updateDisplayList wouldn't
be called in t
Unfortunately that isn't a great option in our case. The sprite in
question is part of a graphical editor where dozens and dozens of
sprites may be on the stage and they only provide a simple graphical
representation so converting them to uicomponents would probably be more
overkill than watch
Maybe I'm missing something really fundamental then; I didn't think
Sprites dispatched move and size events and the documentation doesn't
show any such events either. I'll do some more research later, but
please correct me if you know something I don't.
Thanks for the response.
Aaron
Tim Ho
5 matches
Mail list logo
