Yeah, that's kind of what I am thinking about. That the LFC should be able to notice something trying to be dragged, and then let it all happen in the sprite, rather than the mouse/touch events having to go all the way out to the generic LFC and then right back to the sprite to follow the drag.
On 2010-05-04, at 13:03, Henry Minsky wrote: > 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]
