Dibujo y pintura en Wisej.NET

Dibujo y pintura en Wisej.NET empieza con una decisión previa a cualquier código de dibujo: dónde se producen realmente los píxeles. En este módulo se muestra una única lectura de telemetría en cuatro superficies distintas de Visual Operations Studio, para que puedas compararlas una al lado de otra.

Pedirle a una aplicación que dibuje un número no es un requisito, sino cuatro. Un dial en un panel, un indicador pequeño dentro de una celda de cuadrícula, un nodo en un mapa de topología y una imagen escrita en un archivo de informe presentan el mismo valor, pero cada uno se produce en otro sitio y cada uno envía algo distinto al navegador.

Un controlador Paint se ejecuta en el servidor, y la imagen terminada viaja al navegador. El dibujo de celdas hace lo mismo, acotado a una sola celda de la cuadrícula. El Canvas se comporta de otra forma: envía comandos de dibujo que ejecuta el navegador. El renderizado fuera de pantalla produce bytes de imagen que ningún control llega a mostrar.

En la página, las cuatro superficies leen un único campo de muestra de telemetría, así que ninguna es dueña del valor. Un botón cambia ese campo y refresca cada superficie a su manera: la etiqueta y la barra de progreso simplemente lo leen, el panel dibujado se invalida para que el servidor lo repinte, el método de escena del Canvas vuelve a ejecutarse y se produce una imagen nueva fuera de pantalla.

El dibujo personalizado va al final de una escalera de decisión, no al principio. Recurre primero a un control estándar, después a marcado normal, y solo entonces a un controlador Paint, una celda dibujada o un Canvas. El renderizado fuera de pantalla viene después, y un bucle de dibujo en el navegador se reserva para cuando la frecuencia de fotogramas importa de verdad.

Redibujar un Canvas significa limpiarlo y reconstruir toda la escena desde el modelo, porque el servidor no puede depender de la copia que tiene el navegador. El renderizador fuera de pantalla está en el extremo opuesto: un bitmap, y una superficie de gráficos creada sobre él, bastan para producir una imagen sin ningún control implicado.

Ejecuta la página y pulsa New reading. El mismo número aparece a la vez en los cuatro sitios, lo que hace que parezca una sola operación. No lo es. Cada superficie acaba de poner en la red algo bastante distinto para llegar hasta ahí, y de esa diferencia trata realmente este módulo.

Ahora redimensiona la ventana del navegador. Tres de las superficies vuelven solas, porque el servidor sigue siendo dueño de lo que muestran. El Canvas vuelve en blanco, y sigue en blanco hasta que el método de redibujado lo reconstruye desde la muestra de telemetría que guardó el servidor. Esa asimetría es la consecuencia práctica de la frontera.

En el primer laboratorio construyes esta página tú mismo: un modelo detrás de cuatro superficies, un único botón que las refresca todas y una nota breve que registra qué cruza la red por cada superficie y qué visuales sobreviven a un redimensionado.

Este módulo construye un control dibujado como es debido. El indicador de telemetría dibuja un anillo, sus zonas de umbral, una aguja y una lectura numérica, y cada una de sus propiedades públicas acota lo que recibe antes de decidir si hace falta repintar.

Tu código de dibujo se ejecuta en el servidor, y el navegador recibe la imagen resultante. Eso es cómodo, y también es la razón de que un controlador copiado en seis paneles salga caro: se producen seis imágenes, se crean seis juegos de objetos de dibujo y ocurren repintados que nadie pidió.

Así que mide primero y dibuja después. El ayudante de geometría recibe un rectángulo y devuelve los límites del anillo, los ángulos de barrido, los puntos de la aguja y el rectángulo donde va la etiqueta. Es aritmética normal, sin nada de dibujo, y eso significa que puedes probar la parte difícil sin llegar a crear un control.

Cada setter de propiedad sigue una misma receta: acota el valor entrante, compáralo con el actual, sal de inmediato cuando nada ha cambiado, asígnalo e invalida exactamente una vez. La misma línea de código refresca la descripción accesible, de modo que la lectura sigue disponible como texto y no solo como píxeles.

El controlador se protege de un recorte de tamaño cero, llama una vez al paso de medición y después dibuja. Cinco declaraciones using cubren los cinco objetos que este código crea y por tanto posee. La superficie de gráficos que llega en los argumentos del evento no es uno de ellos, y liberarla sería un error.

Saber de quién es cada objeto resuelve casi todas las dudas. Los brushes y pens del framework son compartidos y hay que dejarlos en paz, un pen estático propio es inseguro en cuanto varias sesiones dibujan a la vez, y una consulta a base de datos, una carga de fuente o un temporizador no pintan nada en una ruta de dibujo.

