Well, I'm definitely interested. I'd be happy to help do whatever you need to 
get it ready for donation.

Harbs

On Jan 24, 2013, at 10:02 AM, Daniel Freeman wrote:

> @Harbs, Yup agreed.  Wait until AS"next".
> 
> My text wrapping (eMagazine) project seems such a long time ago.  I had a
> couple of commercial enquiries about developing this further - but nothing
> materialised in the end.  I moved onto other projects, planning to come
> back to this - but realistically I don't think I'll ever have time.  OK - I
> could donate it to open-source if there was interest.  I'd need to do a bit
> of tidying-up first.
> 
> The AIR app is no longer available, but there are some youtube videos on my
> old blog:
> 
> http://e2easy.wordpress.com/2009/12/03/first-beta-prototype-of-e2publish-here-now/
> 
> http://e2easy.wordpress.com/2010/04/28/e2publish-video-tutorials/
> 
> 
> 
> 
> On Thu, Jan 24, 2013 at 5:39 PM, Harbs <harbs.li...@gmail.com> wrote:
> 
>> I'm not sure that people have a problem with your attitude. (I definitely
>> don't.) I think that it wasn't totally clear what you were proposing.
>> 
>> Basically, there's not much to talk about until ASNext is available and
>> the actual work on these components could be done. What you say about
>> waiting makes sense to me. It seems likely to me that building on your
>> components will make sense, but I don't see how we can know until we see
>> what develops between now and then.
>> 
>> On a totally separate topic:
>> 
>> I know you did work a while back on implementing text wrap for TLF. What's
>> the status of that work? Is it something you might consider donating? I'm
>> sure many of us would not mind polishing it up, if it's not yet ready for
>> publication…
>> 
>> Harbs
>> 
>> On Jan 24, 2013, at 4:23 AM, Daniel Freeman wrote:
>> 
>>> @Om, I think people misunderstand what I've demoed here.  The demo was a
>>> very quick and dirty proof of concept.  An experiment I didn't want to
>>> spend too much time on - because too much investment at this time might
>> be
>>> lost when we get to the other side of the AS"next" cataclysm.
>>> 
>>> I could have subclassed viewStack and dealt with transitions there,
>> solving
>>> any synch problems the way I do in MadComponents.  But I went with a
>> quick
>>> lash-up.
>>> 
>>> My intention for MC3D"next" is to fully integrate Stage3D capabilities
>> into
>>> MadComponents.
>>> 
>>> Maybe you've noticed that my Stage3D MC3D classes aren't fully integrated
>>> into MadComponents.  If you think that they're bolted on the side - you'd
>>> be right.  And there's a good reason for this.  Stage3D is bolted on the
>>> side of AS3.  The further that I get into work-arounds, the more I'm
>>> probably wasting effort on matters that will hopefully be resolved in
>>> AS"next" anyway.
>>> 
>>> I have a lot of display-list Sprite.graphics drawing going on right now.
>>> And unrestricted styling of display-list text.  I'm hoping that AS"next"
>>> will provide new vector graphics and text classes for Stage3D - and if it
>>> does, re-writing my existing component rendering code might be
>>> straightforward.  And I might not need a geometric renderer work-around
>>> after all.
>>> 
>>> But I don't know yet.
>>> 
>>> Personally, I wouldn't invest too much effort in a new framework now.  (
>>> Unless, you're on a beta programme for AS"next" that I don't know about
>> ).
>>> For me, there are too many unknowns right now.  If I were you, I would
>>> plan to work on this intensely on this as soon as an AS"next" beta
>>> programme kicks off.
>>> 
>>> Om, I've come onto this forum being completely honest about my
>> intentions.
>>> And people don't like my attitude.  It is my intention deliver
>> MC3D"next".
>>> Not Flex"next".  My idea is to offer these classes as the basis for
>>> Flex"next" - if you want.
>>> 
>>> 
>>> On Wed, Jan 23, 2013 at 9:04 AM, Om <bigosma...@gmail.com> wrote:
>>> 
>>>> On Mon, Jan 21, 2013 at 3:30 AM, Daniel Freeman <
>> madcompone...@gmail.com
>>>>> wrote:
>>>> 
>>>>> I've done some experiments with Stage3D accelerated Flex components,
>>>>> derived from MadComponents classes.
>>>>> 
>>>>> 
>>>>> 
>>>> 
>> http://madskool.wordpress.com/2013/01/21/madcomponents3d-part5-stage3d-accelerated-flex/
>>>>> 
>>>>> It is my intention to port MadComponents to AS"next".  I propose that
>>>> these
>>>>> ported MadComponents/MC3D classes might form the basis of a new Flex
>>>> mobile
>>>>> framework that utilises hardware GPU rendering.
>>>>> 
>>>>> I'm aware that Thibault Imbert has proposed that a new Flex framework
>>>>> should be based on Starling and Feathers.  But I believe that the MC3D
>>>>> approach is better suited to the next Flex mobile framework.
>>>>> 
>>>>> MadComponents is a fully fledged framework, not just a UI framework.
>> It
>>>>> allows for versatile styling of components (without having to design
>>>>> texture skins), server communication, and memory management.
>>>>> 
>>>>> However, until we know more about AS"next", which framework approach to
>>>>> choose is mostly speculation.
>>>>> 
>>>>> So I'd like the members of this group to read my blog post, and let me
>>>> know
>>>>> what they think.
>>>>> 
>>>> 
>>>> 
>>>> Daniel,
>>>> 
>>>> Thanks for your interest in helping out Apache Flex!
>>>> 
>>>> I have been following Madcomponents and your blog for a while now.  I
>>>> looked your example in your "stage3d accelerated flex" post [1].  While
>>>> that is good for a nice looking demo, I dont think that the approach you
>>>> suggest can be used to support an real framework like Flex.
>>>> 
>>>> Whenever I see a reference to FlexGlobals.topLevelApplication anywhere
>> in a
>>>> component's code, I always think of it as a hackish workaround trying to
>>>> cover up for the lack of a good design.  More specifically, this
>> approach
>>>> would blow up when there are two instances (Lists in your example) on
>> the
>>>> stage and we try to animate both of them at the same time or at a slight
>>>> lag.  The topLevelApplication goes invisible, the first List does its
>> thing
>>>> on the gpu, then sets the topLevelApplication to be visible.  Now, if
>> the
>>>> second component had already started the transition, it would expect the
>>>> topLevelApplication to be invisible while it runs.  But the first
>> component
>>>> would have made it visible because it had finished running.  This would
>>>> cause quite serious rendering issues to say the least.
>>>> 
>>>> While I have your attention, I would like to talk about another blog
>> post
>>>> of yours that I had bookmarked a while ago [2]  Here, you talk about
>>>> building a set of UI components from scratch that would directly draw to
>>>> Stage3D (no starling or anything in between)  I think that your example
>> and
>>>> your approach made a lot of sense.  If you have been following the
>> thread
>>>> [3], we are talking about a brand new flex framework designed from
>> scratch.
>>>> This is where I am planning to spend my time on for the next few months.
>>>> My hope was to start building a graphics rendering layer that draws
>>>> directly to Stage3D, much like how you mention in the blog post.  Is
>> this
>>>> something you can help out with?  This approach would set us free of the
>>>> shackles of the current Flex framework - which frankly needs a lot of
>>>> rework and/or hacks to support Stage3D.
>>>> 
>>>> Regards,
>>>> Om
>>>> 
>>>> 
>>>> [1]
>>>> 
>>>> 
>> http://code.google.com/p/mad-components/source/browse/trunk/FlexMadComponents/src/FlexMadPageTransitions.mxml
>>>> [2]
>>>> 
>>>> 
>> http://madskool.wordpress.com/2012/04/10/drawing-madcomponents-with-stage3d/
>>>> [3] http://markmail.org/message/yjykc72a7qeoootr
>>>> 
>> 
>> 

Reply via email to