Yes I saw that, but it is only there at startup. It's easy to check in the debugger.
On Apr 25, 2011, at 17:24, Henry Minsky <[email protected]> wrote: > 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] > >
