Sorry, yes. I was referring to the new roadmap.
http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html
I've blogged about the news here:
http://madskool.wordpress.com/2013/01/30/adobes-cut-price-roadmap-and-mc3dnext
@Kevin, I can accomplish miraculous graphics performance when I code
I believe he was referring to the cancelation of AVMNext (and AS4) and
FlashNext.
Kevin N.
On 1/30/13 4:08 AM, Frank Martin wrote:
Daniel, what current announcement are you referring to?
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 o
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
@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
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 ma
@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 subc
On Mon, Jan 21, 2013 at 3:30 AM, 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 MadCompo
No worries,
i can't even deduct that you Kevin Newman are not the author of
jacksondunstan.com!
hehe :-)
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,
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 alp
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. Wh
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, 2
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 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
On Mon, Jan 21, 2013 at 10:31 PM, Avi Kessner 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 impo
Quoting Daniel Freeman :
"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 th
"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-
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
wrote:
> Interes
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 commen
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
21 matches
Mail list logo
