incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Kwiatkowski <nicho...@spoon.as>
Subject Re: Starling + Flex
Date Sun, 21 Oct 2012 23:22:42 GMT
Actually, I said the displayList /could/ be emulated, but I wouldn't be one
to do it.  Since everything in Flex pretty much depends on it, you would
need to be extremely careful for anything that would need to be optimized.
 Something I am not ;P

-Nick

On Sun, Oct 21, 2012 at 3:38 PM, sébastien Paturel
<sebpatu.flex@gmail.com>wrote:

> A display list can't be emulated? is it such a bad idea that we should not
> continue to use it anymore?
>
> It's not only the "adobe's direction issue", its the multi target
> direction issue, and getting rid of Adobe's runtime dependency
>
> Le 21/10/2012 20:00, Nicholas Kwiatkowski a écrit :
>
>  I've taken a look at it, and gave it the half-day heave.
>>
>> It looks to be a pretty big task.  The biggest problem is the lack of a
>> DisplayList, which is the model that Flex is based on.  That in itself
>> will
>> cause well over 900 classes to have to be re-engineered.  After you've
>> re=engineered those, all you would have left is the networking stack, and
>> some one-offs (like Mike's favorite -- binding!).
>>
>> I'm not saying that Flex shouldn't go that route, but I think at this
>> point
>> of the game, it would be unfeasible for us to think we can take this on in
>> the short-term.  There are LOTS of other things I'd like to see happen
>> before we refactor to use the "this is Adobe's direction today"
>> technology.
>>
>> -Nick
>>
>> On Sun, Oct 21, 2012 at 11:07 AM, aYo ~ <ayo@binitie.com> wrote:
>>
>>  Considering the discussions on the various forums, it doesn't look very
>>> promising
>>> On Oct 21, 2012 3:59 PM, "sébastien Paturel" <sebpatu.flex@gmail.com>
>>> wrote:
>>>
>>>  Thanks for the update,
>>>> but why would it require a "fairly massive rewrite" exactly?
>>>> when you say "I would look at that" about feathersui, you mean as an
>>>> alternative to flex?
>>>>
>>>> its quite a bad news IMO. if flex can't "easely" target a new rendering
>>>> layer like starling, which stay in an Adobe runtime,
>>>> what is the future of flex as a multi platform framework, and especially
>>>> as a mobile SDK?
>>>>
>>>>
>>>>   After discussing with Thibault and spending time working on this I've
>>>>
>>>>> determined that a fairly massive rewrite would be required. Shortly
>>>>>
>>>> after
>>>
>>>> they released http://feathersui.com/ and I will say that it is a nice
>>>>>
>>>> bit
>>>
>>>> of work. I would look at that.
>>>>>
>>>>> On Sat, Oct 20, 2012 at 8:40 AM, sébastien Paturel
>>>>> <sebpatu.flex@gmail.com>wrote:
>>>>>
>>>>>   Hi jonathan,
>>>>>
>>>>>> What is the state of this very promising project?
>>>>>>
>>>>>> Le 14/06/2012 18:46, Jonathan Campos a écrit :
>>>>>>
>>>>>>    Recently I've been getting aquatinted with Starling to see if
it
>>>>>>
>>>>> could
>>>
>>>> work
>>>>>>> with Flex. After a few days of playing I think that it is possible
>>>>>>>
>>>>>> but I
>>>
>>>> do
>>>>>>> see the issues now and there is plenty of work that is necessary
to
>>>>>>>
>>>>>> make
>>>
>>>> it
>>>>>>> happen.
>>>>>>>
>>>>>>> To get things going I basically cut down the UIComponent (to
the
>>>>>>> parts
>>>>>>> that
>>>>>>> I cared about), made a copy of the entire Flex framework (as
many
>>>>>>> interfaces rely on DisplayObject, etc), replaced them with Starling
>>>>>>> classes, rebuilt some of the Spark primitives, and "adjusted"
some of
>>>>>>> the
>>>>>>> starling classes to fit some of the Flash interfaces.
>>>>>>>
>>>>>>> At this point I'm definitely going to wait to get the 4.8 release
out
>>>>>>> before giving this more time but I think it is possible. I'm
sure
>>>>>>>
>>>>>> other
>>>
>>>> developers are already aware of it but if we could make some new
>>>>>>> interfaces
>>>>>>> such as an IDisplayObject it would be much easier switching out
>>>>>>> DisplayObject for a Starling DisplayObject.
>>>>>>>
>>>>>>> Just thinking out loud at this point.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message