CLR: .Net / Mono / Boo / Otros CLR > C#
Discusion:
JuanK:
Bueno lamento contradecirte..
--- Citar ---Hola, el programa no necesita utilizar doble buffer para correr mas rapido, de hecho eso lo haria mas lento y al ser un sistema para dibujo directamente lo haría un poco mas complicado de programar y por lo tanto aumentaría la cantidad de instrucciones para realizar el mismo trabajo.
--- Fin de la cita ---
En esto estas totalmente equivocado, es mas rapido dibujar todo en memoria y luego hacer transferencia en bloque que hacer transferecia directa puto a punto (copia direta a memoria visible)
--- Citar ---Si bien el doble buffer eliminaría el flickering, tambien se puede obtener ese efecto de otras maneras como utilizando máscaras XOR
--- Fin de la cita ---
El double buffer no ayuda mucho a lo del flickering, para esto es mejor conplementarlo con lo del retrazo vertical.
--- Citar ---, pero como se ve en el código está utilizando las librerias GDI+ de .NET Framework por lo tanto no soporta esa función raster. Aunque bien podría utilizar SetPixel del GDI de windows, como está utilizando el GetPixel, y así aumentará el rendimiento. La mejor forma para aumentar el rendimiento del programa es utilizar la memoria directamente, pero eso es otro cuento...
--- Fin de la cita ---
En parte cierto, pero en realidad ningún sistema derivado de win32 permite usar la memoria directamente, lo más rapido seria usar la api de directX la cual evita pasar por el ciclo de mensajes de ventanas del GDI y permite usar las implementaciones de hardware a travez de las apis de bajo nivel de windows. o biien usar una version reciente de openGL
niofis:
Hola de nuevo, no es por molestar pero creo ke aun hay que hacer algunas aclaraciones...
--- Citar ---
Bueno lamento contradecirte..
QUOTE
Hola, el programa no necesita utilizar doble buffer para correr mas rapido, de hecho eso lo haria mas lento y al ser un sistema para dibujo directamente lo haría un poco mas complicado de programar y por lo tanto aumentaría la cantidad de instrucciones para realizar el mismo trabajo.
En esto estas totalmente equivocado, es mas rapido dibujar todo en memoria y luego hacer transferencia en bloque que hacer transferecia directa puto a punto (copia direta a memoria visible)
--- Fin de la cita ---
Aqui estas totalmente en lo cierto... si se tratase de un programa que presentara animaciones, pero este no es el punto de este programa, y al estar esperando la entrada del usuario, se presenta mayor carga al procesador pues es necesario calcular las transiciones al punto origen y de vuelta a la pantalla; no es que sea algo complicado, de hecho es trivial, sin embargo se lo está ahorrando sin ningun problema. Pero obviamente el cuello de botella no es el uso directo de la pantalla, esta en otro lugar.
--- Citar ---QUOTE
Si bien el doble buffer eliminaría el flickering, tambien se puede obtener ese efecto de otras maneras como utilizando máscaras XOR
El double buffer no ayuda mucho a lo del flickering, para esto es mejor conplementarlo con lo del retrazo vertical.
--- Fin de la cita ---
Aquí creo que no fui lo suficientemente claro, con flickering me referia al parpadeo que se ve cuando se hace el movimiento de la imagen con los botones designados, para lo cual si funcionaria el double buffer. Sin embargo para poder utilizar el retrazo vertical (VZYNC) necesitas utilizar el double buffering, y como dije antes, no seria de mucha ayuda, pues no es un programa que presente animaciones, a demás el flickering(ahora si) es mas visible en pantalla completa.
--- Citar ---QUOTE
, pero como se ve en el código está utilizando las librerias GDI+ de .NET Framework por lo tanto no soporta esa función raster. Aunque bien podría utilizar SetPixel del GDI de windows, como está utilizando el GetPixel, y así aumentará el rendimiento. La mejor forma para aumentar el rendimiento del programa es utilizar la memoria directamente, pero eso es otro cuento...
En parte cierto, pero en realidad ningún sistema derivado de win32 permite usar la memoria directamente, lo más rapido seria usar la api de directX la cual evita pasar por el ciclo de mensajes de ventanas del GDI y permite usar las implementaciones de hardware a travez de las apis de bajo nivel de windows. o biien usar una version reciente de openGL
--- Fin de la cita ---
En esto estas equivocado, pues con directx y su interfaz de directdraw(que ya no se llama asi), puede hacerse un lock del buffer de la pantalla y accesarlo directamente como si se tratase de una matriz de bytes y escribir o leer de ella como con cualquier otro arreglo.
saludos
niofis
JuanK:
--- Citar ---Aqui estas totalmente en lo cierto... si se tratase de un programa que presentara animaciones, pero este no es el punto
--- Fin de la cita ---
si es una animacion.. es el mismo principio pues al estar escribiendo pixeles directamente en pantalla se ve como se van pintando linea a linea.
--- Citar ---y al estar esperando la entrada del usuario, se presenta mayor carga al procesador pues es necesario calcular las transiciones al punto origen y de vuelta a la pantalla; no es que sea algo complicado, de hecho es trivial, sin embargo se lo está ahorrando sin ningun problema. Pero obviamente el cuello de botella no es el uso directo de la pantalla, esta en otro lugar.
--- Fin de la cita ---
Estas seguro?, yo te puedo asegurar que no es asi, y menos en una aplicacion que corre en modo ventana.
--- Citar ---Aquí creo que no fui lo suficientemente claro, con flickering me referia al parpadeo que se ve cuando se hace el movimiento de la imagen con los botones designados, para lo cual si funcionaria el double buffer. Sin embargo para poder utilizar el retrazo vertical (VZYNC) necesitas utilizar el double buffering, y como dije antes, no seria de mucha ayuda, pues no es un programa que presente animaciones, a demás el flickering(ahora si) es mas visible en pantalla completa.
--- Fin de la cita ---
Si lo fuiste y te reitero, la tecnica de double buffer ayuda a disminuir el efecto de flicker pero no lo elimina y en graficos grandes se sigue haciendo notorio.
Parece que estas muy confundido, el efecto de flicker no se genera por solo tener una animacion y no tiene nada que ver con los botones ni del teclado ni del mouse ni del joystick, dehecho puedes tarr dibujando siempre el mismo cuadro en pantalla y tendras el efecto de flicker sin necesidad de animarlo ni d relacionarlo con ningún botón ni cosa parecida.
--- Citar ---En esto estas equivocado, pues con directx y su interfaz de directdraw(que ya no se llama asi), puede hacerse un lock del buffer de la pantalla y accesarlo directamente como si se tratase de una matriz de bytes y escribir o leer de ella como con cualquier otro arreglo.
--- Fin de la cita ---
Bueno yo se que DirectDraw fue Deprecado y hasta la version de enero aun existia, lo remplazaron? que se usa ahora? respecto a lo de interfaz DirectDraw no es una interfaz. Tienes razon en lo del lock del buffer de pantalla pero realmente cuando haces esto es directX quien se encarga de enmascarar todo y realmente no estas accediendo directamente a la memoria de video sino que DX enmascara su uso de esta manera pero por debajo debe de igual manera pasar por la capa de abstraccion de hardware usando llamadas de bajo nivel en la API.
Bueno no te habia visto por aqui y aprovecho para decir que eres bienvenido, se ve que tienes buenos conocimientos del tema y nos pueds ser a todos de mucha ayuda.
ibito:
Lo que yo si puedo afirmar, es que el double buffering si es mas lento, y mas aun con el uso de vsync. Tambien puedo decir que el double buffer no elimina por completo el flickering, esto se puede notar cuando estas moviendo imagenes grandes por la pantalla.
niofis:
De vuelta con unos peqeños comentarios a tu post JuanK...
--- Citar ---
si es una animacion.. es el mismo principio pues al estar escribiendo pixeles directamente en pantalla se ve como se van pintando linea a linea.
--- Fin de la cita ---
Reitero sin intencion de molestar, la finalidad de este programa no es generar animaciones, y el ke se vea que se pintan linea por linea en pantalla es mas culpa del GDI+ pues está usando FillRectangle para pintar los puntos.
--- Citar ---Estas seguro?, yo te puedo asegurar que no es asi, y menos en una aplicacion que corre en modo ventana.
--- Fin de la cita ---
Aqui si no entendi muy bien, pero lo que se me fiura que pensaste es que puedes sin ningun problema pasar del backbuffer al frontbuffer sin calculo alguno, simplemente indicando las coordenadas left/top origen-destino, utilizando un BitBlt, DrawImage o un memcpy, pero eso no es razon de procesamiento extra. El problema es cuando hay que calcular las coordenadas de la entrada del mouse del usario, en el area de dibujo y convertirlos al origen, para luego pasarlo al backbuffer; lo cual es precisamente lo que digo que se está ahorrando.
--- Citar ---Si lo fuiste y te reitero, la tecnica de double buffer ayuda a disminuir el efecto de flicker pero no lo elimina y en graficos grandes se sigue haciendo notorio.
Parece que estas muy confundido, el efecto de flicker no se genera por solo tener una animacion y no tiene nada que ver con los botones ni del teclado ni del mouse ni del joystick, dehecho puedes tarr dibujando siempre el mismo cuadro en pantalla y tendras el efecto de flicker sin necesidad de animarlo ni d relacionarlo con ningún botón ni cosa parecida.
--- Fin de la cita ---
Muy bien, el efecto de flicker es cuando es notorio tanto el barrido de la pantalla y/o el borrado y redibujado sobre el frontbuffer. Pero aqui al parecer el confundido eres tu, yo mencioné que el flickering en el area de dibujo en el programa de ibito se genera cuando presiona algun boton de panning, lo que hace que el dibujo dentro del area de pintado se mueve, ya se hacia arriba, abajo o los lados, y como hay un redibujado se ve el efecto de parpadeo.
Por otro lado, si no vas a mostrar animaciones (ni un solo cambio de texto, redibujado, etc.) no tiene caso utilizar el backbuffer. Pues no se necesita borrar la pantalla para redibujar en ella, a final de cuentas nada ha cambiado, por lo tanto si no hay animacion no hay redibujado(o no tiene porque haber) programado (solo el de hardware), y como no hay movimiento tampoco puede notarse el barrido generado por el refresco vertical.
--- Citar ---Bueno yo se que DirectDraw fue Deprecado y hasta la version de enero aun existia, lo remplazaron? que se usa ahora? respecto a lo de interfaz DirectDraw no es una interfaz. Tienes razon en lo del lock del buffer de pantalla pero realmente cuando haces esto es directX quien se encarga de enmascarar todo y realmente no estas accediendo directamente a la memoria de video sino que DX enmascara su uso de esta manera pero por debajo debe de igual manera pasar por la capa de abstraccion de hardware usando llamadas de bajo nivel en la API.
--- Fin de la cita ---
Aqui sí no te puedo dicutir mucho sobre la abstraccion de hardware, pero con el lock del buffer si se accede directamente a memoria, puesto que una vez hecho esto no se puede dibujar sobre este a travez de ninguna llamada a API(alto o bajo nivel), pues la unica forma de acceder al buffer blockeado es a travéz de punteros y funciones de memoria (memcpy,zeromemory, etc), hasta que al buffer se le haya quitado el lock, entonces ya se podrian utilizar funciones como PutPixel y otros. Tampoco estoy diciendo que no se pueda accesar a la memoria de video, pues esto es posible al indicar que tipo de memoria utilizara el backbuffer, al momento de ser creado.
Y... creo que ya nos salimos del tema...
Muy buen programa ibito, felicidades!
niofis
Navegación
[#] Página Siguiente
Ir a la versión completa