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.
Si bien el doble buffer eliminaría el flickering, tambien se puede obtener ese efecto de otras maneras como utilizando máscaras XOR
, 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...
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)
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.
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
Aqui estas totalmente en lo cierto... si se tratase de un programa que presentara animaciones, pero este no es el punto
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.
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.
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.
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.
Estas seguro?, yo te puedo asegurar que no es asi, y menos en una aplicacion que corre en modo ventana.
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.
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.
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.
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.
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.
Nuevamente en desacuerdo, como cres que funciona el panit? adivina...con el gdi+ de hecho todo cuanto vez del sistema de ventanas de windows usa el GDI+ y nunca veraz que suceda eso, realmente es problema es la programacion.
bueno es cierto que ahorra un tiempo pero es despreciable a cmabio del costo que implica pasar repetidamente por el DMA para enviar los datos a la memoria de video, ya que es mucho mas rapido hacer un solo viaje con un bloque de datos por DMA que hacer muchos viajes con pequeños segmentos.
Al usar backbuffer no se nceesita borarr la pantalla, solo se remplazan los datos que estan en ella y por otro lado el dibujar un circulo en un buffer y luego pasarlo a la pantalla no implica que se redibuje toda la pantalla sino solo el area donde esta el circulo.
lo que pasa es que funciones como las que has mencionado, y de ehco cualquier operacion tenga o no tenga punteros... es hecha a travez de la api, el compilador convierte el codigo en llamados a la API que le autorizan o no una transaccion en memoria por ello cuando con un puntero vas por una locacion de memoira no asiganda te sale el mensaje de error del sistema (sea linux o windows) diciendo que hay una infraccion de acceso ya que es el propio sistema quien determina si se puede o no hacer algo en una locacion de memoria.
QUOTENuevamente en desacuerdo, como cres que funciona el panit? adivina...con el gdi+ de hecho todo cuanto vez del sistema de ventanas de windows usa el GDI+ y nunca veraz que suceda eso, realmente es problema es la programacion.Así es, el paint (versiones nuevas) utiliza gdi+. Y tal como lo dices es "problema" de la programación, ya que al no estar utilizando las funciones de gdi+ para el dibujado, hace mas lento las cosas al tener que utilizar un seudo-punto hecho con un fillrectangle con ancho y alto puestos a 1.QUOTEbueno es cierto que ahorra un tiempo pero es despreciable a cmabio del costo que implica pasar repetidamente por el DMA para enviar los datos a la memoria de video, ya que es mucho mas rapido hacer un solo viaje con un bloque de datos por DMA que hacer muchos viajes con pequeños segmentos.En eso tienes razon, pero a final de cuentas, solo son unos cuantos puntos los que vas a transferir al frontbuffer, comparado a todo el tamaño del backbuffer en un solo bloque, incluso si tan solo transfieres un area determinada, por decir un círculo, de la manera que él lo hace solo transfiere los puntos del perímetro. De otra forma, si transfieres el cuadro donde está el círculo con un BitBlt te traes muchisimos puntos mas (una transferencia de memoria mas grande, que tal vez no supere la velocidad que hacer las transferencias individuales para cada uno de los puntos de la circunferencia); ahora bien podrias decir utilizar un TransparentBlt pero con eso tambien te puedes traer mas informacion que la necesaria.QUOTEAl usar backbuffer no se nceesita borarr la pantalla, solo se remplazan los datos que estan en ella y por otro lado el dibujar un circulo en un buffer y luego pasarlo a la pantalla no implica que se redibuje toda la pantalla sino solo el area donde esta el circulo.No mencione que fuese necesario, borrar la pantalla para traerse el backbuffer. Pero al tratarse de graficos vectoriales, solo se dibuja la parte necesaria y obviamente hay que borrar el area de dibujo para redibujar, ya que si no los dibujos ke se encontraban ahi, kedarán sobrepuestos. Si se tratase de un programa con graficos tipo raster entonces no habria que borrar, simplemente sobreponer la parte cambiada o todo.QUOTElo que pasa es que funciones como las que has mencionado, y de ehco cualquier operacion tenga o no tenga punteros... es hecha a travez de la api, el compilador convierte el codigo en llamados a la API que le autorizan o no una transaccion en memoria por ello cuando con un puntero vas por una locacion de memoira no asiganda te sale el mensaje de error del sistema (sea linux o windows) diciendo que hay una infraccion de acceso ya que es el propio sistema quien determina si se puede o no hacer algo en una locacion de memoria.Creo que no me di a entender, cuando tu utilizas punteros para acceder a la memoria no pasas por ningún API ni el compilador lo convierte a llamadas de API. Te puedes dar cuenta de esto si desensamblas un código ejecutable, cuando hayas hecho un acceso a memoria verás algo como MOV eax,[eax] donde esta cargando al registro eax, la informacion a la que apunta el valor de eax, sin llamar a la API, pues no hay ningun CALL.Con el block de memoria que te deja accesar el lock del backbuffer tu puedes hacer algo como esto:CODEint *video;//...video[100][100]=0;//...Donde pondrás el pixel 100,100 en color negro, acceso directo al backbuffer (VRAM o RAM).Lo que hacen los sistemas operativos, es monitorear el uso de la memoria de cada uno de los programas que están en ejecución, en ningún momento los programas le piden permiso a windows para leer o escribir en ram (aunque para reservar memoria si), eso no implica ke solo puedas leer o escribir en tu espacio de memoria, por ejemplo puedes obtener el puntero de una ventana ajena a tu sistema y hacer con ella muchas cosas. Hay espacios de memoria restringidos y es cuando el sistema operativo destruye el proceso que la esta tratando de acceder. InvalidMemmoryAddress error, el mas clasico es el (0x000000), por punteros nulos.niofis
Por supuesto, pero no seguire discutiendo pues seria una discución sin fin y la verdad no me la paso todo el dia sin hacer nada y tengo que trabajar... asi que decidi abandonar la converzacion, lo ideal que queria hacer era hacer un ejemplo yo mismo donde demostrara que lo que digo es cierto, pero lamentablemente ando muy mal de tiempo y tengo otros desarrollos muy urgentes por hacer. Lo siento, si tengo tiempo en algunas semas hare lo de el ejemplo.. sino.. pues bien cada cual es libre de experimentar.
Autor
Tema: Discusion: (Leído 3308 veces)
