Amy Muntz | 1 May 23:40 2011

Re: LPP-7837 can be closed (https / SSL dataset won't load in Proxied Modus)

Thanks, Raju.

On Sat, Apr 30, 2011 at 12:23 PM, Raju Bitter <r.bitter.mailinglists <at> googlemail.com> wrote:
Henry, Sebastian,

http://jira.openlaszlo.org/jira/browse/LPP-7837 is a Java/Tomcat
configuration problem. I've added a solution as a comment. Amy might
want to close the issue.

P T Withington | 2 May 00:02 2011
Picon

Re: [Laszlo-reviews] For Review: Change ptw-20110429-3IF Summary: Optimize redraw of swf10 sprites

Is there any sort of a leak tool that you can run on teh swf with your test case?

I have a bad feeling, because I left your test case open last night and when I came back my machine was totally
hung.  I had to force reboot it to get it back...

On 2011-04-29, at 18:39, Henry Minsky wrote:

> Go for it
> 
> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>> Scratch that.  I just tried it.  Doesn't improve things that I can see.
>> 
>> How about I just check in with the invalidatePixelAligned chopped out?
>> 
>> On 2011-04-29, at 18:24, Henry Minsky wrote:
>> 
>>> I think that is a good idea, I'll revert it
>>> 
>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>> One other thought:
>>>> 
>>>> Now that we draw more conservatively, maybe we don't need to pace the mouse-move events?  What if we try
reverting r19117?
>>>> 
>>>> On 2011-04-29, at 15:25, Henry Minsky wrote:
>>>> 
>>>>> 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 <henry.minsky <at> gmail.com>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 <henry.minsky <at> gmail.com>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 <henry.minsky <at> gmail.com>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" resizab
> 
> -- 
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com

Henry Minsky | 2 May 02:05 2011
Picon

Re: [Laszlo-reviews] For Review: Change ptw-20110429-3IF Summary: Optimize redraw of swf10 sprites

there is some kind of memory allocation trace in the flex profiler view in Flash Builder. I will try running
the app in it. You didn't check in the patch yet, right?

On Sun, May 1, 2011 at 6:02 PM, P T Withington <ptw <at> pobox.com> wrote:
Is there any sort of a leak tool that you can run on teh swf with your test case?

I have a bad feeling, because I left your test case open last night and when I came back my machine was totally hung.  I had to force reboot it to get it back...

On 2011-04-29, at 18:39, Henry Minsky wrote:

> Go for it
>
> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>> Scratch that.  I just tried it.  Doesn't improve things that I can see.
>>
>> How about I just check in with the invalidatePixelAligned chopped out?
>>
>> On 2011-04-29, at 18:24, Henry Minsky wrote:
>>
>>> I think that is a good idea, I'll revert it
>>>
>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>> One other thought:
>>>>
>>>> Now that we draw more conservatively, maybe we don't need to pace the mouse-move events?  What if we try reverting r19117?
>>>>
>>>> On 2011-04-29, at 15:25, Henry Minsky wrote:
>>>>
>>>>> 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 <henry.minsky <at> gmail.com>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 <henry.minsky <at> gmail.com>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 <henry.minsky <at> gmail.com>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" resizab
>
> --
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com




--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com


Henry Minsky | 2 May 02:09 2011
Picon

Re: [Laszlo-reviews] For Review: Change ptw-20110429-3IF Summary: Optimize redraw of swf10 sprites

Oh I see you did. I will run the profiler on my test case

On Sun, May 1, 2011 at 8:05 PM, Henry Minsky <henry.minsky <at> gmail.com> wrote:
there is some kind of memory allocation trace in the flex profiler view in Flash Builder. I will try running
the app in it. You didn't check in the patch yet, right?


On Sun, May 1, 2011 at 6:02 PM, P T Withington <ptw <at> pobox.com> wrote:
Is there any sort of a leak tool that you can run on teh swf with your test case?

I have a bad feeling, because I left your test case open last night and when I came back my machine was totally hung.  I had to force reboot it to get it back...

On 2011-04-29, at 18:39, Henry Minsky wrote:

> Go for it
>
> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>> Scratch that.  I just tried it.  Doesn't improve things that I can see.
>>
>> How about I just check in with the invalidatePixelAligned chopped out?
>>
>> On 2011-04-29, at 18:24, Henry Minsky wrote:
>>
>>> I think that is a good idea, I'll revert it
>>>
>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>> One other thought:
>>>>
>>>> Now that we draw more conservatively, maybe we don't need to pace the mouse-move events?  What if we try reverting r19117?
>>>>
>>>> On 2011-04-29, at 15:25, Henry Minsky wrote:
>>>>
>>>>> 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 <henry.minsky <at> gmail.com>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 <henry.minsky <at> gmail.com>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 <henry.minsky <at> gmail.com>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" resizab
>
> --
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com




--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com





--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com


P T Withington | 2 May 02:19 2011
Picon

Re: [Laszlo-reviews] For Review: Change ptw-20110429-3IF Summary: Optimize redraw of swf10 sprites

Thanks!

On 2011-05-01, at 20:09, Henry Minsky wrote:

> Oh I see you did. I will run the profiler on my test case
> 
> On Sun, May 1, 2011 at 8:05 PM, Henry Minsky <henry.minsky <at> gmail.com> wrote:
> 
>> there is some kind of memory allocation trace in the flex profiler view in
>> Flash Builder. I will try running
>> the app in it. You didn't check in the patch yet, right?
>> 
>> 
>> On Sun, May 1, 2011 at 6:02 PM, P T Withington <ptw <at> pobox.com> wrote:
>> 
>>> Is there any sort of a leak tool that you can run on teh swf with your
>>> test case?
>>> 
>>> I have a bad feeling, because I left your test case open last night and
>>> when I came back my machine was totally hung.  I had to force reboot it to
>>> get it back...
>>> 
>>> On 2011-04-29, at 18:39, Henry Minsky wrote:
>>> 
>>>> Go for it
>>>> 
>>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>>> Scratch that.  I just tried it.  Doesn't improve things that I can see.
>>>>> 
>>>>> How about I just check in with the invalidatePixelAligned chopped out?
>>>>> 
>>>>> On 2011-04-29, at 18:24, Henry Minsky wrote:
>>>>> 
>>>>>> I think that is a good idea, I'll revert it
>>>>>> 
>>>>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>>>>> One other thought:
>>>>>>> 
>>>>>>> Now that we draw more conservatively, maybe we don't need to pace the
>>> mouse-move events?  What if we try reverting r19117?
>>>>>>> 
>>>>>>> On 2011-04-29, at 15:25, Henry Minsky wrote:
>>>>>>> 
>>>>>>>> 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 <
>>> henry.minsky <at> gmail.com>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 <
>>> henry.minsky <at> gmail.com>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 <
>>> henry.minsky <at> gmail.com>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" resizab
>>>> 
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky <at> laszlosystems.com
>>> 
>>> 
>> 
>> 
>> --
>> Henry Minsky
>> Software Architect
>> hminsky <at> laszlosystems.com
>> 
>> 
>> 
> 
> 
> -- 
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com

Raju Bitter | 2 May 11:15 2011

Re: Adding CORS support to the LFC for the DHTML runtime

I've created a simple test application for the CORS functionality
using Maven and Jetty. The code can be found here:
https://github.com/raju-bitter/openlaszlo-cors-test

I'll send in a changeset for review a bit later, which uses this web
application for testing. For CORS testing you need at least a server
running on an different port than LPS. Since Maven will download all
dependencies, it should be enough to get the source code or the
ZIP/Tar file and just do a
mvn jetty:run

to have the test application running at http://localhost:9000/cors

On Sat, Apr 30, 2011 at 7:23 PM, Raju Bitter
<r.bitter.mailinglists <at> googlemail.com> wrote:
> For the SWF10 runtime, the value of is set inside
>
> LzHTTPLoader.as#loadXMLDoc
>        var secure:Boolean = (url.indexOf("https:") == 0);
>
>
> On Sat, Apr 30, 2011 at 6:57 PM, Raju Bitter
> <r.bitter.mailinglists <at> googlemail.com> wrote:
>> Henry,
>>
>> The "secure" property of the LzHTTPLoader is not set correctly for
>> dataset requests using https. I saw the comments you've added to I've
>> created a JIRA issue, and will see if I can fix that as par of the
>> CORS support feature:
>> http://jira.openlaszlo.org/jira/browse/LPP-9923
>>
>> On Thu, Apr 28, 2011 at 7:00 PM, Raju Bitter
>> <r.bitter.mailinglists <at> googlemail.com> wrote:
>>> Thanks, Henry.
>>>
>>> On Thu, Apr 28, 2011 at 6:42 PM, Henry Minsky <henry.minsky <at> gmail.com> wrote:
>>>> I think it will not need anything to be touched in the compiler, just add
>>>> the attribute to the LzDataset class in the lfc, with proper js2doc comment,
>>>> and it will get added to the schema.
>>>>
>>>> The compiler only treats top-level dataset as a special case when it thinks
>>>> it is a constant (non-HTTP or constraint for src or type). If there is a
>>>> type='http' or a url in the
>>>> src, it compiles it with the node compiler, and will include all attributes.
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 28, 2011 at 12:23 PM, Raju Bitter
>>>> <r.bitter.mailinglists <at> googlemail.com> wrote:
>>>>>
>>>>> > Datasets are special forms, so to implement this new attribute, you'd
>>>>> > have to muck with the dataset compiler.
>>>>> That doesn't sound like fun, how can I do that?
>>>>>
>>>>> On Thu, Apr 28, 2011 at 6:20 PM, P T Withington <ptw <at> pobox.com> wrote:
>>>>> > I guess add an attribute?  Stylistically, our attributes are normally
>>>>> > all lower case, so maybe
>>>>> >
>>>>> > <attribute name="credentialled" type="boolean" />
>>>>> >
>>>>> > Datasets are special forms, so to implement this new attribute, you'd
>>>>> > have to muck with the dataset compiler.
>>>>> >
>>>>> > On 2011-04-28, at 12:15, Raju Bitter wrote:
>>>>> >
>>>>> >> But do you have any comment on how to add the "withCredentials"
>>>>> >> setting to datasets?
>>>>> >>
>>>>> >> On Thu, Apr 28, 2011 at 6:03 PM, Raju Bitter
>>>>> >> <r.bitter.mailinglists <at> googlemail.com> wrote:
>>>>> >>> The scenario I have is: I'm developing an OpenLaszlo app on
>>>>> >>> localhost:8080. I'm logging into the app, but the web service I'm
>>>>> >>> using is running on remote server connected to the Internet. When the
>>>>> >>> correct login credentials are sent to that server, the server response
>>>>> >>> will contain a set-cookie header. Any following request to the remote
>>>>> >>> server relies on the presence of that cookie value - or I'll get a 401
>>>>> >>> not authorized response.
>>>>> >>>
>>>>> >>> The scenario you are describing with Paypal is based on iFrame
>>>>> >>> behavior: When you load content in an iFrame, Safari will not accept
>>>>> >>> any cookies from the webserver serving the iFrame HTML content until
>>>>> >>> the user interacts with that frame (clicks into that frame).
>>>>> >>>
>>>>> >>> For the CORS scenario I have, check this example: Click on the button
>>>>> >>> to set a cookie in your browser following an XHR request to aruner.net
>>>>> >>> from arunranga.com. That works in Firefox and Chrome, but not in
>>>>> >>> Safari with the default settings
>>>>> >>> http://arunranga.com/examples/access-control/credentialedRequest.html
>>>>> >>> HTTP headers exchanged:
>>>>> >>> http://arunranga.com/examples/access-control/SimpleXSInvocation.txt
>>>>> >>>
>>>>> >>>
>>>>> >>> On Thu, Apr 28, 2011 at 3:16 PM, P T Withington <ptw <at> pobox.com> wrote:
>>>>> >>>> If I am reading this right, Safari's policy is to not _accept_
>>>>> >>>> cookies from a domain other than the one you are visiting.  In the case of a
>>>>> >>>> credentialed request, the request is _sending_ a cookie to the foreign
>>>>> >>>> domain, which is not going to be affected by Safari's default policy[*].
>>>>> >>>>  When you make the XHR request and set 'withCredentials' any cookies the
>>>>> >>>> browser has for that domain will be sent with the request.  If the foreign
>>>>> >>>> server accepts the request (and cookies) from your domain, it responds with
>>>>> >>>> Allow-Origin and Allow-Credentials set appropriately and you get the data.
>>>>> >>>>
>>>>> >>>> I think the scenario here is that you have previously logged in
>>>>> >>>> directly to the foreign site and this variation on the XHR request is
>>>>> >>>> allowing your (cross-origin) app to make requests including those
>>>>> >>>> credentials, while still letting the foreign server decide what (other)
>>>>> >>>> sites it will permit access for.
>>>>> >>>>
>>>>> >>>> ---
>>>>> >>>> [*] The purpose of Safari's default policy is to limit tracking by
>>>>> >>>> not _accepting_ 3rd-party cookies from embedded ads.  But as you can see if
>>>>> >>>> you go to a site that accepts paypal, it still _sends_ 3rd-party cookies
>>>>> >>>> that it may have acquired with a direct connection, which is how the
>>>>> >>>> embedded paypal button knows who you are.
>>>>> >>>>
>>>>> >>>> On 2011-04-28, at 07:12, Raju Bitter wrote:
>>>>> >>>>
>>>>> >>>>> I would say that most scenarios where CORS is really useful are
>>>>> >>>>> 1) Accessing data on remote sites through XHR for mashups.
>>>>> >>>>> 2) Localhost / server backend test scenarios: Running a local
>>>>> >>>>> installation of OpenLaszlo for development, and accessing resources
>>>>> >>>>> on
>>>>> >>>>> a remote server backend.
>>>>> >>>>>
>>>>> >>>>> For 2), the Safari cookie settings can be changed by the developer,
>>>>> >>>>> for 1) that would only be necessary when you have a cross-domain
>>>>> >>>>> request with credentials.
>>>>> >>>>>
>>>>> >>>>> On Thu, Apr 28, 2011 at 1:05 PM, Raju Bitter
>>>>> >>>>> <r.bitter.mailinglists <at> googlemail.com> wrote:
>>>>> >>>>>> That's a browser setting: Safari -> Preferences -> Security
>>>>> >>>>>>
>>>>> >>>>>> http://grack.com/blog/2010/01/06/3rd-party-cookies-dom-storage-and-privacy/
>>>>> >>>>>>
>>>>> >>>>>> On Thu, Apr 28, 2011 at 12:56 PM, Henry Minsky
>>>>> >>>>>> <henry.minsky <at> gmail.com> wrote:
>>>>> >>>>>>> One problem is, that
>>>>> >>>>>>>>
>>>>> >>>>>>>> Safari's default cookie settings are set to "Accept cookies: Only
>>>>> >>>>>>>> from
>>>>> >>>>>>>> sites I visit". That means, even with CORS/withCredentials
>>>>> >>>>>>>> support,
>>>>> >>>>>>>> without the user chaning the accept cookies settings to "always",
>>>>> >>>>>>>> the
>>>>> >>>>>>>> browser will not accept cookies for CORS requests.
>>>>> >>>>>>>
>>>>> >>>>>>> Is there any way to set that automatically from the LFC , or is
>>>>> >>>>>>> that
>>>>> >>>>>>> something the user
>>>>> >>>>>>> has to manually change in their browser settings?
>>>>> >>>>>>>
>>>>> >>>>>>> --
>>>>> >>>>>>> Henry Minsky
>>>>> >>>>>>> Software Architect
>>>>> >>>>>>> hminsky <at> laszlosystems.com
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>
>>>>> >
>>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky <at> laszlosystems.com
>>>>
>>>>
>>>>
>>>
>>
>

