This sounds like a nice optimization for dragstate, provided there's
only one view/sprite being dragged - which seems like a reasonable
assumption. Not sure how it would apply to resizestate though... Would
we have a startDragResize() and associated sprite methods?
Also, if we don't update the LFC constraints, etc won't work. I suppose
we could make sure there are no listeners for the view x/y/drag
dependencies before deferring to the sprite drag implementation.
File an improvement?
Regards,
Max Carlson
OpenLaszlo.org
On 5/4/10 11:38 AM, P T Withington wrote:
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]