Míralo funcionar. Una lectura se mueve, así que un indicador se invalida y se produce una imagen. Los otros dos setters compararon sus valores y salieron antes de tiempo, que es justo de lo que se trata. Un redimensionado reconstruye después cada imagen desde el nuevo rectángulo de recorte, al nuevo tamaño.

Luego viene el presupuesto: tiempo de procesador en el servidor, memoria para el bitmap temporal y los bytes enviados en cada repintado. Cuando esas cifras dejan de justificar los píxeles, un control con tema es la mejor respuesta. En cualquier caso, los valores en sí deben seguir siendo legibles como texto.

En el segundo laboratorio construyes el indicador y su ayudante de geometría puro, proteges el tamaño cero y un rango invertido, publicas la lectura mediante la descripción accesible y anotas el coste de un repintado en tus propias notas.

En este módulo es la cuadrícula quien dibuja. Visual Operations Studio muestra ahora mil máquinas, y dos de sus columnas tienen que leerse de un vistazo, en lugar de número a número.

Hay tres formas de llegar ahí. Un número enlazado que nadie mira es honesto pero inútil. Un control indicador en cada fila es legible y ruinoso, porque eso son mil controles de servidor vivos en una sola sesión. La tercera opción es una celda que se dibuja sola, y solo mientras está visible de verdad.

El dibujo por el usuario va siempre antes que el dibujo de celda: pasas una celda o una columna entera a modo dibujado por el usuario, y solo entonces la cuadrícula lanza para ella su evento de dibujo de celda. Sus argumentos derivan de los de dibujo normales, así que llevan la superficie de gráficos y el rectángulo de recorte, y añaden los índices de fila y columna que necesitas para enrutar.

Una diferencia importa más que las demás. Los argumentos de evento de Wisej.NET no traen ayudantes para dibujar el fondo ni el contenido, así que tu controlador es responsable de todo lo que aparece en esa celda. Copiar tal cual un ejemplo de Windows Forms no va a funcionar. Suscríbete una sola vez en la cuadrícula y bifurca según las dos columnas que son tuyas.

Protege antes de dibujar. Un índice de fila negativo es una cabecera y no una fila de datos, y una columna que no es tuya sale de inmediato. Solo entonces toma la geometría del rectángulo de recorte y lee los valores que necesitas, en un único paso, del objeto al que la fila ya está enlazada.

Al ejecutarlo, seis filas visibles producen doce llamadas al controlador: una barra coloreada por umbrales para la salud y un pequeño gráfico de líneas para la tendencia. La fila seleccionada se dibuja con sus propios colores, porque una celda dibujada que ignora la selección parece rota en cuanto alguien hace clic.

Ahora desplázate por las mil filas. Cada celda que se hace visible vuelve a llamar al controlador, y eso lo convierte en una ruta crítica. Por eso dentro no hay acceso a archivos ni a base de datos, no se crean fuentes ni imágenes por celda, y leer los valores de una fila debe seguir siendo un paso de tiempo constante.

Después haz la comparación honesta. El marcado de celda gana para texto, iconos y accesibilidad. El dibujo gana para la geometría que el marcado no sabe expresar. Y un tipo de celda real gana siempre que el usuario tenga que interactuar con la celda y no solo leerla.

En el tercer laboratorio construyes dos columnas dibujadas detrás de un único controlador protegido, lees los valores de cada fila en un solo paso, después construyes ese mismo indicador de estado otra vez como celda de marcado y anotas cuál de los dos enviarías realmente a producción.

Visual Operations Studio necesita ahora una superficie de dibujo de verdad. El Canvas de Wisej.NET te da el contexto de dibujo bidimensional del navegador desde C#, con una condición: no recuerda nada por ti.

Paint y el dibujo de celdas envían los dos una imagen terminada, y el servidor sabe qué contiene esa imagen. Un Canvas envía en cambio comandos de dibujo que ejecuta el navegador. Nada se retiene en el servidor, y un redimensionado puede borrar el resultado, así que la escena tiene que existir en algún sitio que tú controles.

Traducir un ejemplo del navegador son tres pasadas. Ajusta el uso de mayúsculas, porque los miembros son los de siempre con la convención de C#. Cambia las cadenas de estilo por tipos de .NET, como colores y fuentes. Convierte los ángulos de radianes a grados. Y confirma que el miembro existe de verdad, en vez de suponer que todo lo del navegador se trasladó.

El evento de redibujado llama exactamente a un método. Ese método empieza limpiando toda la superficie, y cada forma abre un trazado nuevo antes de dibujarse. Sáltate ese paso y un trazo posterior arrastrará consigo el contorno anterior, que es una de las formas más comunes de que un ejemplo traducido salga mal.

El texto se coloca con las propiedades de alineación y de línea base, en lugar de medirse, porque la llamada de medición del navegador no forma parte de la superficie documentada. Los degradados son objetos por derecho propio: construyes uno y después lo asignas como estilo de relleno, en vez de describirlo dentro de cada llamada.

