NekroAyuda: Optimizar aplicaciones I: Buscar el rendimiento y la compatibilidad
NekroByte:
Optimizar la velocidad
percibida
Suele ocurrir que la velocidad subjetiva de su aplicación tiene poco que ver
con la rapidez de ejecución del código. Para el usuario, una aplicación que se
inicie con rapidez, se dibuje con rapidez y proporcione mensajes de forma
continua da la sensación de ser más "garbosa" que una aplicación que se queda
"parada" mientras hace su trabajo. Puede usar una gama variada de técnicas para
aportar dicho "garbo" a su aplicación:
Mantener los formularios ocultos pero cargados.Cargar los datos previamente.Usar cronómetros para trabajar en segundo plano.Usar indicadores de progreso.Acelerar el inicio de la aplicación.
Mantener los formularios ocultos pero cargados
Ocultar los formularios en lugar de descargarlos es un truco que viene de las
primeras épocas de Visual Basic 1.0, pero sigue siendo efectivo. El
inconveniente obvio de esta técnica es la cantidad de memoria que consumen los
formularios cargados, pero puede desestimarlo si puede permitirse el gasto en
memoria, ya que hacer que los formularios aparezcan con rapidez es de la máxima
importancia.
Cargar los datos previamente
También puede mejorar la velocidad aparente de la aplicación si carga los
datos previamente. Por ejemplo, si necesita ir al disco a cargar el primero de
varios archivos, ¿por qué no cargar todos los que pueda? A menos que los
archivos sean extremadamente pequeños, el usuario advertirá el retraso de todos
modos. Probablemente, el incremento del tiempo empleado en la carga de los
archivos adicionales pasará inadvertido y, además, no tendrá que hacer esperar
al usuario otra vez.
Usar cronómetros para trabajar en segundo plano
En algunas aplicaciones se puede realizar una cantidad considerable de
trabajo mientras se espera al usuario. La mejor manera de hacerlo es mediante un
control Timer. Utilice variables estáticas (o de nivel de módulo) para
hacer un seguimiento del progreso y ejecute una pequeña parte del trabajo cada
vez que salte el cronómetro. Si hace que la cantidad de trabajo realizado entre
cada evento del cronómetro sea muy pequeña, los usuarios no verán efecto alguno
sobre la respuesta de la aplicación y podrá cargar datos o efectuar otras tareas
que aceleren aún más la velocidad de su aplicación.
Para obtener más información Para aprender más
acerca del control temporizador, vea "Usar el control Timer" en "Usar los
controles estándar de Visual Basic". Para obtener la descripción del proceso en
segundo plano, vea "Interrumpir el procesamiento en segundo plano" en "Responder
a los eventos del mouse y del teclado".
Usar indicadores de progreso
Cuando no pueda evitar una larga espera en el programa, tiene que ofrecer al
usuario alguna indicación de que la aplicación no se ha quedado bloqueada.
Windows 95 utiliza una barra de progreso estándar para indicar esto a los
usuarios. Puede usar el control ProgressBar de los Controles comunes de
Microsoft Windows incluidos en la Edición Profesional y en la Edición
Empresarial de Visual Basic. Utilice DoEvents en los puntos estratégicos,
especialmente cada vez que actualice el valor del control ProgressBar,
para permitir que la aplicación dibuje mientras el usuario hace otras cosas.
Como mínimo admisible, debe presentar el cursor para indicar la espera
mediante el valor vbHourglass (11) de la propiedad MousePointer
del formulario (11).
Acelerar el inicio de la aplicación
La velocidad aparente tiene la máxima importancia cuando se inicia su
aplicación. La primera impresión de los usuarios sobre la velocidad de una
aplicación se mide por la rapidez con la que pueden hacer algo después de
seleccionar el nombre de la aplicación en el menú Inicio. Con las
diversas DLL de tiempo de ejecución que tienen que cargarse para Visual Basic
para aplicaciones, los controles ActiveX y todo lo demás, es inevitable un
pequeño retraso en cualquier aplicación. Sin embargo, puede hacer varias cosas
para dar respuesta al usuario de la forma más rápida posible:
Usar Show en el evento Form_Load.Simplificar el formulario inicial.No cargar los módulos que no necesite.Ejecutar una pequeña aplicación de Visual Basic al iniciar para cargar
previamente los archivos DLL de tiempo de ejecución.
Usar Show en el evento Form_Load
Cuando un formulario se carga por primera vez, todo el código del evento
Form_Load se ejecuta antes de presentar el formulario. Puede alterar este
comportamiento si utiliza el método Show en el evento Form_Load para
ofrecer al usuario algo que mirar mientras se ejecuta el resto del código del
evento. Siga al método Show con DoEvents para asegurar que se
dibuja el formulario:
Código:
Sub Form_Load()
Me.Show ' Presenta el formulario inicial.
DoEvents ' Asegura que se dibuja el
' formulario inicial.
Load MainForm ' Carga el formulario principal.
Unload Me ' Descarga el formulario inicial.
MainForm.Show ' Presenta el formulario principal.
End Sub
Simplificar el formulario inicial
Cuanto más complicado es un formulario, más tiempo necesita para cargarse.
Simplifique su formulario inicial. La mayor parte de las aplicaciones para
Microsoft Windows presentan al iniciarse una pantalla de copyright sencilla
(también conocida como pantalla de bienvenida); su aplicación puede hacer lo
mismo. Cuantos menos controles y cuanto menos código contiene el formulario
inicial, más rápido se cargará y aparecerá. Incluso aunque cargue otro más
complicado inmediatamente, el usuario sabrá que la aplicación se ha
iniciado.
En las aplicaciones grandes puede que le interese cargar previamente en el
inicio los formularios utilizados con mayor frecuencia para mostrarlos
instantáneamente cuando sea necesario. Una manera satisfactoria de hacer esto es
presentar una barra de progreso en el formulario inicial y actualizarla al
cargar cada uno de los demás formularios. Llame a DoEvents después de
cargar cada formulario para volver a dibujar el formulario inicial. En cuanto se
han cargado todos los formularios importantes, el formulario inicial puede
presentar el primero y descargarse a sí mismo. Por supuesto, cada formulario que
cargue ejecutará el código de su evento Form_Load, de modo que preste atención
para que esto no provoque problemas o retrasos excesivos.
No cargar los módulos que no necesite
Visual Basic carga los módulos de código cuando se solicita, en lugar de
todos a la vez al iniciar. Esto significa que si nunca llama a un procedimiento
de un módulo, ese módulo no se cargará nunca. Por el contrario, si el formulario
inicial llama a procedimientos de varios módulos, todos estos módulos se
cargarán mientras se inicia la aplicación, lo que la retrasa. Por tanto, debe
evitar llamar a procedimientos de otros módulos desde el formulario inicial.
Ejecutar una pequeña aplicación de Visual Basic al iniciar para cargar los
archivos DLL de tiempo de ejecución
Gran parte del tiempo que se requiere para iniciar una aplicación de Visual
Basic se emplea en cargar los archivos DLL de tiempo de ejecución para Visual
Basic, ActiveX y los controles ActiveX. Desde luego, si estos ya estuvieran
cargados, no se emplearía tanto tiempo. De esta forma los usuarios verán que la
aplicación se inicia con más rapidez si ya se está ejecutando otra aplicación
que utiliza alguna o todas estas DLL.
Una forma de aumentar el rendimiento inicial de las aplicaciones de forma
significativa es proporcionar otra pequeña aplicación que se ejecute siempre.
Por ejemplo, puede escribir una pequeña aplicación para presentar un calendario
e instalarla en el grupo Inicio de Windows. De este modo, se cargará
automáticamente al iniciar el sistema y, además de ser útil por sí misma,
asegura que se carguen las diversas DLL de tiempo ejecución de Visual Basic.
Finalmente, con la Edición Profesional y la Edición Empresarial de Visual
Basic puede dividir su aplicación en un esqueleto de aplicación principal y
varios componentes ejecutables o varias DLL. Una aplicación principal pequeña se
cargará con más rapidez y después podrá cargar las otras partes cuando las
necesite.
NekroByte:
Medir el rendimiento
Determinar qué algoritmo es el mejor para una situación dada no es siempre
obvio. Algunas veces necesitará comprobar sus hipótesis; esto puede hacerse
fácilmente creando una aplicación sencilla para medir el rendimiento, como la
mostrada a continuación. La aplicación de ejemplo Optimize.vbp también contiene
ejemplos de distintos escenarios de prueba.
Para crear una aplicación de prueba de rendimiento
Abra un nuevo proyecto .exe.Cree un formulario con dos botones de comando: Command1 y Command2.En el evento Command1_Click, agregue el código siguiente:
Código:
Private Sub Command1_Click()
Dim dblStart As Double
Dim dblEnd As Double
Dim i as Long
dblStart = Timer ' Hora de inicio.
For i = 0 To 9999
»Rutina para probar« ' Escriba su rutina aquí.
Next
dblEnd = Timer ' Hora de terminación.
Debug.Print dblEnd - dblStart ' Presenta el
' tiempo
' transcurrido.
End Sub
[li]Agregue el mismo código al evento Command2_Click, pero utilice la segunda
versión de su rutina en el bucle.[/li]
[li]Ejecute la aplicación y siga los resultados en la ventana Inmediato.
[/li][/list]
Este ejemplo utiliza la propiedad predeterminada de la clase Timer de
Visual Basic para medir el tiempo de ejecución de la rutina dentro del bucle. Al
colocar el código dentro del bucle de cada botón de comando, puede comparar
rápidamente el rendimiento de los dos algoritmos. El código puede estar dentro
del bucle o puede ser una llamada a otros procedimientos.
Puede que tenga que experimentar con valores diferentes en los límites
superiores del contador del bucle, especialmente en las rutinas rápidas.
Asegúrese de ejecutar cada versión varias veces para obtener un promedio; los
resultados pueden variar entre una ejecución y otra.
También puede optimizar su aplicación si incrementa la velocidad de acceso a
los datos.
NekroByte:
Optimizar el Tamaño
En el pasado, la memoria disponible y los recursos del sistema solían ser factores restrictivos en el diseño de una aplicación. En los sistema operativos de 32 bits, como Windows 95 y Windows NT, estos factores raramente suponen una preocupación para la mayoría de los programadores de Visual Basic. Sin embargo, hay varios escenarios en los que sigue siendo importante minimizar el tamaño de una aplicación.
El tamaño es extremadamente importante en las aplicaciones que se cargan desde Internet o se transfieren como adjuntos de correo electrónico. Para los poco afortunados que no tienen conexiones de datos de alta velocidad, la transferencia de un archivo de 1 megabyte podría durar una hora o más. Además del archivo .exe, muchas aplicaciones requieren archivos .dll y .ocx adicionales, lo que incrementa el tamaño (y el tiempo) de la transferencia. En estos escenarios, le interesa optimizar el tamaño en disco de las aplicaciones.
Incluso si los usuarios no van a transferir su aplicación, siempre conviene hacer que una aplicación sea lo más compacta posible. Las aplicaciones pequeñas se cargan con mayor rapidez y como consumen menos memoria, puede ejecutar otras aplicaciones al mismo tiempo. A menudo puede mejorar el rendimiento si optimiza el tamaño de la aplicación en la memoria.
NekroByte:
Reducir el tamaño del código
Cuando es importante reducir el tamaño de una aplicación, hay varias técnicas
que puede aplicar para hacer que el código sea más compacto. Además de reducir
el tamaño de la aplicación en memoria, la mayor parte de estas optimizaciones
también reducirán el tamaño del archivo .exe. Como ventaja adicional, las
aplicaciones pequeñas se cargarán con mayor rapidez.
La mayoría de las técnicas de optimización del tamaño consisten en eliminar
elementos innecesarios del código. Visual Basic elimina automáticamente ciertos
elementos cuando compila la aplicación. No hay razones para restringir la
longitud o el número de los siguientes elementos:
IdentificadoresComentariosLíneas en blanco
Ninguno de estos elementos afecta al tamaño de la aplicación en memoria
cuando se ejecuta como archivo .exe.
Otros elementos, como las variables, los formularios y los procedimientos,
ocupan espacio en memoria. Normalmente, lo mejor es refinar en esta dirección.
Puede usar varias técnicas para reducir la memoria que ocupa la aplicación
cuando se ejecuta como archivo .exe. Las siguientes técnicas pueden reducir el
tamaño del código:
Reducir el número de formularios cargados.Reducir el número de controles.Usar etiquetas en lugar de cuadros de texto.Guardar datos en archivos de disco o en otros recursos y cargarlos sólo
cuando sean necesarios.Organizar los módulos.Considerar alternativas al tipo de datos Variant.Usar matrices dinámicas y borrarlas para liberar memoria.Liberar el espacio utilizado por las cadenas o por las variables de
objeto.Eliminar el código inservible y las variables que no se utilizan.
Reducir el número de formularios cargados
Cada formulario cargado, ya sea visible o no, consume una gran cantidad de
memoria (que varía con el número y el tipo de controles del formulario, el
tamaño de los mapas de bits del formulario, etc.). Sólo cargue los formularios
cuando necesite presentarlos y descárguelos (en vez de ocultarlos) cuando ya no
los necesite. Recuerde que cualquier referencia a las propiedades, los métodos o
los controles de un formulario, o una variable del formulario declarada como
New, hace que Visual Basic lo cargue.
Cuando descarga un formulario mediante el método Unload, sólo se
libera una parte de la memoria ocupada por el formulario. Para liberar toda la
memoria, invalide la referencia al formulario mediante la palabra clave
Nothing:
Código:
Set Form = Nothing
Reducir el número de controles
Cuando diseña una aplicación, procure usar el mínimo número de controles
posible en los formularios. El límite real depende del tipo de controles y del
sistema disponible, pero en la práctica, los formularios con un gran número de
controles funcionan con lentitud. Una técnica relacionada consiste en usar
matrices de controles siempre que sea posible, en lugar de colocar un gran
número de controles del mismo tipo en el formulario en tiempo de diseño.
Para obtener más información Para aprender más
acerca de las matrices de controles, vea "Trabajar con matrices de controles" en
"Usar los controles estándar de Visual Basic".
Usar etiquetas en lugar de cuadros de texto
Los controles Label utilizan menos recursos de Windows que los cuadros
de texto, por lo que debe usar etiquetas en lugar de cuadros de texto siempre
que sea posible. Por ejemplo, si necesita un control oculto en un formulario
para almacenar texto, es más eficiente usar una etiqueta.
Esta técnica permite optimizar hasta un formulario de entrada de datos que
necesita numerosos campos de texto. Puede crear una etiqueta para cada campo y
usar un único campo de texto para la entrada de campos, desplazándolo hasta la
posición del control Label siguiente en el evento LostFocus:
Código:
Private Sub Label1_LostFocus()
' Actualiza Label1
Label1.Caption = Text1.Text
' Desplaza el control Textbox encima de la etiqueta siguiente
Text1.Move Label2.Left, Label2.Top
' Actualiza el contenido de Text1
Text1.Text = Label2.Caption
End Sub
Puede hacer que una etiqueta se parezca a un cuadro de texto al establecer
las propiedades BackColor y BorderStyle. Aunque este técnica
necesita más código, puede reducir de significativamente el uso de los recursos
de un formulario que contiene numerosos campos.
Guardar datos en archivos de disco o en otros recursos y cargarlos sólo
cuando sean necesarios
Los datos colocados directamente en la aplicación en tiempo de diseño (como
propiedades o como cadenas literales y números dentro del código) aumentan la
cantidad de memoria consumida por la aplicación en tiempo de ejecución. Puede
reducir la memoria necesaria si carga los datos desde archivos de disco o desde
recursos en tiempo de ejecución. Esto es especialmente útil para los mapas de
bits y las cadenas de gran tamaño.
Organizar los módulos
Visual Basic carga los módulos cuando se solicita; es decir, carga un módulo
en memoria solamente cuando el código llama a uno de los procedimientos de ese
módulo. Si nunca llama a un procedimiento de un módulo determinado, Visual Basic
nunca carga dicho módulo. Reunir todos los procedimientos relacionados en el
mismo módulo hace que Visual Basic sólo cargue los módulos cuando son
necesarios.
Considerar alternativas al tipo de datos Variant
El tipo de datos Variant es extremadamente flexible, pero también es mayor en
tamaño que cualquier otro tipo de datos. Cuando tenga que reducir hasta el
último byte de la aplicación, considere la posibilidad de sustituir las
variables Variant, y especialmente las matrices de variables Variant, por otro
tipos de datos.
Cada Variant ocupa 16 bytes, comparado con los 2 bytes de un Integer u 8
bytes de un Double. Las variables String de longitud variable utilizan 4 bytes
más 1 byte por cada carácter de la cadena, pero cada Variant que contiene una
cadena ocupa 16 bytes más 1 byte por cada carácter de la cadena. Como ocupan
tanto, las variables Variant son especialmente problemáticas cuando se utilizan
como variables locales o como argumentos de procedimientos, ya que consumen
rápidamente el espacio de la pila.
Sin embargo, en algunos casos la utilización de otros tipos de datos le
obliga a agregar más código para compensar la pérdida de flexibilidad que
proporciona el tipo de datos Variant, lo que no aporta una reducción neta de
tamaño.
Usar matrices dinámicas y borrado para liberar memoria
Piense en usar matrices dinámicas en lugar de matrices fijas. Cuando ya no
necesite los datos de una matriz dinámica, utilice Erase o ReDim
Preserve para descargar los datos innecesarios y liberar la memoria
utilizada por la matriz. Por ejemplo, con el siguiente código puede liberar el
espacio utilizado por una matriz dinámica:
Código:
Erase MiMatriz
Mientras Erase elimina completamente la matriz, ReDim Preserve
reduce su tamaño sin perder el contenido:
Código:
ReDim Preserve MiMatriz(10, smallernum)
Borrar una matriz de tamaño fijo no libera la memoria ocupada por la matriz,
sino que simplemente borra los valores de los elementos de la matriz. Si los
elementos eran una cadena o variables Variant que contenían cadenas o matrices,
borrar la matriz libera la memoria de esas cadenas o esas variables, no la
memoria ocupada por la matriz.
Liberar el espacio utilizado por las cadenas o por las variables de
objeto
El espacio utilizado por las variables de cadena y de matriz locales (no
estáticas) se libera de forma automática cuando termina el procedimiento. Sin
embargo, las variables de cadena y de matriz globales y de módulo siguen
existiendo durante toda la ejecución del programa. Si intenta mantener la
aplicación con el mínimo tamaño posible, debe liberar el espacio utilizado por
esas variables tan pronto como pueda. Puede liberar el espacio de las cadenas
asignándole cadenas de longitud cero:
Código:
SomeStringVar = "" ' Libera el espacio ocupado.
De forma similar, puede liberar parte del espacio (pero no todo) utilizado
por una variable de objeto estableciéndola a Nothing. Por ejemplo, para
quitar una variable de objeto Recordset:
Código:
Private rs As New RecordSet
… ' Aquí viene código para inicializar y usar un recordset
rs.Close ' Cierra el recordset
Set rs = Nothing ' Establece la referencia al objeto a Nothing
Si no ha establecido explícitamente la referencia del objeto a Nothing,
permanecerá su referencia en memoria hasta que la aplicación termine; para una
aplicación que utiliza muchos objetos podría consumir la memoria disponible y
bajar el rendimiento de la aplicación.
Puede también recuperar el espacio mediante la descarga de formularios y
estableciéndolos a Nothing en lugar de ocultarlos cuando no se necesiten
más.
Eliminación del código inservible y las variables que no se utilizan
Al desarrollar y modificar las aplicaciones, puede dejar código
inservible; es decir, procedimientos enteros a los que no se llama desde
ninguna parte del código. También puede haber variables declaradas que
después no se utilizan. Aunque Visual Basic quita las constantes que no se
utilizan, no quita las variables que no se utilizan ni el código inservible
cuando crea un .exe. No olvide repasar el código para buscar y quitar
los procedimientos y las variables que no se utilicen. Por ejemplo, las
instrucciones Debug.Print, aunque se pasan por alto en tiempo de
ejecución, se encuentran presentes en el archivo .exe.
Las instrucciones Debug.Print con cadenas o variables como argumentos
no se compilan cuando se crea un .exe. Sin embargo, cuando las instrucciones
Debug.Print tienen una llamada a una función como argumento, el
compilador ignora la instrucción Debug.Print, pero la llamada a la
función se compila. Más tarde, cuando se ejecuta la aplicación, se llama a la
función pero se pasa por alto su resultado. Como las funciones que aparecen como
argumentos de Debug.Print ocupan espacio y tiempo de CPU, puede ser
conveniente eliminar estas instrucciones antes de generar un .exe.
Utilice el comando Buscar del menú Edición para buscar
referencias a una variable concreta. Si tiene instrucciones Option
Explicit en todos los módulos, puede determinar cuándo la aplicación utiliza
una variable si la quita o si pone como comentario su declaración y ejecuta
después la aplicación. Si se utiliza la variable, Visual Basic generará un
error. Si no recibe ningún error, la variable no se usará.
Para obtener más información Para aprender más
acerca de la instrucción Debug.Print, vea "Imprimir información en la
ventana Inmediato" en "Depurar el código y tratar errores".
NekroByte:
Recortar los gráficos
Los gráficos (las imágenes y los métodos gráficos) pueden consumir una gran
cantidad de memoria. En cierto modo es inevitable: los gráficos contienen mucha
información y suelen ser grandes. Pero en muchos casos puede reducir el impacto
de los gráficos sobre el tamaño de la aplicación si emplea alguna de las
técnicas siguientes:
Usar el control Image para presentar mapas de bits.Cargar los mapas de bits desde archivos cuando sean necesarios y compartir
imágenes.Usar el método PaintPicture.Liberar la memoria utilizada por los gráficos.Usar mapas de bits en formato .rle o metarchivos.
Usar el control Image para presentar mapas de bits
Los controles Picture de muchas aplicaciones de Visual Basic sólo
existen para hacer clic en ellos o para arrastrarlos y colocarlos. Si esto es
todo lo que va a hacer con un control Picture, está malgastando muchos
recursos de Windows. Para estos mismos propósitos, los controles Image
son mejores que los controles Picture. Cada control Picture es una
ventana real y utiliza bastantes recursos del sistema. El control Image
es un control "ligero", no una ventana, y no utiliza tantos recursos. De hecho,
normalmente puede usar entre cinco y diez controles Image por cada
control Picture. Además, los controles Image se dibujan más rápido
que los controles Picture. Utilice los controles Picture
únicamente cuando necesite alguna de las características que sólo estos
proporcionan, como el intercambio dinámico de datos (DDE), los métodos gráficos
o la posibilidad de contener otros controles.
Cargar los mapas de bits desde archivos cuando sean necesarios y compartir
imágenes
Cuando establece una propiedad Picture en tiempo de diseño, agrega la
imagen al formulario e incrementa la memoria consumida por el formulario en
tiempo de ejecución. Puede reducir el consumo de memoria si almacena las
imágenes en un archivo de recursos y utiliza la función LoadResPicture
para cargarlos en tiempo de ejecución. Si nunca utiliza todas las imágenes
asociadas con un formulario al mismo tiempo, esta técnica ahorra memoria en
comparación con la de almacenar todas las imágenes en los controles del
formulario. Puede acelerar la velocidad de carga del formulario porque no todas
las imágenes tienen que cargarse antes de presentar el formulario.
Puede compartir la misma imagen entre varios controles Picture,
controles Image y formularios. Si utiliza código de este tipo,
sólo mantiene una copia de la imagen:
Código:
Picture = LoadPicture("C:\Windows\Chess.bmp")
Image1.Picture = Picture ' Utiliza la misma imagen.
Picture1.Picture = Picture ' Utiliza la misma imagen.
Contraste lo anterior con el siguiente código, que hace cargar tres
mapas de bits y, por tanto, necesita más memoria y más tiempo:
Código:
Picture = LoadPicture("C:\Windows\Chess.bmp")
Image1.Picture = LoadPicture("C:\Windows\Chess.bmp")
Picture1.Picture = LoadPicture("C:\Windows\Chess.bmp")
De forma similar, si carga la misma imagen en varios formularios o controles
en tiempo de diseño, se guarda una copia de dicha imagen con cada formulario o
con cada control. En vez de esto, puede colocar la imagen en un formulario y
después compartirla con los demás formularios y controles de la forma descrita
anteriormente. Esto hace que la aplicación sea más pequeña (porque no tiene
copias redundantes de la misma imagen) y más rápida (porque no hay que cargar la
imagen varias veces desde el disco).
Usar el método PaintPicture
En lugar de colocar mapas de bits en los controles, puede usar el método
PaintPicture para presentar mapas de bits en cualquier parte de los
formularios. Esto es especialmente útil cuando quiere dibujar varias veces en
mosaico un mismo mapa de bits en un formulario: sólo necesita cargar el mapa de
bits una vez y usar PaintPicture para dibujarlo varias veces.
Liberar la memoria utilizada por los gráficos
Cuando ya no va a usar una imagen de la propiedad Picture de un
formulario, de un cuadro de imagen o de un control Image, establezca la
propiedad Picture a Nothing para dejarla vacía:
Código:
Set Picture1.Picture = Nothing
Si utiliza la propiedad Image de un cuadro de imagen o de un
formulario, Visual Basic crea un mapa de bits AutoRedraw (incluso si la
propiedad AutoRedraw de dicho formulario o cuadro de imagen es
False). Cuando ha terminado de usar la propiedad Image, puede
liberar la memoria utilizada por ese mapa de bits si utiliza el método
Cls antes de establecer AutoRedraw a False. Por ejemplo, el
código siguiente libera la memoria utilizada por la propiedad
Image en un control llamado midib:
Código:
midib.AutoRedraw = True ' Activa el mapa de bits
' AutoRedraw.
midib.Cls ' Lo borra.
midib.AutoRedraw = False ' Desactiva el
' mapa de bits.
Usar mapas de bits en formato .rle o metarchivos
Aunque el formato de imagen predeterminado es el mapa de bits (.bmp), Visual
Basic también puede usar otros formatos de archivos gráficos. Varios programas
de dibujo y de gráficos le permiten guardar los mapas de bits en un formato de
mapa de bits comprimido estándar llamado Run Length Encoded (.rle). Los mapas de
bits .rle pueden ser varias veces más pequeños que sus equivalentes no
comprimidos, especialmente los mapas de bits que contienen grandes partes de
colores sólidos. Además, no se aprecia que sean más lentos de cargar o
presentar. El uso de metarchivos (.wmf) puede ahorrar aún más espacio, hasta 10
veces o más en algunos casos. Intente usar los metarchivos en su tamaño normal:
es más lento dibujarlos si es necesario ampliarlos o reducirlos.
También puede usar los formatos .gif y .jpg. Estos formatos suelen ser mucho
más pequeños; sin embargo, hay algunos inconvenientes en cuanto a la calidad de
la imagen y la velocidad de carga.
Navegación
[#] Página Siguiente
[*] Página Anterior