none
parpadeo en winform y problemas de consumo de memoria con la interfaz grafica RRS feed

  • Pregunta

  • tema: puedo evitar el parpadeo que se me genera en los winforms
    al abrir otro form y volver al anterior?

    por ejemplo si tengo una imagen de fondo para el form1 y abro un form2, cuando cierro el form 2
    y vuelvo al form1 se redibuja la pantalla y se produce el parpadeo, mas lerdo aun
    por terminal server

    he visto esto:
    La clase BufferedGraphicsContext permite implementar un doble búfer personalizado para los gráficos. Los gráficos que usan un doble búfer pueden reducir o eliminar el parpadeo que se origina al volver a dibujar una superficie de pantalla.

    pero ya estoy tan confundido que no se que hacer, debo aplicar doble buffer a cada control o a la
    aplicacion?

    Nota:
    La manera más sencilla de usar un doble búfer es establecer el indicador de estilo de control OptimizedDoubleBuffer en un control con el método SetStyle. Si se establece el indicador de estilo OptimizedDoubleBuffer de un control, el dibujo del control se redirige a través de un búfer gráfico predeterminado, sin que se necesite ningún código adicional. El valor predeterminado de este indicador es true
     

    la pregunta es si debo implementar doble buffer a todos mis controles perzonalizados
    (ya sean formularios base, textbox, combo, grillas, etc, etc)
    y implementar algo a nivel de aplicacion con doble buffer como lo indica
    la clase La clase BufferedGraphicsContext

    que me conviene para que la aplicacion sea mas rapida, no implementar estilos visuales en mis controles
    , no usar images de fondo en mis form?

    al final noto que net tiene muchas cosas usables pero tenes que ser un genio para poder
    usarlas o directamente no uses nada porque todo provoca estallidos de memoria
    los graficos, los dataset, todo pesa mucho

    si la finalidad de un programador es mejorar cosas de un lenguaje se pierde la finalidad
    de producir sistemas

    en lenguajes anteriores como fox, clarion, la interfaz es muy veloz y no tengo que andar
    reprogramando controles para que no me estalle la memoria

    estoy bastante desilucionado con net o sera que soy muy burro para entender este nuevo
    mundo de la programacion pero vuelvo a insistir que no soy programador del lenguaje c#
    y la mayoria necesita un lenguaje para usarlo como herrramienta y no tener que mejorar
    cada cosa que tiene

    ya me desahogue, ahora si volvamos...
    si alguien puede orientarme con que hacer para mejorar la velocidad de interfaz grafica y
    evitar parpadeos, o evitar consumo de memoria se lo agradezco enormemente

    el problema es que mi misma aplicacion anda en un server 2003 y en otro server 2003 no
    en ese que no anda me da el sigueinte error:
    "Error Espacio insuficiente para completar esta operación", este error
    me sale en una ventana que tiene como titulo "Framework"

    entonces viene mi duda y todas las sugerencias que recibo son que no consuma tantos recursos,
    pero no entiendo proque si la aplicacion anda en un sempron 2.8 con 1 gb o 256 de memoria
    y anda perfecto porque en un server con 4 gb de ram, disco de 500 gb no funciona y
    larga ese error, ademas del parpadeo
    en el otro server tambein tiene las mismas caracteristicas fisicas y anda perfecto

    para mi sinceramente no consumo tantos recursos como programador, sera net el que consume
    solito los recursos con su forma de trabajar graficamente,
    pero si tengo una libreria enorme para usarla y no la
    puedo usar porque me consume recursos, para que la crearon?

    Saludos

    pd: perdonen por mi indignacion a los fanaticos de c# pero si tengo que escribir dos millones de lineas para que algo ande mas o menos veloz como lenguajes anteriores como fox, es para pensarlo o para decir que todavia le falta mucho para ser una herramienta usable profesionalmente en aplicaciones en serio y no en ejemplos simples para enseñar temas de programacion

    igualemente me sigo quedando con c# a los otros lenguajes pero me gustaria que solucionen esos problemas en los controles base y no que un programador tenga que andar aprendiendo system.drawing para poder arreglar un control, esa no es mi finalidad por lo menos, sino poder producir un sistema final usable

    aclaro que es mi opinion personal, no es la verdad absoluta para nada, solo una opinion personal de acuerdo a mis capacidades y mis oportunidades, capaz qu si fuera un mvp, desarrollador 5 estrellas y seria un capo todo seria mas facil seguramente

    saludos de nuevo

     

     

     

     

     


    programador
    jueves, 7 de octubre de 2010 14:11

Todas las respuestas

  • Es cierto, hay que tener muchas cosas en cuenta con cada control que se implementa...

    Con el tema de las imágenes, yo pasaría del tema doblebuferesd, a mí me pasaba lo mismo porque cargaba las imágenes en tiempo de diseño y me crecía también el ejecutable; he conseguido acelerar muchísimo la velocidad de trabajo desde que cargo las imágenes en tiempo de ejecución desde una ruta con las imágenes guardadadas.

    En el tema do los datasets he oido que el problema son los datagridviews, que funcionan eficientemente con hasta 100 filas, después todo se desmorona. Intenta aplicar filtros a tope y subtablas con relaciones para intentar disminuir el número final de filas. Otro truco de velocidad en desasignar temporalmente el binding del datagrid durante el proceso del update.

    Es cierto, hay que tener muchas cosas en cuenta con cada control que se implementa... yo intenté desahogarme también, pero como me interesa que todo funcione y valla rápido, no me queda otra que implementar, implementar e implementar. UN SALUDO


    UN SALUDO. UN PROBLEMA SUELE TENER MÁS DE UNA SOLUCIÓN.
    jueves, 7 de octubre de 2010 20:19
  • gracias por los consejos roberto, imaginate un programador a penas de fox de un dia para el otro que tenga que andar sabiendo dos millones de cosas para hacer un abm que en otros lenguajes es cuestion de dos patadas, veo que este lenguaje net si deja mas abierto a cada desarrollador hacer lo que quiera con los controles o lo que pueda mejor dicho, y como vos decis, implementar, implementar, implementar... para que un exe ande parecido a un exe de fox o visual basic

    ahora con toda la potencia de  hardware que hay, de arranque con 4 gb de memoria, discos de mas de 300 gb, micros nuevos y que mi aplicacion se reviente proque cargue 10, 20, 30 imagenes, me parece que el recolector de memoria esta de paro, veo qeu avanzamos en tecnologias pero no en rendimiento, cada dia todo cuesta mas tiempo hacerlo y mas y mas hardware, al final voy a pensar que lo mejor era un sistema en dos, porque para mi la tecnologia es hacer cosas que rindan mas y con menos recursos, no hacer cosas que consuman mas para hacer lo msimo que hace otra que consume menos, yo trabajo algo de fox, he visto aplicaciones visual basic de colegas y no quieren saber nada de net pro el motivo de rendimiento

    pones un maquinon y poruqe en el proyecto usaste un par de dll ya se revienta, algo debe andar mal, igualemente muchas gracias por el consejo y voy a probar, no me queda otra

    saludos  


    programador
    jueves, 7 de octubre de 2010 20:55