Cada transformación va entre un Save y un Restore. También la región de recorte, también la transparencia, y también el patrón de guiones y la sombra, porque todos ellos son estado del Canvas y no argumentos de una sola llamada. Acotarlos así evita que una sección se filtre en la siguiente.

Cinco secciones se emiten juntas en una sola actualización, porque la actualización en vivo está desactivada por defecto. Actívala solo cuando una operación larga de servidor deba ir mostrando su progreso mientras trabaja. No es una forma de animar, y una petición por fotograma es la arquitectura equivocada.

Merece la pena ver dos fallos a propósito. Redimensiona la superficie y se queda en blanco hasta que el redibujado la reconstruye desde el modelo. Quita una llamada a Restore y todo lo dibujado después se desvía de su sitio. Ninguno de los dos aparece en el diseñador, y justo por eso cuestan tanto tiempo.

En el cuarto laboratorio dibujas el área de pruebas entera desde un único método al que llama el redibujado, acotas cada transformación, añades un recorte, una sección de transparencia, un guionado y una sombra, y portas un ejemplo medido en radianes a los grados que espera la rotación de Wisej.NET.

El Canvas olvida, y el modelo no debe. En este módulo el área de pruebas del módulo anterior se convierte en un editor de topología con selección, arrastre, desplazamiento y zoom, y cada uno de esos gestos tiene que sobrevivir a un redibujado.

Un rectángulo en el navegador no es una bomba. El significado vive en el objeto de escena del servidor: los nodos, las aristas, cuál está seleccionado, dónde está el viewport. La entrada cambia ese estado, y un único método de render convierte el estado en llamadas de dibujo. El renderizador nunca decide nada.

El render convierte coordenadas de mundo en coordenadas de pantalla aplicando el zoom y después el desplazamiento. La prueba de impacto ejecuta esa conversión al revés, y devuelve la posición del puntero a coordenadas de mundo antes de compararla con un nodo. El Canvas no ofrece ninguna prueba de punto dentro de trazado, así que esa aritmética es cosa tuya.

Empieza por el modelo. Los nodos y las aristas llevan identificadores estables y su propia geometría, y la escena que los contiene vive por sesión, nunca en un campo estático mutable que todos los usuarios compartirían. La prueba de impacto recorre la lista hacia atrás, así que el nodo dibujado el último, y por tanto el de encima, es el que obtiene el usuario.

Los tres controladores de puntero hacen poco. Al bajar el ratón se convierte y se hace la prueba de impacto, al moverlo se arrastra la selección o se desplaza el viewport, y al soltarlo acaba el gesto. Cada uno cambia el estado y llama al único método de render. El redibujado llama a ese mismo método, y por eso un redimensionado reconstruye la escena.

Cuando redibujar cuesta demasiado, baja por una escalera: primero menos primitivas, después descarta lo que queda fuera de pantalla, luego simplifica la geometría y después guarda en caché las capas que casi no cambian. Llevar el bucle al navegador es el último paso, no el primero, y la actualización en vivo sigue desactivada para el render principal.

En el navegador el clic se convierte a coordenadas de mundo, encuentra la segunda bomba, la marca como seleccionada y renderiza. Mira cómo sube el número de peticiones mientras arrastras. Esa cifra es lo que cuesta de verdad un arrastre en el servidor, y es la medición que te dice cuándo parar.

Haz zoom alrededor del puntero y la selección sigue cayendo en el nodo correcto, porque la conversión inversa tiene en cuenta el nuevo zoom. Los nodos fuera del rectángulo visible se descartan por completo. Y la tecla de tabulación con las flechas alcanza todos los nodos, así que el editor no exige un ratón para ser usable.

En el quinto laboratorio construyes la escena por sesión, haces la prueba de impacto en coordenadas de mundo, mantienes los tres controladores llamando a un único método de render, descartas lo que queda fuera de pantalla, añades la vía de teclado y anotas cuándo llevarías la interacción al navegador.

Este módulo produce un archivo en lugar de una pantalla. Operaciones quiere la misma topología como una imagen que puedan conservar, generada en un servidor que no tiene debajo ningún subsistema gráfico del tipo tradicional.

Ninguna de las tres superficies anteriores puede hacerlo, porque cada una necesita un control vivo y una sesión viva. Y la biblioteca obvia también queda descartada: Microsoft hizo su paquete de dibujo clásico específico de Windows desde .NET 6, y el interruptor que lo reactivaba en otros sistemas desapareció en .NET 7.

Tres nombres describen una sola cosa, y tenerlos claros te ahorra una tarde. El paquete que referencias es la distribución gestionada, el ensamblado en disco es la biblioteca de dibujo gestionada, y el espacio de nombres que usa tu código es el de siempre. Es un motor de renderizado gestionado, no un envoltorio sobre la capa gráfica de la plataforma.

