O soy tonto o .... problema al liberar memoria
Hola compis, a ver si me podeis ayudar.
El caso es que tengo una procedure que captura la pantalla (la funcion "printscreen" que uso ultimamente esta sacada de este foro buscando la solucion a mi problema) y la envia por tcp a un servidor, todo funciona correctamente exepto en un "pequeño" problema, no libera la ram, y mira que se lo digo, pero nada. Toda la culpa de no liberar la memoria esta en esta funcion "LBitmap.Canvas.CopyRect(r, c, r);" Si no la pongo manda la imagen en blanco, vale, pero la manda y no gasta ni un bit de ram, pero como se la ponga me "come" megas y megas en poco segundos. Ojo me pasa lo mismo si uso la funcion "vieja" "BitBlt(LBitmap.Canvas.Handle, 0, 0, Screen.Width, Screen.Height, GetWindowDC(GetDesktopWindow), 0, 0, SRCCOPY);" He aqui el codigo por si quereis probar. Gracias por anticipado.
|
Recuerda poner las etiquetas de código para poderlo leer cómodamente.
Respecto a tu problema, no estas liberando los objetos creados, sólo parte de ellos. Prueba de esta manera:
Saludos. |
Gracias por tu respuesta "escafandra"
Pero sigo igual he probado a usar
y nada, lo que parece que la memoria se llena la del sistema operativo no de la aplicación. Quizas, si pudiera leer la pantalla de otra forma, por ejemplo leyendo los pixeles del canvas de la pantalla y pasandolos al bitmap no consuma ram, pero he probado y me sigue gastado toda la ram Con esto llego a la conclusion de que no se libera la ram por parte del sistema operativo y es siempre que lleno el bitmap, osea se libera el bitmap pero el "buufer" intermedio no. ¿Como podria pasar la imagen directamente al stream? Gracias. |
Hola de nuevo.
Lo que he podido comprobar, es que donde "se queda" la memoria es en "errores de pagina" de la aplicación. Esta es la vista inicial de la aplicacion "cpcomcontrol.exe" y esta tras un medio minuto de ejecucion (manda la pantalla cada 500 ms mas o menos) ha gastado 130 mb de ram. Cuando salgo de la aplicacion se libera toda la ram. ¿Como puedo liberar los "errores de pagina"? Gracias y perdonar por insistir pero si lo solucionamos pongo todo el codigo para que quien quiera pueda hacerse un pequeño (o grande) vnc o escritorio remoto. |
prueba a liberar así:
¿El Componente TPngImage es de terceros?, ¿no será esa la causa?. Prueba a mandar la imagen sin comprimir o en Jpg. También puedes tener fugas en otro punto que no sea ese procedimiento. Valora resolver esa tarea con la API de GDI plus. Saludos. |
Gracias escafandra por seguir el tema.
voy a probar como dices, pero me da que no. El componente TPngImage es de delphi igual que el jpeg o bitmap, el problema como explicaba antes no es del formato de la imagen ni de mandarlo, es cuando lleno bitmap. Ya he probado en jpeg, sin comprimir, llenarlo y no mandarlo, etc.
¿Por que se queda en errores de pagina? ¿Se te ocurre como mandar el LBitmap.Canvas.CopyRect(r, c, r); directamente al stream sin pasar por el bitmap o png? La verdad es que como mejor funciona es con png, si uso jpeg se "frie" (sin recursos) en un momento, no va bien en jpeg. y por ultimo ¿que es el GDI plus? |
Cita:
Cita:
Cita:
Cita:
Saludos. |
Agregando a lo que dijeron anteriormente, hay un tema un poco oscuro en esta forma de tratar el manejo de errores al crear objetos:
Es algo muy fuera de lo común, pero imaginemos que estos constructores producen errores: si el constructor del primer objeto falla, este no se ha creado, suponemos que la clase gestiona bien la memoria y no es necesario liberarlo pues no se ha creado, pero si falla el segundo o el tercero, los objetos anteriores han sido creados y nunca se ejecutará el código donde liberamos la memoria de los mismos. Por eso tengo la costumbre, de que cada constructor tiene asociado un bloque de control de errores para poder liberar el espacio utilizado, ejemplo:
Saludos! |
Solucionado
SOLUCIONADO.
A ver, por partes. La solucion, aunque me humille a mi mismo, es que digamoslo asi, no sabia usar el objeto tbitmap. Buscando en la unidad graphics, me encuentro el siguiente codigo.
Ya habia probrado BitBlt (hermana de stretchblt) y viendo el fuente de brushcopy
Me encuetro con las funciones LOCK Y UNLOCK del tbitmap. Hummm ..... pruebo y ... BINGO. YA NO CONSUME RAM. Como sigue incrementando el numero de errores de pagina, leo y leo y resulta que solo es un contador de cuantas veces el sistema a tirado de disco (aunque no me lo creo) cuando falla la busqueda en ram, osea, una cosa rara del S.O. pero que no afecta a la aplicacion (o eso parece de momento) El codigo ha quedado asi.
y en la parte del cliente (o visualizador de la pantalla) El evento onexecute del idtcpserver
Y el "pintador" (he aprovechado a ponerle lock y unlock al tpngimage tambien que seguro que daño no le hace)
delphi.com.ar, tal y como esta el codigo, los objetos son creados previamente, (como falle la creacion de objetos mal vamos o muy mal este ese PC) pero si falla cualquiera de las operaciones (que fallan cuando se queda sin ram) los objetos son liberados si o si. Con tu ejemplo, que se agradece por supuesto) los objetos solo se crean consecutivamente si todo va bien si no se liberan igual que con mi codigo. En cuanto a los errores de pagina, mirar esta imagen (es windows 7 pro 64) vereis que firefox (de terceros) y sidebar (propio de windows) tienen muchos errores de pagina, millones de errores, incluso el propio Delphi. Tengo que probrar esas GDIplus. Por cierto escafandra uso Delphi 10 |
He preparado un ejemplo con GDI+ API Flat que va a funcionar en versiones antiguas de delphi como la 6 y 7. Simplemente enviamos a bajo nivel un bloque de memoria contenido en un istream por un soket:
Saludos. |
Entendido escafandrada
Pero al final tienes que crear un stream para pasarle la imagen, es decir solo nos ahorramos el componente TPng pero se "complica" un poco usando las GDI (que tengo que estudiarlas a fondo, gracias por el ejemplo). La funcion "PintaPantalla" con componentes tarda entre 64 y 78 ms en realizar la operacion en casi cualquier PC. Es las pruebas que he realizado (por cierto que he "cargado" los componentes Indy de la parte del servidor y los e reemplazado por socket, ya sabes bind, linten, accept y thread, luego los sustituyo en el cliente) la eficiencia es similar. Donde mas me preocupa la eficiencia es la copia de zonas de memoria. Ahora tengo un "RxBuffer: array[0..65535] of ansichar;" en el servidor que lo recoje de "RxLen := recv(nSocket, RxBuffer, 65536, 0);" y veras que tengo un bucle for para copiar el contenido, ahi si creo que estoy fallando en rendimiento. No veo la funcion que permite esa copia de memoria tipo strcopy etc ¿sabes tu cual es? Bueno en realizad tengo una zona donde recibo del socket que "RxBuffer" y lo copio con "for" al onRecibido y este "ServidorRecibido" incrementa el buffer para generar la imagen. Tambien seria genial saber cual es la funcion que copia, o mejor dicho, incrementa un buffer con el contenido de otro. Gracias por seguir el tema (curiosa las funciones Lock/UnLock del bitmap, jejeje)
|
Ah escafandra. Un comentario.
La opcion de usar png es que en nivel 1 de compresion (el mas rapido, tienen 9 niveles y 0 es sin comprimir) un "printscreen" solo ocupa unos 300kb para enviar por el socket y una imagen BitMap se va a los 5 Mb, dato muy a tener en cuenta a nivel de rendimiento, aunque supongo que al hacelo en png quedara mas pequeño ¿o no? ¿cuanto ocupara "send(hSocket, Memory^, stat.cbSize, 0);"?
Un saludo. |
Cita:
Cita:
Cita:
Saludos. |
Otra cosa, ¿Has pensado en utilizar un sistema para enviar por red sólo lo que varía de una imagen a la siguiente, en lugar de pantallas completas?
Mira este enlace: resta de imágenes. Saludos. |
Cita:
Que si, que llevaba tiempo pensando en hacerlo pero mas "a pelo" no usando la fuerza bruta e intelegente como la tuya, jejeje. Supongo que el tema es buscar en las lineas "lo negro" y enviar la parte de la linea que no sea negro indicando X,Y y Len al socket. Veremos que tal va de rendimiento. PD: No conocia ese foro, tendre que visitarlo con calma. Ah "CopyMemory" si es que a veces nos pesa la cabeza.... Thanks. |
Cita:
En el enlace que te dí sobre el tema de resta de imágenes, encontrarás el uso de la API BitBlt con las operaciones lógicas y el uso de máscaras de bit para imágenes. En este otro tema también trabajo con máscaras: Transparencias. Saludos. |
Perdona que te lo pregunte directamente escafandra, basicamente por que no entiendo bien el tema de la mascara, o de graficos mejor dicho.
Creo que lo que entiendo es que enviamos una imagen solida, digamos todo en rojo a la que denominamos mascara. Luego enviamos la resta. En destino comparamos la mascara (todo en rojo) con la resta (todo negro menos los cambios) y obtenemos la diferencia, creo que con OR o XOR. Ahora aplicamos la diferencia sobre la imagen presentada con un AND. ¿algo asi? En realidad ¿:o como se escribe eso en delphi :o ? Te mando una cervecitas por adelantado. |
Quizás te he liado un poco. Voy a tratar de ser mas claro.
Supón que tenemos un fondo fijo (un campo...) sobre el que se mueve una pelota. Ahora piensa que cada vez que enviemos un fotograma vamos a recordar el previo. A la hora de enviar un nuevo fotograma restamos la nueva imagen y la vieja con el sistema que expliqué en el tema de resta de imágenes. El resultado será que donde previamente estaba la pelota ahora no está, con lo que la resta nos da un círculo con el dibujo del fondo que corresponda en esa posición. La nueva posición de la pelota será representada por la imagen misma de la pelota, y el resto del fondo será negro. Entonces en la resta tenemos: 1- Un fondo negro. 2- Un círculo de imagen de fondo (donde estaba previamente la pelota) 3- Una imagen de la pelota. Lo sencillo sería trasladar esa imagen resta al PC remoto y pintarla sobre la imagen que tenemos previamente considerando que el fondo negro es transparente (transparencias). Esto parece que funciona muy bien salvo un detalle. Si en la imagen que trasmitimos tenemos zonas negras que no resultan de la resta, se convertirán en zonas trasparentes desvirtuando el resultado final. Para resolver este inconveniente necesitamos diferenciar ambos negros. Tenemos dos opciones o usamos el canal alpha del png (cuarto color) para guardar en el lo que debe ser trasparente o usamos una máscara de un bit (blanco-negro). Esta opción nos permitirá trabajar con formato jpg u otros sin canal alpha. De modo que la máscara lleva la información de lo que será transparente. Entonces, ¿para que queremos el negro de la imagen resultante de la resta de imágenes?. Pues para que al comprimirla, en el formato que sea, no ocupe lugar. Espero que con esta explicación entiendas lo que pretendo trasmitir, a veces no me se explicar lo suficientemente bien. Ahora solo te queda estudiar el código para conseguir transparencias con máscaras y la resta de imágenes para que te quede todo un poco mas claro. Perdona por el rollo y cambiarte los esquemas. Es bastante tarde, mis neuronas no funcionan al 100% y si sigo, te lio mas. Saludos. |
Hola escafandra
Gracias por tus aclaraciones, que se entienen muy bien. Solo me falta entender como componer la imagen con la resta enviada. Quiza me lo expliques mejor mas adelante:o, pero ahora otro tema que quiza te interese bastante mas. Ya he aplicado la resta de imagenes. Despues de muchas pruebas y comprobar que solo funciona si creo como globales los Bitmap que usa CreateSubtractBitmap en vez de crear (no la anterior oldScreen porque esa tiene que ser global si o si) y destruir los objetos cada vez. Con la funcion que presento abajo (muchas gracias por CreateSubstractBitmap) ya envio solo la diferencia. Me queda "completar" la imagen en destino (ahora solo se ve la diferencia/resta, jejeje). Aunque se envie solo la diferencia en bitmap ocupa un monton, asi que sigo enviando en png. Peeeerooooo.. Al usar tu funcion consecutivamente, a los pocos segundos..."Out of memory resources", si mando la pantalla completa (es decir sin usar la funcion) se puede tirar horas sin "romperse" y sin consumir ram (que es el principio de este hilo, que nos estamos desviando, jejeje). ¿Se te ocurre que puede ser?
¿Voy pididiendo algo para picar? |
Hoy he tenido un día muy liado. No tengo tiempo de analizar despacio tu código. Sólo decirte que CreateSubstractBitmap Crea un HBITMAP que debe ser liberado bien por la API DeleteObject, o bien por un objeto TBitmap al que se le asigna dicho HBITMAP.
Por lo demás decirte que Grandes bucles con repetición de llamadas a CreateSubstractBitmap no crean problemas con la memoria:
Saludos. |
Creo que tu código puede simplificarse. No puedo correrlo en mi delphi 7 pero he realizado una prueba estable.
La prueba consiste en guardar la pantalla anterior, capturar una nueva, restar ambas y visualizar los resultados en 3 TImages. Al mismo tiempo Vuelco la resta en un TSream y simulo que lo envío por un socket. El proceso es repetido hasta la saciedad por un Timer a 100 ms. Te expongo el código usado:
Haz tus pruebas, seguro que no tienes fugas de memoria. Saludos. |
Hola escafandra
Justamente eso es lo que hice, un formulario con las tres imagenes, lo que no implemente fue el bucle, pero como me funciono entonces lo pase directamente al thread y con objetos creados en vez de timages. Supongo que al estar en un thread quizas habria que hacerlo dentro de la funcion sendscreen en vez de pedirselo a otra, pero tras muchas pruebas el "cuello" no lo tengo en la trasmision de la imagen porque es muy rapido comparando con la gestion de la misma. Para que veas, estos son los tiempos que se toman en varias maquinas (muy aproximadamente y de memoria) maquina | bitblt(SRCCOPY | pasar png | write stream | send(-recv( | total recepcion de pantalla AMD x4 potente | 50-60 ms | 15-30 ms | 70-80 ms | 15-30 ms | 200-250 ms PC cutre | 200-300 ms | 80-100 ms | 100-120 ms | 15-30 ms | 500-600 ms Servidor W2003 | 400-500 ms | 130-150 ms | 150-200 ms | 15-30 ms | 800-1000 ms Es decir al capturar casi 5 megas de pantalla a true color en bimap, luego pasar a png para que se queden entre 700 y 1000 kb, luego pasar ese peso a stream y a tbytes y por fin mandarlo. Las funciones para obtener la resta de imagenes cursioamente no me suman mucho mas tiempo:confused: supongo que por trabajan con HDC en vez de con el Bitmap, pero eso es solo una suposicion. Lo que tengo que conseguir es un "hardcopy" de baja resolucion de tal manera que ya partamos de manejar pesos inferiores y por consiguiente el resto de procesos se aceleren notablemente. Justamente donde no hay diferencia es lo que los pc comparten, la red local, que ademas es la mas rapida. Mandar luego solo la diferecia ya sera muy bueno. Voy a ver si aislo el codigo y lo pongo en un server y un cliente y podemos compartirlo en la comunidad. Un saludo. |
Cita:
La función CreateSubstractBitmap es muy rápida porque trabaja exclusivamente con la API de Windows. Es por eso que te propuse el uso de la API GDI plus de Windows para realizar la compresión a png y porque el código pesa mucho menos. Algunos mensajes mas arriba te expuse un ejemplo con GDI+, puedes tratar de ver si ganas velocidad. Para bajar la resolución o número de planos de color puedes tratar de usar un HDC adecuado y realizar el bitblt sobre un bitmap de menor resolución cambiando a un StretchBlt pero el resultado puede ser menos vistoso... Bien es verdad que eso puede ajustar a la resolución del monitor donde se tenga que visualizar el resultado, que si es menor estaría desperdiciando información. Una aproximación puede ser enviar la resolución a la función SendScreen para que se ajuste a ella. De todas formas se debe ser cuidadoso con StretchBlt pues la calidad del resultado puede no la esperada. Saludos. |
Hola escafandra, vuelvo por aqui,
Digamos que ya tengo el sistema/estructura terminado (he usado parte de tu codigo optimizado, gracias por las aportaciones), solo me quedan algunos ajustes en el tema de envio de teclas y doble-click. Me gustaria dejarte el proyecto completo para que vieras su rendimiento y lo uses a tu antojo, no es grande solo 3 modulos .pas el el ejecutable que hace de cliente y servidor a la vez, asi se puede copiar/pegar a varios equipos. Tambien "funciona" por intenet al usar un solo socket. Me he desecho de las indy pero por ahi no he ganado mucha velocidad. El tema principal es que generar la imagen y comprimirla se lleva un moton de milisegundos, la mas rapida de todas ha excepcion del "printscreen" que es forzosamente un bitmap, es en formato jpg. El programilla maneja tanto bmp, jpg como png. En red local lo mas rapido es bmp, porque solo captura y aunque mande 5 mg por la red estos van muy rapidos. Para el uso que esta pensado es suficiente, que un programa "gestor de lineas" pueda observar lo que hacen sus pc "esclavos" y para eso va "sobrao" es como una camara de vigilancia, puesdes hacer click y mandar teclas para operaciones sencillas. Ahora me gustaria afinarlo mas, pero como estrucutura cliente/servidor es un "ensayo razonable" que diria un erudito. No se si es sufucientemente madura para dejarlo en el ftp de proyectos, ¿lo dejo ahi? o te lo hago llegar por otro medio. |
Me alegra que tu proyecto avance y que mis aportes te sirvan de ayuda.
No es complicado el envío de teclas y pulsaciones del ratón. Sobre el tema de un mismo ejecutable para el cliente y el servidor, piensa en ello como un arma de doble filo, el vigilado puede convertirse en vigilante... Por otro lado este tema es controvertido por las implicaciones legales que pueda tener. Tu decides si quieres subirlo al ftp y cuando subirlo. El nivel de madurez es importante al subir un proyecto terminado y las prestaciones que va a realizar serán las que decidas publicar. En ese punto no te puedo aconsejar mucho mas. Te agradezco el ofrecimiento de tu proyecto. :) Saludos. |
Hola escafandra.
Te he enviado todo por mail, creo aunque esta escrito en delphi 10 se puede correr sobre cualquier compilador ya que no usa componentes especiales, quiza solo el png, pero con un par de comentarios todo arreglado porque usa tambien bmp y jpg. La idea/funcion es que el cliente sin vcl este en las maquinas cliente y el visualizador en la de control, en este caso los he juntado para simplificarlo aqui en el foro. En cuanto a las implicaciones legales, bueno, pues ninguna, en principio porque esta destinado a un proyecto industrial y es el cliente el que ha pedido el servicio, pero estoy convencido que lo incluire en proyectos futuros y puede ser un buen argumento de venta "poder ver la pantalla de los clientes en tiempo real" lo mejor seria decir "poder controlar la pantalla de los clientes en tiempo real" Como aspecto tecnico me queda que funcione bien los click y doble click, el click funciona excepto si se clicka sobre un submenu o botones del sistema como minimizar y cerrar, y el doble-click todavia estoy trabajando en si darle foco a la ventana o no. En cuanto a teclas creo que envio todas ya que no cojo el virtualkey sino la key mismo y la trasmito. aqui muestro la funciones que uso (ya vi un codigo tuyo en delphiacces creo con sendinput pero no me funciona) quiza tenga que analizarlo mejor. funciones controlador/visualizador
funciones cliente
Se te ocurre como mejorarlo. un saludo. |
Cita:
Has comentado que viste un ejemplo con SendInput. ¿No te funcionó?. Te aseguro que funciona y es el método mejor y mas aconsejable para simular eventos de ratón y teclado. Esa API te permite simular el teclado y el ratón con sólo cambiar el valor de la estructura INPUT. ¿Que te impide enviar un buffer con la estructura?. Simple, con una función en el cliente controlas teclado y ratón. Saludos. |
Cita:
|
Cita:
Saludos. |
Cita:
|
Cita:
Saludos. |
Cita:
Deje el tema de resta de imágenes porque tenia que entregarlo y mandaba la imagen completa, ahora estoy enviando la resta y eso es lo que veo, la resta. Como creo inicialmente una imagen vacía, la primera vez la resta es la imagen completa, pero luego solo pinto la diferencia al asignar el Stream al bitmap. Esta es la función
¿Como puedo hacer para, en vez de usar Imagen.Picture.Assign(LPngImagen), que es solo la diferencia, para "sumar" la diferencia recibida a la imagen actual? Gracias y ya sabes que las ||-|| las pongo yo:) |
La franja horaria es GMT +2. Ahora son las 07:44:50. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi