Empezando con AS3

Zárate

<div class="quote">
Athomix

<blockquote>Que cosas sabe Zárate</blockquote>
</div>

Que cosas lee Zárate : )

Ea!

Pues vas a tener que cambiarle el título a loqueyosede.com :D

Ventd'Aval

Buenas,

Habeis probado el BitmapData.dispose() ? en principio, y me consta, destruye el bmp, y libera la memoria ocupada...

Si, ahora, en la nueva versión del puzzle que estoy haciendo, recorto sólo el trozo de imagen que abarca la ficha y no se me llena tanto la RAM. Antes lo hacía a lo "bestia": duplicaba todo el Bitmap y lo enmascaraba; malos hábitos adquiridos tras tantos años de Flash :-)

Zárate

tpmmds, como advierte el post original, yo lo utilizaría con mucho cuidado. Puede que en una futura versión del player simplemente deje de funcionar (probable) o que provoque un crash total (menos probable).

Totalmente de acuerdo, como he comentado más arriba, tengo la sensación de que este truco lo descubrió un programador una noche de insomnio que estaba probando una LocalConnection entre dos swf's :-). Seguro!!!
Pero bueno, habrá que utilizarla para forzar la limpieza de la memoria en aquellas aplicaciones que la llenamos bastante, a la espera de que Adobe nos de una solución mejor. Y seguro que en la nueva actualización de Flash player deja de funcionar: tiene pinta de ser un bug ya que si quitas la segunda LocalConnection() del try/catch no se lanza el GC.
Un saludo.
P.D.: Perdonad mi mala redacción, escribo desde un portátil de hace 8 años, al que no le funcionan la mitad de las teclas.

Buenas,

Habeis probado el BitmapData.dispose() ? en principio, y me consta, destruye el bmp, y libera la memoria ocupada...

Por otro lado, y esto es solo con BitmapData, si excedes la capacidad de la ram, Flash ya no creara mas BitmapDatas, y la instancia evaluara falso (creo recordar, como cuando creas uno mayor a 2880 pixeles de ancho o alto)... podeis probar un onEnterFrame que vaya metiendo bmps grandes a un array...
Otro truquillo es no usar bmps transparentes cuando se pueda... estos ocupan casi el doble que los opacos ;)

Sobre los entornos de trabajo, uso Flash CS3 (btt hasta la polla, pero es q ademas diseño) y FlashDevelop para XMLs y clases (SI! toy haciendo alguna q otra clase de vez en cuando ^^), q mola mucho lo del ctrl+enter conectao al IDE :P

Saludos :)

Athomix

Que cosas sabe Zárate

Que cosas lee Zárate : )

De hecho cuando leí los artículos me cagué bastante porque pinta el escenario muy negro en plan: "hay que tener infinito cuidado o vamos a colgar los equipos de los usuarios".

Tiempo después parece que la Tierra sigue girando y que el desarrollo de AS3 no se ha vuelto un infierno. Aunque el otro día estaba haciendo mi primera aplicacioncilla y me di unos cuantos cabezazos ¬¬

Ea!

Pues eso, no hay cosa más estúpida que borrar una variable y que la borre cuando le salga de los coj.... :D

El garbage, que yo sepa, no te va a reescribir un código que sature de variables que no borras. Lo que hace es gestionar como se libera la memoria de las variables que precisamente si borras. (creo)

EDIT: Me veo al garbage collector como cabeza de turco para explicar problemas, como en su día lo fue el proxy cache:
Cliente: La pantalla muestra un undefined!
Desarrolador: Eso es que no se ha borrado el garbage.

Que cosas sabe Zárate.

Una vez hice una función en C que hacía un new variable con cada movimiento del mouse pero nunca un delete, en unos minutos quedaba colgado todo.

Pensaba que la misión del Garbage Collector era evitar este tipo de errores, no?

tpmmds, como advierte el post original, yo lo utilizaría con mucho cuidado. Puede que en una futura versión del player simplemente deje de funcionar (probable) o que provoque un crash total (menos probable).

Y yo creo que estos "encuentros casuales" vienen directamente desde Adobe cuando uno de los mega-frikis pregunta a alguien que conoce allí. Aunque puede ser mi vena conspiranoica : D

tpmmds

No es tan raro encontrar ordenadores con menos de 256KB de RAM, y esta cantidad de memoria se puede llenar ràpidamente con sólo poner a true el cacheAsBitmap de todos los movieClip que estemos utilizando.

Como dirían en IT Crowd "Are you from the past?"

(Es una coña :-) Entiendo que son Mb)

Zárate

