Mensajes

No me quiero anticipar pero segun fuentes no oficiales una vez mas volvio a ganar el MAS:

Windows 7 esta obsoleto, Microsoft ya no le da soporte.

De nada.

[es la base]

El codigo del ejemplo es la base de mi programa. Añadele leer imagenes, pintarlas pixel a pixel y luego usar HBITMAP y BITMAPINFO de WINAPI para plasmarlo en la ventana. Todo eso es un proceso costoso para la CPU y por eso quiero reducir el coste que tiene ese codigo fuente del ejemplo sobre la CPU. Para destinar el CPU restante a dibujar las imagenes en la ventana.

Y lo seguira haciendo siempre que tengas un bucle continuamente ejecutando codigo.

Tanto si utilizo OpenGL como sino, el programa pone el procesador al 100% en un unico hilo. OpenGL le da algo mas de rendimiento a mi programa porque "SetDIBitsToDevice()" es mas lenta que "glDrawPixels()". Mi problema no va con la carga en la tarjeta grafica. Solo mencionaba algo que me dejo perplejo.

Por lo de arriba y con un Sleep esta solucionado en un simple programa de ventanas.

Tirando de OpenGL el programa seguro que fluye perfecto. El problema es que para visualizar una imagen con OpenGL debo usar mas memoria de la necesaria si no tiene dimensiones de base 2. (16x16, 32x32, 512x512,... etc)

Ademas de que si copio el programa a otro ordenador, debo llevar tambien las DLL de OpenGL. En mi caso no es problema, pero si le doy el programa a alguien de casa (por poner un ejemplo) lo primero que me van a decir es que no funciona porque no saben que deben copiar tambien esas DLL.

Ah, bien, entonces busca otro ejemplo de OpenGL que si funcione a tu gusto y listo, todo solucionado ... o no.

La CPU baja, pero sigue presentandome un lag con los input y sigue sin fluidez en las animaciones de zoom.

¿Que input y animaciones? ¿Eso se supone que esta en el codigo de arriba?

La idea es reducir el uso de CPU sin sentido para centrarlo en lo que interesa del programa, que funcione con fluidez.

Sera un problema de OpenGL entonces. ¿Es acaso la tecnologia adecuada para un "visualizador de imagenes"?

https://stackoverflow.com/questions/5999555/opengl-on-windows-uses-tons-of-cpu-when-swapbuffers-is-called-on-a-renderthread

Llamar a glFlush y glFinish como dicen ahi antes de SwapBuffers reduce a la mitad el consumo de CPU en mi maquina (de 5%/6% a 2%/3%).

Con el sleep (al ser monohilo) se detiene el programa ese milisegundo. La CPU descansa, pero se le acumula el trabajo.

Pero si ese codigo no hace nada ... en fin.

Lo de la CPU tambien me ocurre con el videjo motor de juegos que hice con GLUT. Aunque solo mostrase medio cubo en pantalla, la CPU se dispara al 100%. Incluso limitandolo a 60fps.

¿Pero hiciste lo que te dije? ¿Pusiste la llamada al Sleep? Hacelo y despues me contas.

Lo que pasa es que ejecutas continuamente DrawGLScene y SwapBuffers, ponele un Sleep(1); justo despues.

[00010000]

¿Que valor tiene EBX? Indefinido. ¿A donde apunta EBX? Nadie lo sabe.

Asumo que estas trabajando en Windows aunque no lo dijiste. Ni bien arranca el programa, mucho antes del entry point con el WinDbg puedo ver:

ntdll!LdrpDoDebuggerBreak+0x30:
00007ffe`c765119c cc              int     3
0:000> r ebx
ebx=272000
0:000> dd @ebx l1
00000000`00272000  00010000

Lo que sucede al parecer es que la direccion a la que apunta EBX contiene el valor 0x10000=65536, es un puntero a una estructura (el PEB, Process Environment Block) pero igual el planteamiento de usar un registro con un valor indefinido es un error de logica (podria apuntar a 0 u otra direccion invalida provocando una excepcion no controlada). De esos cuatro bytes solo modificas el primero haciendo que el valor cambie a 0x10004=65540, despues al solo usar el primero tambien en la multiplicacion el resultado es correcto.

Esta es la razon ultima por la cual al depurar ese valor es 0x10000  Justamente el tercer byte del PEB indica si un proceso esta siendo depurado o no BeingDebugged. No deberias escribir en el PEB ...

0:000> dt ntdll!_peb
   +0x000 InheritedAddressSpace : UChar
   +0x001 ReadImageFileExecOptions : UChar
   +0x002 BeingDebugged    : UChar
   +0x003 BitField         : UChar
   +0x003 ImageUsesLargePages : Pos 0, 1 Bit
   +0x003 IsProtectedProcess : Pos 1, 1 Bit
   +0x003 IsImageDynamicallyRelocated : Pos 2, 1 Bit
   +0x003 SkipPatchingUser32Forwarders : Pos 3, 1 Bit
   +0x003 IsPackagedProcess : Pos 4, 1 Bit
   +0x003 IsAppContainer   : Pos 5, 1 Bit
   +0x003 IsProtectedProcessLight : Pos 6, 1 Bit
   +0x003 IsLongPathAwareProcess : Pos 7, 1 Bit

PD. EBX es un registro a preservar en STDCALL. Al final no estas multiplicando dos registros, estas multiplicando el registro EAX por un byte al que apunta el registro EBX.

Hay un subforo de ASM donde deberia ir esta pregunta: https://foro.elhacker.net/asm-b84.0/
Lo reportare y con suerte alguien lo movera.

[A]

O cambias el proyecto a ANSI, o llamas explicitamente a FindWindowA o mejor simplemente usas literales de cadena anchos asi: L"CADENA".

De nada.

EdePC: lo encontre justo antes de irme a dormir poniendo funciones de consola c en Google, parecia util a simple vista al menos