El renderizador recibe una escena y un tamaño de salida y devuelve bytes. Crea un bitmap, obtiene sobre él una superficie de gráficos, dibuja las aristas, los nodos y las etiquetas con pens, brushes y un trazado, y guarda el resultado en un flujo de memoria como PNG. No aparece ningún control por ninguna parte.

Memoriza la matriz de plataformas. La medición de fuentes es gestionada en todas partes. El dibujo es gestionado en el .NET moderno en todos los sistemas operativos, y recae en la capa de la plataforma en .NET Framework y en la compilación del diseñador. Nunca ates un despliegue multiplataforma a un destino solo de Windows para quitarte de encima un problema de dibujo.

Dos decisiones deciden después si esto sobrevive al despliegue. Resuelve la fuente mediante una cadena que termine en algo que entregues tú mismo, en lugar de dar por hecho que la fuente existe en el host. Y mantén exactamente una implementación de dibujo en el grafo de referencias, porque dos de ellas resolviendo los mismos nombres de tipo son un problema que no disfrutarás diagnosticando.

Ejecútalo. La exportación se renderiza fuera de pantalla en unos treinta y cuatro milisegundos sin ningún control implicado, y los bytes se entregan al navegador como una descarga. Eso sí, acota el tamaño pedido: un bitmap de cuatro mil píxeles de ancho por tres mil de alto cuesta unos cuarenta y ocho megabytes antes de haber dibujado nada.

Ahora el contenedor. La misma prueba pasa en Linux, nada se enlaza con la biblioteca gráfica nativa de la plataforma, y las dos imágenes salen idénticas byte a byte, porque la fuente viajó con la aplicación en lugar de tomarse prestada del host.

En el sexto laboratorio construyes el renderizador sin controles, le das una cadena de reserva de fuentes, descargas la imagen desde la página, revisas las referencias por si hay una segunda implementación de dibujo y registras tus evidencias de Windows y de Linux junto con lo que implican para los destinos móviles y de escritorio.

Este es el proyecto final. Seis módulos han construido cuatro superficies de renderizado en Visual Operations Studio, cada una correcta por su cuenta. Entregarlas significa ponerlas de acuerdo entre sí, y demostrar que lo están.

Ahora mismo cada superficie guarda sus propios umbrales, sus propios colores y su propia idea de dónde va cada cosa. Mueve una vez la línea de aviso y la imagen exportada contradice en silencio a la pantalla de la que salió. Eso no es un fallo de renderizado; son cuatro copias de la misma regla de negocio.

El remedio son tres capas. Un modelo visual guarda el estado semántico: valores, estados, selección. Una capa de geometría convierte ese estado y un tamaño en formas, y es aritmética pura. Y después un renderizador por superficie, cada uno conservando las primitivas que le van bien, porque forzarlos a través de una interfaz común no ayuda a nadie.

Después, fija las cifras antes de optimizar nada. Un control dibujado debería quedarse por debajo de unos cinco milisegundos. Un redibujado completo del Canvas pertenece al rango de dieciséis a cincuenta milisegundos. Una exportación puede ser más lenta que cualquiera de los dos, siempre que nunca bloquee la sesión de otro usuario mientras se ejecuta.

La llamada de geometría recibe el modelo y un tamaño y devuelve formas, y los dos renderizadores la llaman, así que ninguno puede desviarse. A su alrededor, un pequeño ayudante de métricas registra cuánto tardó un render, cuán grande fue la salida y cuántos objetos de escena se dibujaron realmente. Sin esas tres cifras, ajustar es adivinar.

Después dibuja los estados malos a propósito. Datos vacíos, una superficie sin tamaño, un rango cuyo mínimo supera al máximo, una fuente que falta: cada uno debería degradar a algo legible en lugar de lanzar una excepción. Y una exportación fallida debería llegar al usuario como un mensaje, no como un hueco en blanco donde se esperaba una imagen.

Un valor cambia y las cuatro superficies lo siguen: el indicador dibujado, las celdas dibujadas, la topología en Canvas y la imagen exportada. Junto a ellas hay una tabla sencilla que lista cada lectura, y eso es lo que pone la información al alcance de quien no puede usar los gráficos en absoluto.

Por último, las evidencias. El indicador dibujado bajó de unos once milisegundos a cuatro, la exportación de unos trescientos diez milisegundos a ciento veintiocho, y la matriz de pruebas cubre Windows, Linux, los destinos híbridos y tres navegadores. Una decisión medida de no optimizar también cuenta, siempre que quede por escrito.

El laboratorio final es el proyecto final: un único modelo detrás de las cuatro superficies, un ayudante de métricas, una optimización que mediste antes y después, cuatro rutas degradadas que fallan con elegancia y las notas que explican la arquitectura y la frontera que respeta.