Raju | 2 May 14:21 2011

[Laszlo-reviews] For Review: Change raju-20110502-REe Summary: Add CORS support (including credentialled requests) to the LFC data classes

Henry, André,

this is a first changeset to enable credentialled CORS support, and fixing the handling of the "secure"
property in these classes. I'm planning to do a bit more

a) output a warning when a CORS request fails (similar to what we have with crossdomain request in Flash)
b) Use the secureport value when detecting a CORS request. But I have a question on that: What should happen
if the user specifices the port as part of the  <at> src attribute on the dataset, and doesn't set the secureport property?

Raju

Change raju-20110502-REe by raju <at> ringo.fritz.box on 2011-05-02 14:00:46 CEST
    in /Users/raju/src/svn/openlaszlo/cors
    for http://svn.openlaszlo.org/openlaszlo/trunk

Summary: Add CORS support (including credentialled requests) to the LFC data classes

New Features:
Support credentialled cross-origin resource sharing requests.

Bugs Fixed: LPP-9922,LPP-9923

Technical Reviewer: hminsky <at> laszlosystems.com,andre.bargull <at> udo.edu 
QA Reviewer: (pending)
Doc Reviewer: (pending)

Documentation:
New attribute  <at> credentialled is documented on the dataset tag.

Release Notes:
Datasets in DHTML runtime support cross-origin resource sharing requests with credentials and cookies now.

