You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Daniel Freeman <ma...@gmail.com> on 2013/01/21 12:30:15 UTC
Stage3D accelerated Flex components
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.
Re: Stage3D accelerated Flex components
Posted by Harbs <ha...@gmail.com>.
I think it's apparent that you've done a lot of work here, and your approach has merit.
Like Mike says, keeping an open discussion here, would be a good thing.
Personally, I have not done much mobile work, but that will likely change in the near future. So until then I don't have much to comment on...
On Jan 21, 2013, at 1:30 PM, Daniel Freeman 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.
Re: Stage3D accelerated Flex components
Posted by Arnoud Bos <ar...@artim-interactive.nl>.
No worries,
i can't even deduct that you Kevin Newman are not the author of jacksondunstan.com!
hehe :-)
Re: Stage3D accelerated Flex components
Posted by Kevin Newman <Ca...@unFocus.com>.
On 1/21/13 3:31 PM, Arnoud Bos wrote:
> Hi Kevin,
>
> I like to read your blog and learn a lot from the many interesting code optimisations. But i'm not so sure about your statements for this particular one:
>
Gah! Apparently I don't know how to read charts. This doesn't show what
I though it does, or what I thought was the bottleneck . So nevermind,
sorry for adding unneeded noise. :-)
(That's not my blog, I was just referencing it for something I thought I
saw on there, which upon revisiting, I can't see at all!)
Kevin N.
Re: Stage3D accelerated Flex components
Posted by Arnoud Bos <ar...@artim-interactive.nl>.
Hi Kevin,
I like to read your blog and learn a lot from the many interesting code optimisations. But i'm not so sure about your statements for this particular one:
running your test a few times gives me different results:
run 1:
Driver,Test,Time,Bytes/Sec
OpenGL,Texture from BitmapData w/o alpha,7,2396745.14
OpenGL,Texture from BitmapData w/ alpha,10,1677721.60
OpenGL,Texture from ByteArray,8,2097152.00
OpenGL,VertexBuffer from Vector,35,479341.71
OpenGL,VertexBuffer from ByteArray,3,5592320.00
OpenGL,IndexBuffer from Vector,2,1048574.00
OpenGL,IndexBuffer from ByteArray,1,2097148.00
Software Hw_disabled=explicit,Texture from BitmapData w/o alpha,9,1864135.11
Software Hw_disabled=explicit,Texture from BitmapData w/ alpha,4,4194304.00
Software Hw_disabled=explicit,Texture from ByteArray,4,4194304.00
Software Hw_disabled=explicit,VertexBuffer from Vector,12,1398080.00
Software Hw_disabled=explicit,VertexBuffer from ByteArray,5,3355392.00
Software Hw_disabled=explicit,IndexBuffer from Vector,1,2097148.00
Software Hw_disabled=explicit,IndexBuffer from ByteArray,1,2097148.00
run2:
Driver,Test,Time,Bytes/Sec
OpenGL,Texture from BitmapData w/o alpha,8,2097152.00
OpenGL,Texture from BitmapData w/ alpha,9,1864135.11
OpenGL,Texture from ByteArray,7,2396745.14
OpenGL,VertexBuffer from Vector,34,493440.00
OpenGL,VertexBuffer from ByteArray,3,5592320.00
OpenGL,IndexBuffer from Vector,2,1048574.00
OpenGL,IndexBuffer from ByteArray,1,2097148.00
Software Hw_disabled=explicit,Texture from BitmapData w/o alpha,9,1864135.11
Software Hw_disabled=explicit,Texture from BitmapData w/ alpha,4,4194304.00
Software Hw_disabled=explicit,Texture from ByteArray,5,3355443.20
Software Hw_disabled=explicit,VertexBuffer from Vector,12,1398080.00
Software Hw_disabled=explicit,VertexBuffer from ByteArray,4,4194240.00
Software Hw_disabled=explicit,IndexBuffer from Vector,1,2097148.00
Software Hw_disabled=explicit,IndexBuffer from ByteArray,1,2097148.00
run 3:
Driver,Test,Time,Bytes/Sec
OpenGL,Texture from BitmapData w/o alpha,6,2796202.67
OpenGL,Texture from BitmapData w/ alpha,9,1864135.11
OpenGL,Texture from ByteArray,8,2097152.00
OpenGL,VertexBuffer from Vector,33,508392.73
OpenGL,VertexBuffer from ByteArray,3,5592320.00
OpenGL,IndexBuffer from Vector,2,1048574.00
OpenGL,IndexBuffer from ByteArray,1,2097148.00
Software Hw_disabled=explicit,Texture from BitmapData w/o alpha,9,1864135.11
Software Hw_disabled=explicit,Texture from BitmapData w/ alpha,4,4194304.00
Software Hw_disabled=explicit,Texture from ByteArray,4,4194304.00
Software Hw_disabled=explicit,VertexBuffer from Vector,12,1398080.00
Software Hw_disabled=explicit,VertexBuffer from ByteArray,4,4194240.00
Software Hw_disabled=explicit,IndexBuffer from Vector,2,1048574.00
Software Hw_disabled=explicit,IndexBuffer from ByteArray,1,2097148.00
but for 2 of them (1 and 3) texture from bytearray is slower than texture from bitmapdata without alpha.
is that because i'm on a mac? or maybe the flash player improved in the meantime? The article is a bit old :-)
i'm on flash player 11.5 osx 10.8.2.
Arnoud
On 21-01-2013, at 20:54, Kevin Newman <Ca...@unFocus.com> wrote:
> Your blog post says uploads to GPU are slow, but I think that's incorrect (or at least incomplete). I think the bottle neck is the conversion from BitmapData to the texture format ( /texture.uploadFromBitmapData())/. If you use texture.uploadFromByteArray you'll see much faster throughputs. Which suggest, the bottleneck is not with stage3d and texture uploads generally, but with uploads from BitmapData (which is what the old display list produces).
>
> You may even be able to handle and cache some of that BMD -> BGRA conversion yourself in MadComponents and gain a nice performance boost by using uploadFromByteArray() (at least when you can bypass redraw from the display list, which as I've said many times, is not well suited for a GPU workflow).
>
> More:
> http://jacksondunstan.com/articles/1617
>
> Kevin N.
>
Met vriendelijke groet,
Arnoud Bos
Artim interactive
E arnoud@artim-interactive.nl
W www.artim-interactive.nl
T +31 6 246 40 216
A Elisabeth Wolffstraat 77-3
1053TT Amsterdam
Re: Stage3D accelerated Flex components
Posted by Kevin Newman <Ca...@unFocus.com>.
Your blog post says uploads to GPU are slow, but I think that's
incorrect (or at least incomplete). I think the bottle neck is the
conversion from BitmapData to the texture format (
/texture.uploadFromBitmapData())/. If you use
texture.uploadFromByteArray you'll see much faster throughputs. Which
suggest, the bottleneck is not with stage3d and texture uploads
generally, but with uploads from BitmapData (which is what the old
display list produces).
You may even be able to handle and cache some of that BMD -> BGRA
conversion yourself in MadComponents and gain a nice performance boost
by using uploadFromByteArray() (at least when you can bypass redraw from
the display list, which as I've said many times, is not well suited for
a GPU workflow).
More:
http://jacksondunstan.com/articles/1617
Kevin N.
Re: Stage3D accelerated Flex components
Posted by Kevin Newman <Ca...@unFocus.com>.
What are the bottlenecks, and how might they alleviate them? As far as I
know, there isn't really any overhead when you upload a ByteArray or
BitmapData, it's about as fast as you can get, as far as textures go.
With vector data, they could reduce the type marshaling, but that seems
like less of a problem than raw texture throughput. But texture
throughput is limited in native apps too.
Am I missing another bottleneck?
Kevin N.
On 1/30/13 2:31 AM, Daniel Freeman wrote:
> there are Stage3D
> bottlenecks that will impair performance for anything beyond games
> use-cases. If Adobe solve these technical obstructions
Re: Stage3D accelerated Flex components
Posted by Daniel Freeman <ma...@gmail.com>.
Hmm, in light of the current announcement - it looks like my MC3D"next"
plans are cancelled.
The problem with the current Flash/AIR runtimes are that there are Stage3D
bottlenecks that will impair performance for anything beyond games
use-cases. If Adobe solve these technical obstructions - then I can
accomplish in AS3 what I was proposing to accomplish in AS"next".
If they don't solve these issues - then it's probably over.
Re: Stage3D accelerated Flex components
Posted by Daniel Freeman <ma...@gmail.com>.
I've got other chores to complete first - but leave it with me.
Re: Stage3D accelerated Flex components
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <bi...@gmail.com> wrote:
>>>
>>>> On Mon, Jan 21, 2013 at 3:30 AM, Daniel Freeman <
>> madcomponents@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
>>>>
>>
>>
Re: Stage3D accelerated Flex components
Posted by Daniel Freeman <ma...@gmail.com>.
@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 <ha...@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 <bi...@gmail.com> wrote:
> >
> >> On Mon, Jan 21, 2013 at 3:30 AM, Daniel Freeman <
> madcomponents@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
> >>
>
>
Re: Stage3D accelerated Flex components
Posted by Harbs <ha...@gmail.com>.
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 <bi...@gmail.com> wrote:
>
>> On Mon, Jan 21, 2013 at 3:30 AM, Daniel Freeman <madcomponents@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
>>
Re: Stage3D accelerated Flex components
Posted by Daniel Freeman <ma...@gmail.com>.
@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 <bi...@gmail.com> wrote:
> On Mon, Jan 21, 2013 at 3:30 AM, Daniel Freeman <madcomponents@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
>
Re: Stage3D accelerated Flex components
Posted by Om <bi...@gmail.com>.
On Mon, Jan 21, 2013 at 3:30 AM, Daniel Freeman <ma...@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
Re: Stage3D accelerated Flex components
Posted by Avi Kessner <ak...@gmail.com>.
I'm on mobile, so please forgive my terseness and Typos'
What I meant is that it doesn't conceptually make sense to me to have one
server code that works in cpu mode and another server code that works in
GPU mode. Same with memory management.
For the record the tone was clear to me.
On Jan 21, 2013 5:38 PM, "Nick Collins" <nd...@gmail.com> wrote:
> I haven't seen anybody in the group expect any one person to do everything
> for them. That kind of flies in the face of the whole concept of being an
> Apache project. I think that your point, while it has some validity,
> probably didn't need to be verbalized until there was a problem. Otherwise
> it comes across as an insinuation that the group at large is just a bunch
> of parasites looking to leach off your hard work. Kind of leaves a bad
> taste in one's mouth that might cause folks to dismiss your suggestion,
> whether it has technical merit or not ( and I believe it very well may ).
>
> Nick
>
>
> On Mon, Jan 21, 2013 at 7:25 AM, Daniel Freeman <madcomponents@gmail.com
> >wrote:
>
> > @Mike, I've updated my wording slightly. But it's getting late
> (Brisbane
> > time), and I'll see how things look in the morning.
> >
> > I don't apologies for carefully qualifying my expected contributions, and
> > my expectations of other people's contribution. While I've changed the
> > wording and dressed it up a little differently - I'm still not willing to
> > write all of this for you - with no contribution from this group. As
> > MadComponents has became popular - there's been increasing expectation on
> > me to maintain, enhance, and support developers using it. While I've
> tried
> > to share the burden with other developers - I've still had to contribute
> > more time to this project than I've been comfortable with.
> >
>
Re: Stage3D accelerated Flex components
Posted by Nick Collins <nd...@gmail.com>.
I haven't seen anybody in the group expect any one person to do everything
for them. That kind of flies in the face of the whole concept of being an
Apache project. I think that your point, while it has some validity,
probably didn't need to be verbalized until there was a problem. Otherwise
it comes across as an insinuation that the group at large is just a bunch
of parasites looking to leach off your hard work. Kind of leaves a bad
taste in one's mouth that might cause folks to dismiss your suggestion,
whether it has technical merit or not ( and I believe it very well may ).
Nick
On Mon, Jan 21, 2013 at 7:25 AM, Daniel Freeman <ma...@gmail.com>wrote:
> @Mike, I've updated my wording slightly. But it's getting late (Brisbane
> time), and I'll see how things look in the morning.
>
> I don't apologies for carefully qualifying my expected contributions, and
> my expectations of other people's contribution. While I've changed the
> wording and dressed it up a little differently - I'm still not willing to
> write all of this for you - with no contribution from this group. As
> MadComponents has became popular - there's been increasing expectation on
> me to maintain, enhance, and support developers using it. While I've tried
> to share the burden with other developers - I've still had to contribute
> more time to this project than I've been comfortable with.
>
Re: Stage3D accelerated Flex components
Posted by Daniel Freeman <ma...@gmail.com>.
@Mike, I've updated my wording slightly. But it's getting late (Brisbane
time), and I'll see how things look in the morning.
I don't apologies for carefully qualifying my expected contributions, and
my expectations of other people's contribution. While I've changed the
wording and dressed it up a little differently - I'm still not willing to
write all of this for you - with no contribution from this group. As
MadComponents has became popular - there's been increasing expectation on
me to maintain, enhance, and support developers using it. While I've tried
to share the burden with other developers - I've still had to contribute
more time to this project than I've been comfortable with.
Re: Stage3D accelerated Flex components
Posted by Daniel Freeman <ma...@gmail.com>.
On Mon, Jan 21, 2013 at 10:31 PM, Avi Kessner <ak...@gmail.com> wrote:
> Conceptually, I don't understand why you would want to have more than "just
> a UI framework", if your goal is to make use of the GPU.
>
> The fewer dependencies the better.
>
>
@Avi,
I see memory management, and server communication as important aspects of
MadComponents. Not dependencies. How do you mean?
@Michael,
I don't see anything wrong with drawing a line as to how much more my time
I can dedicate to this project. Or asking for commitment and work from the
Open Flex developers. I just didn't want everyone to run away with the
idea that I was going to do ALL the work (in my experience, people usually
expect that).
MadComponents/MC3D are free and open source.
http://opensource.org/licenses/mit-license.php
I wouldn't be adverse to maintaining it under Apache, as I think that
getting more developers involved in the core MadComponents/MC3D classes
could be positive. But it's a little early to talk about that now.
I was thinking we should maintain the code separation between the Flex
wrappers, and the core MadComponents/MC3D classes.
Re: Stage3D accelerated Flex components
Posted by Avi Kessner <ak...@gmail.com>.
Conceptually, I don't understand why you would want to have more than "just
a UI framework", if your goal is to make use of the GPU.
The fewer dependencies the better.
brought to you by the letters A, V, and I
and the number 47
On Mon, Jan 21, 2013 at 2:18 PM, Michael Schmalle
<ap...@teotigraphix.com>wrote:
> Interesting article and I have read quite a bit of what you have done in
> the past.
>
> I don't know if this is a translation thing but;
>
> "
> While I am willing to advise the Open Flex developers, and participate in
> discussions (time and other-commitments permitting), I am not willing to
> write the new Flex framework for them. I would expect the Open Flex group
> to put in the development work for this ? not me.
> "
>
> the above paragraph made me feel like I wanted to hit the back button when
> I got to it.
>
> BTW, I'm not married to the "Flex legacy" either and I am in this project
> because of the ActionScript language. Yes, I have read your thoughts about
> that as well.
>
> If your idea of a component framework was embraced by an abstract open
> source community, I don't think anybody would expect you to do anything, it
> seems like you are offering "consulting" services correct?
>
> If you were honest about adding advice it would be right on this list like
> we all do.
>
> Mike
>
>
>
>
> Quoting Daniel Freeman <ma...@gmail.com>:
>
> 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/<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.
>>
>>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
>
Re: Stage3D accelerated Flex components
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Quoting Daniel Freeman <ma...@gmail.com>:
> "I would expect the Open Flex group to put in the development work for this
> ? not me."...
>
> Let me clarify what I mean. It is my intention to port MadComponents/MC3D
> over to AS"next". This is quite an undertaking. Combined with the effort
> that I've already put into the framework, and the new GPU-enabled effects.
>
> To turn this into a Flex framework - all you'd need to do is write Flex
> wrappers. Along the lines of the examples that I demoed in 2011, but
> writing them in such a way as to maintain the familiar conventions of Flex
> in mxml. Also, tweaks to the MD3D classes to allow them to work within
> Flex. But most of the hard work will be already done. So this is a little
> more than free consultancy (although that in itself would have been
> generous).
>
This is my point, the consultancy thing was a joke. I understand you
believe in your framework and you're abilities, but your tone IMHO
needs a little work.
I am by no means speaking for any body but myself here but, what you
are saying doesn't seem to fit how opensource code has been "donated"
to projects that I have seen in the past. Are you offering the source
code to Apache? Or only parts? Or ideas?
It is unclear to me what you are actually being generous of.
You say write Flex wrappers, so that means we are dependent on
external code (that you own)?
Mike
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: Stage3D accelerated Flex components
Posted by Daniel Freeman <ma...@gmail.com>.
"I would expect the Open Flex group to put in the development work for this
? not me."...
Let me clarify what I mean. It is my intention to port MadComponents/MC3D
over to AS"next". This is quite an undertaking. Combined with the effort
that I've already put into the framework, and the new GPU-enabled effects.
To turn this into a Flex framework - all you'd need to do is write Flex
wrappers. Along the lines of the examples that I demoed in 2011, but
writing them in such a way as to maintain the familiar conventions of Flex
in mxml. Also, tweaks to the MD3D classes to allow them to work within
Flex. But most of the hard work will be already done. So this is a little
more than free consultancy (although that in itself would have been
generous).
Re: Stage3D accelerated Flex components
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Interesting article and I have read quite a bit of what you have done
in the past.
I don't know if this is a translation thing but;
"
While I am willing to advise the Open Flex developers, and participate
in discussions (time and other-commitments permitting), I am not
willing to write the new Flex framework for them. I would expect the
Open Flex group to put in the development work for this ? not me.
"
the above paragraph made me feel like I wanted to hit the back button
when I got to it.
BTW, I'm not married to the "Flex legacy" either and I am in this
project because of the ActionScript language. Yes, I have read your
thoughts about that as well.
If your idea of a component framework was embraced by an abstract open
source community, I don't think anybody would expect you to do
anything, it seems like you are offering "consulting" services correct?
If you were honest about adding advice it would be right on this list
like we all do.
Mike
Quoting Daniel Freeman <ma...@gmail.com>:
> 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.
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com