FWH - Nueva Clase TOutLook2003

Post by **Antonio Linares** » Thu Sep 13, 2007 11:36 pm

Carlos,

Si tu teoria es correcta entonces podríamos usar una variable estática (lPainting) que en caso de ser verdadera serviría para no hacer más pintados mientras que no se termine el anterior.

En una primera prueba habría que comprobar si recibimos un WM_PAINT estando procesando ya un WM_PAINT anteriormente

De la misma forma, podriamos comprobar si se recibe un WM_ERASEBKGND estando procesando un WM_ERASEBKGND anterior

Alfredo Arteaga · Post by **Alfredo Arteaga** » Fri Sep 14, 2007 12:37 am

No es solo un efecto sobre la nueva clase TOutlook, sucede con TGraph, Brush o cualquier imagen cuando se barre algun objeto externo a laaplicación.

Carlos Mora · Post by **Carlos Mora** » Fri Sep 14, 2007 8:24 am

Alfredo,
gracias por el reporte del error.

Antonio,

Antonio Linares wrote: Si tu teoria es correcta entonces podríamos usar una variable estática (lPainting) que en caso de ser verdadera serviría para no hacer más pintados mientras que no se termine el anterior.

Es lo que había pensado, pero no estoy seguro de que sea solución. Voy a probar con un return 1 a ver que pasa.
Cuando recibes un mensaje WM_PAINT no es optativo pintarlo, hay que pintar, porque Windows automáticamente valida la región que ha solicitado pintar y el efecto sería que la region no pintada es la nueva, y no la que estaba en proceso, me explico?

A la vuelta del trabajo seguiré con las pruebas. Mi especulación es que no creo que Windows esté tan mal programado como para que se pierda info de pintado, por lo tanto la cosa es que seguramente windows está optimizando el pintado haciendo algo de álgebra de regiones y nos estamos perdiendo algo.
Por ejemplo que pasa con el DC en el segundo ciclo cuando el primero no esta completo? Creo que por ahí esta la cuestión.

Un saludo,
Carlos.

A&C · Post by **A&C** » Fri Sep 14, 2007 1:41 pm

[img][img]http://img294.imageshack.us/img294/7117/dibujoct5.jpg[/img]
[/img]

AMIGOS COMO DIJO alfredo no solamente es la clase nueva... miren esto
un simple bitmap como fondo

Post by **Antonio Linares** » Fri Sep 14, 2007 2:06 pm

La clase TWindow es una clase propia de FWH por lo que entra dentro del grupo de clases que pueden tener ese problema.

La cuestión es encontrar la causa y la solución

Francisco Horta · Post by **Francisco Horta** » Fri Sep 14, 2007 3:58 pm

Alfredo efectivamente sucede con cualquier aplicacion externa a fwh, yo he probado en dialogs y windows con imagen de fondo (bmp y jpg) con degradado, con colores, y el comportamiento es exactamente el mismo, entiendo que es un bug muy desagradable, a ver si por ahi entre todos coperamos para salir adelante.
salu2
paco

sjingo · Post by **sjingo** » Fri Sep 14, 2007 5:01 pm

He probado el asunto en 3 equipos con características diferentes:

1) Pentium III de 500 Mhz con 448 MB en RAM y tarjeta de video AGP Matrox de 32 MB

2) AMD Athlon XP 2000+, 512 MB en RAM y tarjeta de Video AGP ATI Radeon 9200 de 128 MB

3) AMD Athlon 64 3500+, 512 MB en RAM con tarjeta de Video PCI Express ATI Radeon X300 de 256 MB

El comportamiento es el mismo en los equipos 1 y 2, hay gran consumo de recursos al mover sean diálogos propios o una aplicación externa encima de nuestra ventana FW. Si movemos toda nuestra aplicación sobre el escritorio llega a consumir hasta el 100% de los recursos.

Pero en el equipo 3 no ocurre nada de lo anterior, si movemos cualquier diálogo no llega a consumir más de 2%. Si movemos la ventana entera no llega a consumir el 20%, ¡aquí todo va como la seda!. Será que el puerto PCI Expres tiene algo que ver, al ser más eficiente?

Finalmente probé en modo seguro (a prueba de fallos) donde sólo se carga los controladores básicos de video (VGA), y.... Horror!!!!. En los tres equipos el resultado es peor, un desastre.

La constante en todas las pruebas es que las aplicaciones FW consumen por lo menos un 30% más de recursos que otras, produciéndose por tanto una lentitud en el refresco de los controles mucho más apreciable que en otras aplicaciones. Entonces creo que se debe investigar en qué parte del corazón de FW hace que el requerimiento de recursos sea grande.