<code>try {
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
} catch (e:*) {}
// the GC will perform a full mark/sweep on the second call.</code>

Acabo de probarlo y funciona, no me preguntéis por qué, pero funciona!!!! La curva de memoria disponible,de la que estamos hablando, parece ahora un encefalograma plano :-)))). Basta con llamar a este código después de eliminar las instancias que no deseemos y se lanza el GC, liberando memoria.
Un saludo, y de nuevo, muchas gracias :-)

[quote="Athomix"]Con la cantidad de memoria que tienen los ordenadores actuales me parece correcto que el GC la amortice, y no la limpie ni continua ni inmediatamente. Recuerdo mi Olivetti "portátil" con 640Kb de memoria. Quizás alguien debería recuperar el término "optimización del código" mejor que estar testeando System.TotalMemory.

[quote]

El problema, creo, no está en optimizar, o depurar el código al máximo: el GC no va a eliminar toda aquella "basura" que nos hallamos ido olvidando ;-), ya que sólo "recolecta" aquello que nosotros previamente hallamos eliminado con código. Se me ocurre un caso, no demasiado rebuscado que puede saturar el "sistema más pintado":
Imaginemos una aplicación en forma de revista interactiva que muestre páginas con abundantes fotografías y vídeos Flv. Nuestro avezado programador no ha escatimado en líneas de código y elimina las instancias de todos los elementos gráficos de las páginas que ya ha visto el usuario. Si el GC se lanza cada minuto y limpia la RAM, os puedo asegurar que he visto "usuarios" capaces de verse un libro virtual entero en menos de 1 minuto.
Un saludo, y esto es hablar por no estar callado ;-)

Zárate

<code>try {
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
} catch (e:*) {}
// the GC will perform a full mark/sweep on the second call.</code>

Y si se puede hacer, por qué no lo permite Adobe de forma oficial? Pues yo diría que su filosofía es:

- Tú programa sin memory leaks.
- Nuestro GC sabe muy bien lo que hacer y hará su trabajo.
- No tenemos bugs : )

Da la impresión de ser un "hallazgo" de un programador, que probando un try/catch, escribió dos veces una conexión local y... sorpresa... descubrió que se lanzaba el GC. No he tenido tiempo de probarlo, pero será lo primero que haga cuando me siente delante de Flex (y no me refiero al colchón). Si realmente provoca una activación del GC, ¡¡¡bienvenido sea!!!, muchas gracias por la información.
Un saludo.

elSuricatoRojo

tpmmds, al margen de que esté consumiendo mas memoria, ¿tu has visto que el rendimiento se vea afectado de cara a la experiencia de usuario (en caida de fps por ejemplo)?

En la mayoría de aplicaciones no se va a notar, por eso Adobe no se ha tomado mucho interés en optimizar el GC. Pero aquellas que cargan en memoria mucho contenido gráfico sí pueden llegar a saturar el sistema. No es tan raro encontrar ordenadores con menos de 256KB de RAM, y esta cantidad de memoria se puede llenar ràpidamente con sólo poner a true el cacheAsBitmap de todos los movieClip que estemos utilizando.
Además, cuando aplicamos un filtro (como el sombreado, que tan popular se está haciendo últimamente: no hay interactivo en Flash que se precie que no lleve al menos un sombreado :-)), el sistema se encarga de poner cacheAsBitmap = true por nosotros.
Por otro lado, es que soy muy "perro", si hubiera recortado el bitmap antes de enmascarar cada pieza del puzzle, ocuparía menos RAM y ni me hubiera enterado de lo poco eficiente que es el GC ;-).
Por cierto, en aplicaciones que llevan vídeo Flv incorporado (que no lo leen o hacen streaming), también he notado una cierta tendencia al embotamiento de la RAM.
Un saludo.

Flex Builder: AS3, MXML, debugger, autoimport, autocompletion, memory &amp; performance profiler (versión pro), vista de diseño, editor CSS...

http://www.onflex.org/ted/2007/09/flex-3-beta-2-code-debug-profiler.php
http://www.onflex.org/ted/2007/09/flex-3-beta-2-design-tools-learning.php
http://www.onflex.org/ted/2007/09/flex-3beta-2-crud-wizard-for-aspnet-php.php

A mi parecer bastante más completo en general que FDT 3, que ha tardado demasiado en ver la luz, y te lo dice uno que era defensor acérrimo del FDT para AS2

Llevo usando Flex Builder 2 desde enero, y la beta 2 de FB3 desde que salió, y no hacen más que mejorarlo.

