There is code in iframemanager.js which puts things on a queue during
startup, when it thinks the iframe is not ready yet.
// check to see if the iframe is available yet...
,__checkiframe: function(id) {
var iframe = document.getElementById(id),
iframemanager = lz.embed.iframemanager;
if (iframe) {
var queue = iframemanager.__callqueue[id];
delete iframemanager.__callqueue[id];
iframemanager.__playQueue(queue);
} else {
// try again in a little while
setTimeout('lz.embed.iframemanager.__checkiframe("' + id + '")',
10);
}
}
then when it thinks the iframe exists, it plays the queue. I wonder if its
possible that the
code is keeping the queue around. Doesn't seem likely because none of those
setposition calls would execute
in that case....
On Mon, Apr 25, 2011 at 4:35 PM, P T Withington <[email protected]> wrote:
> I can't find any such queue.
>
> The calls are going through the flash external interface, which claims to
> be synchronous.
>
> I think the problem is (mostly) that Flash itself will defer redraws as
> long as there is computation going on. So, if the mouse-move handler is
> doing a zillion draw operations to update the views, no bits get to the
> screen, but at the same time, synchronous external browser calls are moving
> the iframe, so it looks out of position.
>
> Although the bug says the iframe is 'lagging', it's really the swf views
> that are lagging. In Henry's test, if he whizzes the mouse around the
> iframe tracks it perfectly, while the swf views just stay frozen. I believe
> this supports my theory that the Flash player skips refreshing the display
> as long as there is computation going on.
>
> By synching the position updates of the iframe to the idle queue, you know
> that the Flash display is up to date.
>
> On 2011-04-25, at 16:07, Max Carlson wrote:
>
> > This will help, but I think the real issue is the iframe's updateposition
> calls getting put on a queue. It seems you want each call to update the
> position to replace any others on the queue - in other words, the last call
> should win.
> >
> > On 4/25/11 12:40 PM, P T Withington wrote:
> >> [Try this out in addition to your patch. I think it improves things a
> lot. I still think we want your patch too, because I think that smooths out
> the redraw of the swf views, which flicker a lot otherwise. In the long
> run, the swf kernel should probably have a mechanism where all drawing is
> deferred to idle -- the sprites should just track what they are supposed to
> look like, and then refresh on an idle event when they are 'dirty'.]
> >>
> >> Change ptw-20110425-zC9 by [email protected] on 2011-04-25 15:33:24 EDT
> >> in /Users/ptw/OpenLaszlo/trunk
> >> for http://svn.openlaszlo.org/openlaszlo/trunk
> >>
> >> Summary: Defer iframe updates to idle
> >>
> >> Bugs Fixed: LPP-9916 iframe is lagging in the email app
> >>
> >> Technical Reviewer: [email protected] (pending)
> >> QA Reviewer: [email protected] (pending)
> >>
> >> Details:
> >> Syncronize iframe update to frame refresh
> >>
> >> Tests:
> >> Test case from bug
> >>
> >> Files:
> >> M lps/components/extensions/html.lzx
> >>
> >>
> >> Changeset:
> http://svn.openlaszlo.org/openlaszlo/patches/ptw-20110425-zC9.tar
> >
>
>
--
Henry Minsky
Software Architect
[email protected]
