There may also be a way to speed up the current algorithm
From what I read before, even optimizing the pause time the gain would be no
more than 1 hour which represent no more than between 1/5 and 1/8 of the
total time which is low.
My fear is that the next player version will break the bitmaps again and
we'll have to go and replace all of the remaining CompareBitmaps.
We discussed that already I think, It's what I have to do when building in
swf version 12 which is not a problem until I don't change any code first,
as soon as I modify the code and want to check in, I need to make sure the
14 tests pass.
Until all the tests pass in the actual official version of the SDK,
switching to another swf version shouldn't be a problem when re-generating
the images.
Do I miss something ?
-----Message d'origine-----
From: Alex Harui
Sent: Wednesday, November 07, 2012 12:03 AM
To: flex-dev@incubator.apache.org
Subject: Re: About Flex runtime
On 11/6/12 2:48 PM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote:
ok, I see :)
ps: Given it's slower, will it be mixed with the today pixel based
framework
in order to be used only when there is hassle dealing with differences in
the rendering pipeline ?
I suppose we could do that. We'll see as I get farther into it. My fear is
that the next player version will break the bitmaps again and we'll have to
go and replace all of the remaining CompareBitmaps. It might be better to
just accept the fact that we need to spend extra time to do display list
comparision. There may also be a way to speed up the current algorithm.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