En cuanto al garbage collector, hay que asegurarse que el número de referencias a los objetos que queremos eliminar sea cero, o que todas las referencias que quedan hacia él sean débiles (weak), sino no se borrarán nunca. Un tipo de referencias que no suele borrarse es el de los oyentes de eventos (listeners), por eso en ciertas ocasiones es recomendable usar una referencia débil al objeto que genera el evento, usando el último parámetro del addEventListener.

Con la cantidad de memoria que tienen los ordenadores actuales me parece correcto que el GC la amortice, y no la limpie ni continua ni inmediatamente. Recuerdo mi Olivetti "portátil" con 640Kb de memoria. Quizás alguien debería recuperar el término "optimización del código" mejor que estar testeando System.TotalMemory.

El problema real es si al usuario le afecta o no esta limpieza aleatoria, como, cuando y porqué. Es así?

Por otro lado no he visto nunca un código entero sin bugs, o inmejorable, así que esa crítica a Adobe no me parece tan razonable como otras. Sobretodo cuando a demasiados programadores lamentablemente les importa poco que un ordenador se quede colgado por una aplicación mal programada ("mientras sea bonita..."). Los "dead lines" tienen gran parte de la culpa. :D Así que, les das libertad total o intentas proteger el entorno de programación?

El código perfecto es como el crimen perfecto, todos hablan de él pero nadie sabe como es realmente :)

PD: npi de cuantas letras tiene este post :D ni de su interés o utilidad.

Zárate

<div class="quote">
ozke

<blockquote>Pq lo tienes desabilitado?</blockquote>
</div>

Pues un poco por manía. El otro poco es que juntado con el autocompletar tan agresivo que tiene, acababa importando clases sin darme cuenta.

Y para finalizar, un poco de histeria que paso a relatar aunque alguno diga que parezco Rainman contando cartas. Tengo la manía de importar las clases en cierto orden, me ayuda a ver rápidamente qué estoy utilizando.

- Primero todos los imports de clases de terceros. Por ejemplo XPath, GDispatcher y similares
- Luego todas mis clases que NO son del proyecto. Me refiero a clases comunes, normalmente las guardo en Utils.*
- Por último, todas las clases pertenecientes al proyecto en el que estoy currando.

Evidentemente hay una línea en blanco entre cada una de esas "zonas".

Por cierto, hay 346 letras en este post.

: D

No me parece nada raro tío.
Lo único es que mi orden es:
- "Normales"
- "Generales propias"
- "Del proyecto"

Lo de poner las letras del post ya si q me parece friki por eso jajaja

Sobre lo de forzar el GC mr Grant Skinner debe tener soplones en Adobe, mirad lo que cuenta en Resource Management 3:

<fieldset>This trick can be really handy for exploring Garbage Collection, and testing your applications during development, but it should never be deployed in production code because it can wreak havoc with processor load. It is also officially unsupported, so you cannot rely on it to work in updated versions of the player.</fieldset>

<code>try {
new LocalConnection().connect('foo');
new LocalConnection().connect('foo');
} catch (e:*) {}
// the GC will perform a full mark/sweep on the second call.</code>

Y si se puede hacer, por qué no lo permite Adobe de forma oficial? Pues yo diría que su filosofía es:

- Tú programa sin memory leaks.
- Nuestro GC sabe muy bien lo que hacer y hará su trabajo.
- No tenemos bugs : )

Si yo tuviera que utilizar esto, lo encapsularía dentro de un método estático, algo como:

<code>class GCUtils{

public static function ForceGC():Void{
// codigo
}

}</code>

Lo digo porque al ser código no oficial, si manyana deja de funcionar o si pasa a oficial, no hay que andar buscando por todo el código, sólo hay que modificarlo en una clase.

Salud!

Por lo que he leido yo en Moock no puedes forzar que se limpie el garbage collector y será el propio player cuando vea que se está consumiendo mucha memoria quien tomará la iniciativa de borralo.

Eso en teoría implica que no deberíamos preocuparnos por no tener control sobre el garbage... pero claro eso solo en teoría.

tpmmds, al margen de que esté consumiendo mas memoria, ¿tu has visto que el rendimiento se vea afectado de cara a la experiencia de usuario (en caida de fps por ejemplo)?

Con el garbage collector de AS3 (o más concretamente, de Flash player 9) ya he tenido algún que otro "roce". Como dice el artículo que citas, la limpieza de las instancias que se han borrado se produce en un futuro próximo, o lejano, pero incierto :-)).
He desarrollado un pequeño juego de puzzle en Flex y creo las piezas con la clase Bitmap, que permite copiar en memoria trozos de una imagen cargada. Cuando genero un nuevo puzzle elimino las piezas del anterior y, en teoría, las piezas antiguas deben desaparecer y liberar la memoria que ocupaban.
El puzzle ( y todo el código fuente, realizado en Flex) lo podéis encontrar aqui:

