Also, subjectively I feel like doubling the frame rate makes it more responsive
LFCApplication.stage.frameRate=60 maybe we should make this a default? Or is that an un-neighborly thing for a downloaded app to do? On Fri, Apr 29, 2011 at 3:16 PM, Henry Minsky <[email protected]>wrote: > All the calls to invalidatePixelAlignedChildren look like they are > missing > their 'if' clause.... > > public function setY ( newy:Number ):void { > _y = newy; > // Box attributes get scaled > y = newy + ((marginTop + borderTopWidth + paddingTop) * scaleY); > { invalidatePixelAlignedChildren(); } > > > > On Fri, Apr 29, 2011 at 3:14 PM, Henry Minsky <[email protected]>wrote: > >> When I stub out the >> >> function invalidatePixelAlignedChildren () { >> return; >> >> then it gets responsive... so maybe that is being run when it does not >> need to be? >> >> >> On Fri, Apr 29, 2011 at 2:17 PM, Henry Minsky <[email protected]>wrote: >> >>> Wow that's quite a refactoring! >>> >>> It actually seemed to fix another bug which I hadn't reported yet, which >>> is in the test case below, the RTE iframe used to get get offset in the >>> wrong position as you dragged the enclosing window; the further right you >>> dragged the window, the further the offset. Some bug in computing >>> localtoglobal I think. Anyway it works properly now. >>> >>> >>> However, I see a noticably more sluggish drag behavior now in the test >>> case below. Don't know if that is the frame rate becoming visible, or >>> something eating up CPU. Can we now up >>> the Flash frame rate to make up for it? >>> >>> >>> <canvas> >>> <include href="extensions/rte.lzx"/> >>> >>> >>> <stylesheet> >>> boxmodel { >>> padding: 1 3 5 7; >>> border-width: 2 4 6 8; >>> margin: 3 7 11 15; >>> } >>> </stylesheet> >>> <class name="box" extends="view" with="boxmodel" >>> clip="true" x="10%" width="98%" height="50%" >>> shadowblurradius="10" shadowangle="45" shadowdistance="20" >>> shadowcolor="#000000" >>> cornerradius="3 7 11 15" >>> /> >>> >>> <window x="20" y="20" width="500" height="600" resizable="true"> >>> <rte width="300" height="200" text="test test"/> >>> <handler name='oninit'><![CDATA[ >>> for (var i = 0; i < 40; i++) { >>> new lz.box (this, {width: 300, height: 300,y: 200, bgcolor: >>> 0xcccccc}); >>> } >>> >>> ]]> >>> </handler> >>> >>> </window> >>> </canvas> >>> >>> >>> >>> On Fri, Apr 29, 2011 at 11:34 AM, P T Withington <[email protected]> wrote: >>> >>>> [After Henry reviews, I can check this in so Maynard and Fred can test >>>> locally.] >>>> >>>> Change ptw-20110429-3IF by [email protected] on 2011-04-29 11:27:40 EDT >>>> in /Users/ptw/OpenLaszlo/trunk >>>> for http://svn.openlaszlo.org/openlaszlo/trunk >>>> >>>> Summary: Optimize redraw of swf10 sprites >>>> >>>> Bugs Fixed: >>>> LPP-9916 swf lags iframe when dragging >>>> LPP-9919 Consolidate drawing in swf10 kernel >>>> LPP-9914 Reduce the inner shadow intensity to normal state >>>> >>>> Technical Reviewer: [email protected] (pending) >>>> QA Reviewer: [email protected], [email protected](pending) >>>> >>>> Overview: >>>> Completely reorganize drawing of swf10 sprites to 'render' time. >>>> When a sprites details change in a way that would require a >>>> redraw, mark it as dirty and invalidate the stage, use the stage >>>> render callback to update the sprite just before the display will >>>> be refreshed. >>>> >>>> Rework the shadow logic to correctly distinguish between an outer >>>> shadow (which sits in a shape behind the view so as not to be >>>> clipped) and an inner shadow (which sits in a shape that is a >>>> child of the view, just in front of the view background and behind >>>> all the child view sprites. >>>> >>>> Tests: >>>> Test cases from lpp-9912, lpp-9916. >>>> >>>> Files: >>>> M WEB-INF/lps/lfc/kernel/swf9/LzSprite.as >>>> >>>> >>>> Changeset: >>>> http://svn.openlaszlo.org/openlaszlo/patches/ptw-20110429-3IF.tar >>>> >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [email protected] >>> >>> >>> >> >> >> -- >> Henry Minsky >> Software Architect >> [email protected] >> >> >> > > > -- > Henry Minsky > Software Architect > [email protected] > > > -- Henry Minsky Software Architect [email protected]
