OK, sounds good to me.  Thanks for sticking with it.

-Alex

On 10/15/13 1:18 PM, "Maurice Amsellem" <maurice.amsel...@systar.com>
wrote:

>Alex, some good news :
>
>I found some time to run/debug the tests again and discovered that the
>way we handled updateCaretForDataProviderChange was not good.
>The way it's done now is the following:
>- setting a flag and calling invalidateDisplayList()
>-  in updateDisplayList call  caretRowIndex update in case the flag
>changes.
>
>The problem with that code is that caretRowIndex setter will call in turn
>invalidateProperties and invalidateList(), which IMO, should not happen
>in UDL.
>
>So I tried my initial fix intention, which was to do that through
>flag+invalidateProperties / commitProperties.
>
>And all the failing  tests are successful now.
>
>Do you validate ? 
>
>Maurice 
>
>-----Message d'origine-----
>De : Erik de Bruin [mailto:e...@ixsoftware.nl]
>Envoyé : mardi 15 octobre 2013 20:53
>À : dev@flex.apache.org
>Objet : Re: Build failed in Jenkins: flex-sdk_mustella #470
>
>Ok, just thought I'd mention it ;-)
>
>EdB
>
>
>
>On Tue, Oct 15, 2013 at 8:50 PM, Maurice Amsellem
><maurice.amsel...@systar.com> wrote:
>> Erik,
>>
>> The tests are passing because I have undone one the fixes that have
>>broken them.
>>
>> (FLEX-33813 (DataGrid goes blank when scrolled and dataProvider is
>> changed )
>>
>> We are currently trying to make that fix again in a different way that
>>does not break the tests again, possibly fixing also the tests.
>>
>> (At least, this is my understanding)
>>
>> Maurice
>>
>> -----Message d'origine-----
>> De : Erik de Bruin [mailto:e...@ixsoftware.nl] Envoyé : mardi 15
>> octobre 2013 20:14 À : dev@flex.apache.org Objet : Re: Build failed in
>> Jenkins: flex-sdk_mustella #470
>>
>> Build 471 passed all tests... is this player version related, or are
>>you chasing ghosts?
>>
>> EdB
>>
>>
>>
>> On Tue, Oct 15, 2013 at 7:09 PM, Alex Harui <aha...@adobe.com> wrote:
>>>
>>>
>>> On 10/15/13 9:52 AM, "Maurice Amsellem" <maurice.amsel...@systar.com>
>>> wrote:
>>>
>>>>>I will try to generate and check in png.xml files for the two
>>>>>failing tests
>>>>
>>>>Not sure to understand what png.xml files are ? the baseline pngs ?
>>> A png.xml file is an XML description of the display list.  We use
>>> them when different player versions or mac-vs-win give slightly
>>> different bitmaps.  There are only a few checked in right now.
>>> CompareBitmap first compares the .png file  and then if it fails it
>>> looks for the png.xml and compares the display list.  The theory is
>>> that Flex code really only manipulates display list properties so if
>>> a component is at x=4.5 we don't truly care what pixel colors the
>>> player chooses for pixel 4 and 5, we just want our code to set that
>>>component at x=4.5.
>>>
>>> Now if the test still fails you can compare the png.xml output and
>>> see where the proposed code did change some display list property.
>>> So far, that's found a few subtle bugs in our code.
>>>
>>> I'm still trying to get the repo back to where those tests pass so I
>>> can generate the right png.xml files, so I'm not ready to check them
>>> in just yet.
>>>
>>> -Alex
>>>
>>
>>
>>
>> --
>> Ix Multimedia Software
>>
>> Jan Luykenstraat 27
>> 3521 VB Utrecht
>>
>> T. 06-51952295
>> I. www.ixsoftware.nl
>
>
>
>--
>Ix Multimedia Software
>
>Jan Luykenstraat 27
>3521 VB Utrecht
>
>T. 06-51952295
>I. www.ixsoftware.nl

Reply via email to