Return-Path: X-Original-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-flex-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6C58FD732 for ; Fri, 30 Nov 2012 16:22:48 +0000 (UTC) Received: (qmail 91313 invoked by uid 500); 30 Nov 2012 16:22:47 -0000 Delivered-To: apmail-incubator-flex-dev-archive@incubator.apache.org Received: (qmail 91287 invoked by uid 500); 30 Nov 2012 16:22:47 -0000 Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: flex-dev@incubator.apache.org Delivered-To: mailing list flex-dev@incubator.apache.org Received: (qmail 91277 invoked by uid 99); 30 Nov 2012 16:22:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Nov 2012 16:22:46 +0000 X-ASF-Spam-Status: No, hits=-1.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of aharui@adobe.com designates 64.18.1.35 as permitted sender) Received: from [64.18.1.35] (HELO exprod6og115.obsmtp.com) (64.18.1.35) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Nov 2012 16:22:37 +0000 Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKULjdOIVhBLkfotfFvE2kRrhlc0k+coza@postini.com; Fri, 30 Nov 2012 08:22:17 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qAUGJO1v004408 for ; Fri, 30 Nov 2012 08:19:24 -0800 (PST) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qAUGLSXe012960 for ; Fri, 30 Nov 2012 08:22:14 -0800 (PST) Received: from NAMBX02.corp.adobe.com ([10.8.127.96]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Fri, 30 Nov 2012 08:21:43 -0800 From: Alex Harui To: "flex-dev@incubator.apache.org" Date: Fri, 30 Nov 2012 08:21:42 -0800 Subject: Re: [FalconJS] concepts Thread-Topic: [FalconJS] concepts Thread-Index: Ac3O5yPg2/DRJVXoQGqzA1HesuLjVQAL6RlX Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.13.0.120411 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Ah ok. Makes sense to me. We should certainly have support for vector drawing for those who need it. I'm still going to build the interactive widgets using as much of the nativ= e HTML/HTML5 controls as possible. Thanks, -Alex On 11/30/12 2:40 AM, "Frank Wienberg" wrote: > On Thu, Nov 29, 2012 at 6:29 PM, Alex Harui wrote: >=20 >>=20 >> On 11/29/12 3:31 AM, "Frank Wienberg" wrote: >>=20 >>> Primarily, I also map DOs to DOM elements! >>>=20 >>> Greetings >>> -Frank- >> Just curious, but how does this mapping work? How many DOM objects are >> being created and what does the drawing, SVG? >>=20 >> Usually only one DOM object, but that can be different in each > DisplayObject subclass. > The actual drawing (flash.display.Graphics) is always done through a canv= as > (which is, of course, also a DOM element!). Thus, in DOM-mode, a Sprite > consists of a
container with a for rendering and more DOM > elements for all contained child-DOs. > Because in typical gaming scenarios, this approach led to a lot of canvas= es > being created and turned out to be slow and memory-consuming, I implement= ed > a mode where a complete DisplayList-subtree (well, the thing called > DisplayList actually is a tree!) is rendered into a single canvas. This i= s > the approach taken by DartFlash and works extremely well for games and > animations where almost all DOs are graphics or simple text, but is not s= o > good for interactive components like TextField, where you would have to > emulate all the interactive behavior on a low-level basis (blinking curso= r > etc.). > Since it seems none of the two solutions is always preferable, I now let > the developer decide. Setting "cacheAsBitmap" to true on a DO-Container > activates canvas mode for that DL-subtree, but other parts of the DL can > still use DOM-mode, so you can mix-and-match graphics and interactive par= ts > of your UI. > Note however that the DOM-mode supports less Flash features and has sever= al > known bugs concerning scaling and rotation (it is really tough to map the= se > on CSS3 transforms and it turned out to be much easier when using canvas = 2D > API). It might even be that after the canvas-refactoring, DOM-mode work > worse than before... --=20 Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui