FWIW the Flash 10 Sprite has it's own drag state implmentation startDrag()method public function startDrag(lockCenter:Boolean<http://livedocs.adobe.com/flex/3/langref/Boolean.html>= false, bounds: Rectangle<http://livedocs.adobe.com/flex/3/langref/flash/geom/Rectangle.html>= null): void <http://livedocs.adobe.com/flex/3/langref/specialTypes.html#void>
Lets the user drag the specified sprite. The sprite remains draggable until explicitly stopped through a call to the Sprite.stopDrag() method, or until another sprite is made draggable. Only one sprite is draggable at a time. Three-dimensional display objects follow the mouse and Sprite.startDrag()moves the object within the three-dimensional plane defined by the display object. Or, if the display object is a two-dimensional object and the child of a three-dimensional object, the two-dimensional object moves within the three dimensional plane defined by the three-dimensional parent object. Parameters lockCenter:Boolean <http://livedocs.adobe.com/flex/3/langref/Boolean.html>(default = false) — Specifies whether the draggable sprite is locked to the center of the mouse position (true), or locked to the point where the user first clicked the sprite (false). bounds:Rectangle<http://livedocs.adobe.com/flex/3/langref/flash/geom/Rectangle.html>(default = null) — Value relative to the coordinates of the Sprite's parent that specify a constraint rectangle for the Sprite. See also dropTarget<http://livedocs.adobe.com/flex/3/langref/flash/display/Sprite.html#dropTarget> stopDrag()<http://livedocs.adobe.com/flex/3/langref/flash/display/Sprite.html#stopDrag%28%29> On Tue, May 4, 2010 at 12:49 PM, Max Carlson <[email protected]> wrote: > Before we do anything I'm tempted to run the profiler and see where the > bottleneck is... > > Regards, > Max Carlson > OpenLaszlo.org > > > On 5/4/10 4:45 AM, P T Withington wrote: > >> I wonder if we could improve the Kernel API in a way that would improve >> performance regrading dragging. I'm thinking that rather than the sprite >> rippling mouse/touch-move events up to the LFC, the LFC responding, and >> sending back down to the kernel. We have a sprite API for 'draggable' that >> would let the drag handling all happen in the sprite and the sprite would >> just report back to the LFC a smaller set of events like >> dragstart/dragover/dragend. Seems you already did something like this with >> scrollable? >> >> Maybe this is too much of a change to our architecture, but it's sort of >> like pushing graphics ops down into the GPU. >> > -- Henry Minsky Software Architect [email protected]