Una solución (temporal) para evitar ese efecto horrible es desactivar la casilla "Mostrar el contenido de la ventana mientras de arrastra" en las propiedades del escritorio. Para evitar que se repinte constantemente el control.

Otra solución, que depende del cliente, sería la de recomendarle un equipo como el 3 de mi prueba o con mejores características, que hoy por hoy ya son la constante.

Un saludo

Marcelo Jingo

Carlos Mora · Post by **Carlos Mora** » Fri Sep 14, 2007 5:26 pm

Marcelo,

Vienen muy bien tus pruebas, te cuento que es *muy* significativo que otras aplicaciones se estan ejecutando en el ordenador, y más aún, que la ventana que se mueva por encima no sea la propia, por ejemplo la calculadora o la ventana de propiedades del equipo o cualquier otra. Eso hace que las ventanas de nuestra aplicaion se pinten de manera desincronizada y es cuando muestran los fallos.
No he notado fallos cuando la ventana superpuesta en una hija de la aplicacion, ni me ha dado problemas al moverla completamente.

Respecto de limitar el mercado de mis aplicaciones a Athlones 3200+ con tarjetas gráficas y cores duo... completamente en desacuerdo. No se me ocurriría ni siquiera plantearle a un cliente que se compre una muleta porque estoy rengo.

Las soluciones tampoco estan ajustando la configuracion de windows para que no se dibujen las ventanas mientras se mueven, tal vez mejore la situación, pero es que me parece que hacer esos apaños por algo que no debería existir ni siquiera debería plantearse y es buscar parches y no soluciones.

Te aseguro que cuando lo encontremos el error va a ser una estupidez, nos va a dar vergüenza no haberlo visto antes, asi es que prefiero seguir dando con los cuernos contra la pared antes que bajar los brazos buscando rodeos.

Un saludo,

Carlos.

Post by **Antonio Linares** » Fri Sep 14, 2007 5:55 pm

Usando este ejemplo, con Vista 32, no _ de que aparezca un error de pintado. Podeis intentar conseguir el error con este ejemplo ? gracias

Code: Select all

#include "FiveWin.ch"

function Main()

   local oWnd

   DEFINE WINDOW oWnd COLOR "W/G"

   ACTIVATE WINDOW oWnd

return nil

A&C · Post by **A&C** » Fri Sep 14, 2007 7:03 pm

ANTONIO NO LOGRO REPRODUCIR ERROR CON TU EJEMPLO...

PERO PRUEBALO ASI.. CON UN BRUSH...

#include "FiveWin.ch"

function Main()

local oWnd
Local oBrush
DEFINE BRUSH oBrush FILE "bitmap\fondo.bmp"

DEFINE WINDOW oWnd BRUSH oBrush

ACTIVATE WINDOW oWnd MAXIMIZED

return nil

te da error alla...
por ami me queda asi

[img][img]http://img407.imageshack.us/img407/4260/dibujoba6.jpg[/img][/img]

favor confirmalo al foro:: si te sucede este error o NO...

Carlos Mora · Post by **Carlos Mora** » Fri Sep 14, 2007 7:07 pm

Antonio,

efectivamente tu código no falla. Lo estoy probando en el portatil (XP).
De esto que se deduce?

No he probado lo del bitmap. Luego de cenar me pongo. Voy a estar el el messenger como carlosantoniomora arroba yahoo punto es.

Carlos

sysctrl2 · Post by **sysctrl2** » Fri Sep 14, 2007 7:27 pm

Hola amigos,

me retracto a lo que comente en un mensaje anterior,

decia que solo es en algunas maquinas,

mentira,

es en cualquier tipo de pc, la mia es una tochiba,

y el error se reproduce en una windows con brush,

saludos..

Alfredo Arteaga · Post by **Alfredo Arteaga** » Fri Sep 14, 2007 7:27 pm

Renuncio, me cambio a Visual Basic...

sysctrl2 · Post by **sysctrl2** » Fri Sep 14, 2007 7:31 pm

Jeje Alfredo, no es para tanto amigo,,

afortunadamente existen otros lenguajes,

alguna solucion tiene que existir,

no hay que desesperarnos,,

fivewin nos ha dado mucho,

saludos..

Francisco Horta · Post by **Francisco Horta** » Fri Sep 14, 2007 9:26 pm

recordando hace tiempo tuve este problema de pintado, aqui lo que en ese momento publique,
http://fivetechsoft.com/forums/viewtopi ... highlight=
salu2
paco