http://blog.coconnut.com/source/jel/puzzle/

Para comprobar cómo actúa el garbage collector de FP9 basta abrir el Administrador de tareas de Windows (Control Alt Supr) y mostrar la pestaña Rendimiento, a la vez que se van generando puzzles (pulsa el botón "Jugar" de la aplicacion). Verás cómo la memoria no se libera casi nunca cuando pulsas el botón Jugar (es en este momento cuando se eliminan, en teoría, las antiguas piezas), y puede ocurrir que generes varios puzzles sin que el garbage collector libere memoria.
Debería existir alguna forma de "forzar" la limpieza de memoria, sobre todo en aquellas aplicaciones que hacen un uso intensivo de ellas ;-).

ozke

Pq lo tienes desabilitado?

Pues un poco por manía. El otro poco es que juntado con el autocompletar tan agresivo que tiene, acababa importando clases sin darme cuenta.

Y para finalizar, un poco de histeria que paso a relatar aunque alguno diga que parezco Rainman contando cartas. Tengo la manía de importar las clases en cierto orden, me ayuda a ver rápidamente qué estoy utilizando.

- Primero todos los imports de clases de terceros. Por ejemplo XPath, GDispatcher y similares
- Luego todas mis clases que NO son del proyecto. Me refiero a clases comunes, normalmente las guardo en Utils.*
- Por último, todas las clases pertenecientes al proyecto en el que estoy currando.

Evidentemente hay una línea en blanco entre cada una de esas "zonas".

Por cierto, hay 346 letras en este post.

: D

Pues yo el IDE del Flash CS3 como los valientes (o tontos! pero principalmente como los vagos que les da pereza aprenderse otro programa o ir cambiendo entre 2). Eso si, lo inteto tunear un poco con Comandos y tiro mucho de "shortcuts" (cuanta gente sabe que si haces ctrl+f+n se te crea "function(){}?").

Pq lo tienes desabilitado?

FDT &gt; sólo si te gusta Eclipse y pagas la licencia.
FlashDevelop &gt; va bien, y tiene un "auto-import" que yo por cierto deshabilito. Sólo Win ¬¬
Flash IDE &gt; Nunca mais : )

Bueno, a ver si retomo el tema.

Q editor debería usar? (Q usais vosotros?)
- Flash CS3 IDE
- Flex 2 SDK
- FDT
- otro

Básicamente quiero ponerme lo antes posible con AS3 y m molaria 2 cosas:
1) Q los miles de imports se hagan de forma automatica
2) Autocomplementado de codigo como con SEPY + o -
3) Es posible exportar ctrl+intro? (pijada)

Gracias por adelantado :)

ivanv

'Actionscript 3.0 para desarolladores Flash' no es de Collin Moock...
http://www.agapea.com/ActionScript-3-0-para-desarrolladores-Flash-n659547i.htm
sino pondría su nombre en autores...

Si, antes me he equivocado en eso. En cualquier caso... precisamente por no ser el de Moock es el Cookbook y no el Essentials como comentaba. :)

'Actionscript 3.0 para desarolladores Flash' no es de Collin Moock...
http://www.agapea.com/ActionScript-3-0-para-desarrolladores-Flash-n659547i.htm
sino pondría su nombre en autores...

Se agradece Caracool... :)

A ver si nos ponemos manos a la obra. Asi a primera vista, si que parece interesante, si.

Caracool

Algunos colegas de curro hemos abierto un blog con ejemplos y demás material para Flex y AS3 que creo os puede resultar interesante. Podéis visitarlo en http://blog.coconnut.com

Algunos colegas de curro hemos abierto un blog con ejemplos y demás material para Flex y AS3 que creo os puede resultar interesante. Podéis visitarlo en http://blog.coconnut.com

Ah! ¡Ostis! :)

Yo pensaba que el que habia salido a la venta era el Essentials. Es decir que es el "Cookbook": pues no tenia ni puñetera idea. :( Estaba convencido de que era el otro.

Pido disculpas... Me temo, entonces, que habra que esperar. ;)

ozke

Hey erni ;)

El que él dice también es de Moock.
El problema es que el que se ha publicado en España como "para desarrolladores Flash" es en realidad prácticamente calcado al "Cookbook" inglés (mismo animal en portada y creo q todo exactamente ¡ salvo el primer capítulo xD).

Creo que el que Hartum reclama es el básico. El que aquí es "Essentials", como el de AS2.

¿Voy bien encaminado?