Overview:
Add support for credentialled cross-origin resource sharing requests by setting the property
'withCredentials' on the XHR object to 'true'.

Details:
LzDataset.lzs:
* property credentialled added to dataset. The value of this property will be used for the
XHR.withCredentials property when loading the data.

LzHTTPDataProvider.lzs
* method makeLoader: set the credentialled value on the LzHTTPLoader object.
* method makeLoader: remove unnecessary check if (secure == null) {, when setting the secure value on the
LzHTTPLoader object.

LzHTTPDataRequest.lzs
* property credentialled added.
* method set

LzHTTPLoader.js
* add properties iscors and credentialled.
* method LzHTTPLoader.prototype.setCredentialled added.
* method LzHTTPLoader.prototype.checkIfCORS added. Used to check if a request is a CORS request based on
domain/host and port of the request.

LzHTTPLoader.as
  * property credentialled added.
  * setter method setCredentialled added.

Tests:
LZX test file added test/data/dhtml-cross-origin-dataset.lzx. The test relies on a test webapp
application running on http://localhost:9000/cors. The source code with a Maven pom file for running
the webapp in Jetty can be downloaded here:
https://github.com/raju-bitter/openlaszlo-cors-test

After downloading the files, go into the folder openlaszlo-cors-test and execute
mvn jetty:run

Maven will download all dependencies, and launch the Jetty server on port 9000. If you navigate your
browser to http://localhost:9000/cors you can find some information on the test application and the
URLs used.

Files:
A       test/data/dhtml-cross-origin-dataset.lzx
M       WEB-INF/lps/lfc/kernel/dhtml/LzHTTPLoader.js
M       WEB-INF/lps/lfc/kernel/swf9/LzHTTPLoader.as
M       WEB-INF/lps/lfc/data/LzHTTPDataRequest.lzs
M       WEB-INF/lps/lfc/data/LzHTTPDataProvider.lzs
M       WEB-INF/lps/lfc/data/LzDataset.lzs
M       build.properties

Changeset: http://svn.openlaszlo.org/openlaszlo/patches/raju-20110502-REe.tar

Henry Minsky | 2 May 03:15 2011
Picon

Re: [Laszlo-reviews] For Review: Change ptw-20110429-3IF Summary: Optimize redraw of swf10 sprites

I don't see anything suspicious, at least not after a few minutes. Screen shot attached of memory profiler


It shows a flat memory usage over a period of 10 or 15 minutes. I do see a continuous update
of the number of method closures allocated, but I think those must be getting gc'd because total memory usage does not budge


On Sun, May 1, 2011 at 8:19 PM, P T Withington <ptw <at> pobox.com> wrote:
Thanks!

On 2011-05-01, at 20:09, Henry Minsky wrote:

> Oh I see you did. I will run the profiler on my test case
>
> On Sun, May 1, 2011 at 8:05 PM, Henry Minsky <henry.minsky <at> gmail.com> wrote:
>
>> there is some kind of memory allocation trace in the flex profiler view in
>> Flash Builder. I will try running
>> the app in it. You didn't check in the patch yet, right?
>>
>>
>> On Sun, May 1, 2011 at 6:02 PM, P T Withington <ptw <at> pobox.com> wrote:
>>
>>> Is there any sort of a leak tool that you can run on teh swf with your
>>> test case?
>>>
>>> I have a bad feeling, because I left your test case open last night and
>>> when I came back my machine was totally hung.  I had to force reboot it to
>>> get it back...
>>>
>>> On 2011-04-29, at 18:39, Henry Minsky wrote:
>>>
>>>> Go for it
>>>>
>>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>>> Scratch that.  I just tried it.  Doesn't improve things that I can see.
>>>>>
>>>>> How about I just check in with the invalidatePixelAligned chopped out?
>>>>>
>>>>> On 2011-04-29, at 18:24, Henry Minsky wrote:
>>>>>
>>>>>> I think that is a good idea, I'll revert it
>>>>>>
>>>>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>>>>> One other thought:
>>>>>>>
>>>>>>> Now that we draw more conservatively, maybe we don't need to pace the
>>> mouse-move events?  What if we try reverting r19117?
>>>>>>>
>>>>>>> On 2011-04-29, at 15:25, Henry Minsky wrote:
>>>>>>>
>>>>>>>> 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 <
>>> henry.minsky <at> gmail.com>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 <
>>> henry.minsky <at> gmail.com>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 <
>>> henry.minsky <at> gmail.com>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" resizab
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky <at> laszlosystems.com
>>>
>>>
>>
>>
>> --
>> Henry Minsky
>> Software Architect
>> hminsky <at> laszlosystems.com
>>
>>
>>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com




--
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com


Henry Minsky | 2 May 15:13 2011
Picon

Re: [Laszlo-reviews] For Review: Change ptw-20110429-3IF Summary: Optimize redraw of swf10 sprites

I left my firefox running the test case last night and this morning it
did seem like it was very sluggish. But the memory profiler did not
report the flash app taking any more memory. Hmm

On Sunday, May 1, 2011, Henry Minsky <henry.minsky <at> gmail.com> wrote:
> I don't see anything suspicious, at least not after a few minutes. Screen shot attached of memory profiler
> It shows a flat memory usage over a period of 10 or 15 minutes. I do see a continuous update
>
> of the number of method closures allocated, but I think those must be getting gc'd because total memory
usage does not budge
>
>
> On Sun, May 1, 2011 at 8:19 PM, P T Withington <ptw <at> pobox.com> wrote:
> Thanks!
>
> On 2011-05-01, at 20:09, Henry Minsky wrote:
>
>> Oh I see you did. I will run the profiler on my test case
>>
>> On Sun, May 1, 2011 at 8:05 PM, Henry Minsky <henry.minsky <at> gmail.com> wrote:
>>
>>> there is some kind of memory allocation trace in the flex profiler view in
>>> Flash Builder. I will try running
>>> the app in it. You didn't check in the patch yet, right?
>>>
>>>
>>> On Sun, May 1, 2011 at 6:02 PM, P T Withington <ptw <at> pobox.com> wrote:
>>>
>>>> Is there any sort of a leak tool that you can run on teh swf with your
>>>> test case?
>>>>
>>>> I have a bad feeling, because I left your test case open last night and
>>>> when I came back my machine was totally hung.  I had to force reboot it to
>>>> get it back...
>>>>
>>>> On 2011-04-29, at 18:39, Henry Minsky wrote:
>>>>
>>>>> Go for it
>>>>>
>>>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>>>> Scratch that.  I just tried it.  Doesn't improve things that I can see.
>>>>>>
>>>>>> How about I just check in with the invalidatePixelAligned chopped out?
>>>>>>
>>>>>> On 2011-04-29, at 18:24, Henry Minsky wrote:
>>>>>>
>>>>>>> I think that is a good idea, I'll revert it
>>>>>>>
>>>>>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>>>>>> One other thought:
>>>>>>>>
>>>>>>>> Now that we draw more conservatively, maybe we don't need to pace the
>>>> mouse-move events?  What if we try reverting r19117?
>>>>>>>>
>>>>>>>> On 2011-04-29, at 15:25, Henry Minsky wrote:
>>>>>>>>
>>>>>>>>> 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 <
>>>> henry.minsky <at> gmail.com>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 <
>>>> henry.minsky <at> gmail.com>wrote:
>>>>>>>>>>
>>>>>>>>>>> When I stub out the
>>>>>>>>>>>
>>>>>>>>>>> function invalidatePixelAlignedChildren () {
>>>>>>>>>>>       return;
>>--
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com
>
>
>
>

--

-- 
Henry Minsky
Software Architect
hminsky <at> laszlosystems.com

P T Withington | 2 May 15:28 2011
Picon

Re: [Laszlo-reviews] For Review: Change ptw-20110429-3IF Summary: Optimize redraw of swf10 sprites

What does your activity monitor think?  Maybe it is the browser that is bloating, not the swf player?  Maybe
there is a leak in the <html> implementation?

On 2011-05-02, at 09:13, Henry Minsky wrote:

> I left my firefox running the test case last night and this morning it
> did seem like it was very sluggish. But the memory profiler did not
> report the flash app taking any more memory. Hmm
> 
> On Sunday, May 1, 2011, Henry Minsky <henry.minsky <at> gmail.com> wrote:
>> I don't see anything suspicious, at least not after a few minutes. Screen shot attached of memory profiler
>> It shows a flat memory usage over a period of 10 or 15 minutes. I do see a continuous update
>> 
>> of the number of method closures allocated, but I think those must be getting gc'd because total memory
usage does not budge
>> 
>> 
>> On Sun, May 1, 2011 at 8:19 PM, P T Withington <ptw <at> pobox.com> wrote:
>> Thanks!
>> 
>> On 2011-05-01, at 20:09, Henry Minsky wrote:
>> 
>>> Oh I see you did. I will run the profiler on my test case
>>> 
>>> On Sun, May 1, 2011 at 8:05 PM, Henry Minsky <henry.minsky <at> gmail.com> wrote:
>>> 
>>>> there is some kind of memory allocation trace in the flex profiler view in
>>>> Flash Builder. I will try running
>>>> the app in it. You didn't check in the patch yet, right?
>>>> 
>>>> 
>>>> On Sun, May 1, 2011 at 6:02 PM, P T Withington <ptw <at> pobox.com> wrote:
>>>> 
>>>>> Is there any sort of a leak tool that you can run on teh swf with your
>>>>> test case?
>>>>> 
>>>>> I have a bad feeling, because I left your test case open last night and
>>>>> when I came back my machine was totally hung.  I had to force reboot it to
>>>>> get it back...
>>>>> 
>>>>> On 2011-04-29, at 18:39, Henry Minsky wrote:
>>>>> 
>>>>>> Go for it
>>>>>> 
>>>>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>>>>> Scratch that.  I just tried it.  Doesn't improve things that I can see.
>>>>>>> 
>>>>>>> How about I just check in with the invalidatePixelAligned chopped out?
>>>>>>> 
>>>>>>> On 2011-04-29, at 18:24, Henry Minsky wrote:
>>>>>>> 
>>>>>>>> I think that is a good idea, I'll revert it
>>>>>>>> 
>>>>>>>> On Friday, April 29, 2011, P T Withington <ptw <at> pobox.com> wrote:
>>>>>>>>> One other thought:
>>>>>>>>> 
>>>>>>>>> Now that we draw more conservatively, maybe we don't need to pace the
>>>>> mouse-move events?  What if we try reverting r19117?
>>>>>>>>> 
>>>>>>>>> On 2011-04-29, at 15:25, Henry Minsky wrote:
>>>>>>>>> 
>>>>>>>>>> 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 <
>>>>> henry.minsky <at> gmail.com>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 <
>>>>> henry.minsky <at> gmail.com>wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> When I stub out the
>>>>>>>>>>>> 
>>>>>>>>>>>> function invalidatePixelAlignedChildren () {
>>>>>>>>>>>>       return;
>>> --
>> Henry Minsky
>> Software Architect
>> hminsky <at> laszlosystems.com
>> 
>> 
>> 
>> 
> 
> -- 
> Henry Minsky
> Software Architect
> hminsky <at> laszlosystems.com


Gmane