Drawing & Painting in Wisej.NET

Drawing and Painting in Wisej.NET opens with a decision that comes before any drawing code: where the pixels are actually produced. In this module a single telemetry reading is shown on four different surfaces of Visual Operations Studio, so you can compare them side by side.

Asking an application to draw a number is not one requirement but four. A dial on a dashboard, a small indicator inside a grid cell, a node on a topology map and an image written to a report file all present the same value, yet each is produced somewhere different and each sends something different to the browser.

A Paint handler runs on the server, and the finished picture travels to the browser as an image. Cell painting does the same work, confined to the bounds of one grid cell. A Canvas behaves differently: it sends drawing commands that the browser executes for itself. Off-screen rendering produces image bytes that no control ever displays.

In the page, all four surfaces read one telemetry sample field, so none of them owns the value. One button changes that field and refreshes each surface in its own way: the label and the progress bar simply read it, the painted panel is invalidated so the server repaints it, the Canvas scene method runs again, and a fresh off-screen image is produced.

Custom painting belongs at the end of a decision ladder, not the beginning. Reach for a standard control first, then ordinary markup, and only then a Paint handler, a painted cell or a Canvas. Off-screen rendering follows those, and a drawing loop running in the browser is reserved for the cases where the frame rate genuinely matters.

Redrawing a Canvas means clearing it and rebuilding the whole scene from the model, because the browser's copy is not something the server can depend on. The off-screen renderer sits at the opposite extreme: a bitmap, and a graphics surface created over it, are enough to produce an image with no control involved at all.

Run the page and press New reading. The same number appears in all four places at once, which makes it look like a single operation. It is not. Each surface has just put something quite different on the network to arrive there, and that difference is what this module is really about.

Now resize the browser window. Three of the surfaces return on their own, because the server still owns what they display. The Canvas comes back empty, and stays empty until the redraw method reconstructs it from the telemetry sample the server kept. That asymmetry is the practical consequence of the boundary.

In the first lab you build this page yourself: one model behind four surfaces, a single button that refreshes all of them, and a short note recording what crosses the network for each surface and which visuals survive a resize.

This module builds a painted control properly. The telemetry gauge draws a ring, its threshold zones, a needle and a numeric reading, and every one of its public properties clamps what it is given before deciding whether a repaint is needed at all.

Your paint code runs on the server, and the browser receives the resulting image. That is convenient, and it is also why a handler copied into six panels is expensive: six pictures are produced, six sets of drawing objects are created, and repaints happen that nobody asked for.

So measure first, then draw. The geometry helper takes a rectangle and returns the ring bounds, the sweep angles, the needle points and the rectangle the label sits in. It is ordinary arithmetic with no drawing in it, which means you can test the hard part without ever creating a control.

Every property setter follows one recipe: clamp the incoming value, compare it with the current one, return immediately when nothing has changed, assign it, and invalidate exactly once. The same line of code refreshes the accessible description, so the reading stays available as text and not only as pixels.

The handler guards against a zero-sized clip rectangle, calls the measuring step once, and then draws. Five using declarations cover the five objects this code creates and therefore owns. The graphics surface handed to you in the event arguments is not one of them, and disposing it would be a mistake.

Ownership settles most of the awkward questions. Framework brushes and pens are shared and must be left alone, a static pen of your own is unsafe once several sessions paint at the same time, and a database call, a font load or a timer has no business inside a paint path.

Watch it run. One reading moves, so one gauge invalidates and one picture is produced. The other two setters compared their values and returned early, which is the whole point. A resize then rebuilds each picture from the new clip rectangle, at the new size.

Then comes the budget: processor time on the server, memory for the temporary bitmap, and the bytes sent for every repaint. When those numbers stop justifying the pixels, a themed control is the better answer. Either way, the values themselves must stay readable as text.

In the second lab you build the gauge and its pure geometry helper, guard a zero size and an inverted range, publish the reading through the accessible description, and record the cost of a repaint in your own notes.

In this module the grid does the drawing. Visual Operations Studio is now showing a thousand machines, and two of its columns have to be readable at a glance rather than one number at a time.

There are three ways to get there. A bound number that nobody scans is honest but useless. A gauge control in every row is readable and ruinous, because that is a thousand server-side controls alive in one session. The third option is a cell that paints itself, and only while it is actually visible.

User painting always comes before cell painting: a cell or an entire column is switched into user-painted mode, and only then does the grid raise its cell paint event for it. The event arguments derive from the ordinary paint arguments, so they carry the graphics surface and the clip rectangle, and they add the row and column indexes you need for routing.

One difference matters more than the rest. The Wisej.NET event arguments carry no helpers for painting the background or the content, so your handler is responsible for everything that appears in that cell. Copying a Windows Forms example straight across will not work. Subscribe once on the grid and switch on the two columns you own.

Guard before you draw. A negative row index is a header rather than a data row, and a column you do not own returns immediately. Only then take the geometry from the clip rectangle and read the values you need, in a single step, from the object the row is already bound to.

Running it, six visible rows produce twelve calls into the handler: a threshold-coloured bar for health, and a small line chart for the trend. The selected row is drawn with its own colours, because a painted cell that ignores selection looks broken the moment somebody clicks it.

Now scroll through the thousand rows. Every newly visible cell calls the handler again, which turns the handler into a hot path. That is why there is no file or database access in it, no fonts or images created per cell, and why reading a row's values must stay a constant-time step.

Then make the honest comparison. Cell markup wins for text, icons and accessibility. Painting wins for geometry that markup cannot express. And a real cell type wins whenever the user has to interact with the cell rather than only read it.

In the third lab you build two painted columns behind one guarded handler, read each row's values in a single step, then build the same status indicator again as a markup cell and write down which of the two you would actually ship.

Visual Operations Studio now needs a real drawing surface. The Wisej.NET Canvas gives you the browser's two-dimensional drawing context from C#, with one condition attached: it remembers nothing for you.

Paint and cell painting both send a finished image, and the server knows what that image contains. A Canvas sends drawing commands that the browser carries out instead. Nothing is retained on the server, and a resize can wipe the result, so the scene has to exist somewhere you control.

Translating a browser example takes three passes. Adjust the casing, because the members are the familiar ones in the C# convention. Replace the style strings with .NET types such as colours and fonts. Convert angles from radians to degrees. Then confirm the member actually exists, rather than assuming everything from the browser was carried over.

The redraw event calls exactly one method. That method opens by clearing the whole surface, and every shape begins a new path before it draws. Skip that step and a later stroke drags the previous outline along with it, which is one of the most common ways a translated example goes wrong.

Text is positioned with the alignment and baseline properties rather than measured, because the measuring call from the browser is not part of the documented surface. Gradients are objects in their own right: you build one, then assign it as the fill style, instead of describing it inline each time.

Every transform sits between a save and a restore. So does the clipping region, so does the transparency, and so do the dash pattern and the shadow, because all of them are Canvas state rather than arguments to a single call. Bracketing them keeps one section from leaking into the next.

Five sections are issued together in one update, because live update stays off by default. Turn it on only when a long server-side operation should reveal its progress as it works. It is not a way to animate, and a request for every frame is the wrong architecture.

Two failures are worth seeing deliberately. Resize the surface and it goes blank until the redraw rebuilds it from the model. Remove one restore call and everything drawn afterwards drifts out of place. Neither of them shows up in the designer, which is exactly why they cost so much time.

In the fourth lab you draw the entire playground from one method called by redraw, bracket every transform, add a clip, a transparency section, a dash and a shadow, and port a browser example measured in radians to the degrees the Wisej.NET rotate call expects.

The Canvas forgets, and the model must not. In this module the playground from the previous module becomes a topology editor with selection, dragging, panning and zooming, and every one of those gestures has to survive a redraw.

A rectangle in the browser is not a pump. The meaning lives in the scene object on the server: the nodes, the edges, which one is selected, where the viewport sits. Input changes that state, and a single render method turns the state into drawing calls. The renderer never decides anything.

Rendering converts world coordinates to screen coordinates by applying the zoom and then the pan offset. Hit testing has to run that conversion backwards, taking the pointer position back into world coordinates before comparing it with a node. The Canvas offers no point-in-path test to lean on, so this arithmetic is yours.

Start from the model. Nodes and edges carry stable identifiers and their own geometry, and the scene that holds them lives per session, never in a mutable static field that every user would share. The hit test walks the list backwards, so the node drawn last, and therefore on top, is the one the user gets.

The three pointer handlers do very little. Mouse down converts and hit-tests, mouse move drags the selection or pans the viewport, mouse up ends the gesture. Each of them changes state and then calls the one render method. The redraw event calls that same method, which is why a resize simply rebuilds the scene.

When redrawing costs too much, work down a ladder: fewer primitives first, then skip what is off-screen, then simplify the geometry, then cache the layers that rarely change. Moving the loop into the browser is the last step, not the first, and live update stays off for the main render.

In the browser the click is converted into world coordinates, finds the second pump, marks it selected and renders. Watch the request counter climb while you drag. That number is what a server-side drag genuinely costs, and it is the measurement that tells you when to stop.

Zoom about the pointer and selection still lands on the right node, because the inverse conversion accounts for the new zoom. Nodes outside the visible rectangle are skipped entirely. And the tab key with the arrow keys reaches every node, so the editor does not require a mouse to be usable.

In the fifth lab you build the per-session scene, hit-test in world coordinates, keep all three handlers calling one render method, cull what is off-screen, add the keyboard path, and record the point at which you would move the interaction into the browser.

This module produces a file rather than a screen. Operations want the same topology as an image they can keep, generated on a server that has no graphics subsystem of the traditional kind underneath it.

None of the previous three surfaces can do that, because each needs a live control and a live session. The obvious library is ruled out as well: Microsoft made its classic drawing package Windows-specific from .NET 6, and the switch that re-enabled other systems was removed in .NET 7.

Three names describe one thing, and keeping them straight saves an afternoon. The package you reference is the managed distribution, the assembly on disk is the managed drawing library, and the namespace your code uses is the familiar one. It is a managed rendering engine, not a wrapper over the platform's own graphics layer.

The renderer takes a scene and an output size and returns bytes. It creates a bitmap, obtains a graphics surface over it, draws the edges, the nodes and the labels with pens, brushes and a path, and saves the result into a memory stream as a portable network graphic. No control appears anywhere in it.

The platform matrix is worth memorising. Font measurement is managed everywhere. Drawing is managed on modern .NET on every operating system, and falls back to the platform layer on the .NET Framework and inside the designer build. Never pin a cross-platform deployment to a Windows-only target framework to make a drawing problem go away.

Two decisions then determine whether this survives deployment. Resolve the font through a chain that ends in something you ship yourself, rather than assuming a font exists on the host. And keep exactly one drawing implementation in the reference graph, because two of them resolving the same type names is a problem you will not enjoy diagnosing.

Run it. The export renders off-screen in about thirty-four milliseconds with no control involved, and the bytes are handed to the browser as a download. Bound the requested size, though: a bitmap four thousand pixels wide by three thousand high costs roughly forty-eight megabytes before you have drawn anything.

Now the container. The same test passes on Linux, nothing is linked against the platform's native graphics library, and the two images come out byte for byte identical, because the font was shipped with the application rather than borrowed from the host.

In the sixth lab you build the control-free renderer, give it a font fallback chain, download the image from the page, check the references for a second drawing implementation, and record your Windows and Linux evidence along with what it implies for the mobile and desktop targets.

This is the capstone. Six modules have built four rendering surfaces in Visual Operations Studio, each one correct on its own. Shipping them means making them agree with each other, and proving that they do.

At the moment every surface keeps its own thresholds, its own colours and its own idea of where things sit. Move the warning line once and the exported image quietly contradicts the screen it was generated from. That is not a rendering bug; it is four copies of the same business rule.

The remedy is three layers. A visual model holds semantic state: values, statuses, selection. A geometry layer turns that state and a size into shapes, and it is pure arithmetic. Then one renderer per surface, each keeping the primitives that suit it, because forcing them through a shared interface helps nobody.

Next, agree on numbers before you optimise anything. A painted control should stay under about five milliseconds. A full Canvas redraw belongs in the range of sixteen to fifty milliseconds. An export is allowed to be slower than either, provided it never blocks another user's session while it runs.

The geometry call takes the model and a size and returns shapes, and both renderers call it, so neither can drift. Around them, a small metrics helper records how long a render took, how large the output was, and how many scene objects were actually drawn. Without those three numbers, tuning is guesswork.

Then draw the bad states deliberately. Empty data, a surface with no size, a range whose minimum exceeds its maximum, a font that is missing: each one should degrade to something readable rather than throw. And a failed export should reach the user as a message, not as a blank space where a picture was expected.

One value changes and all four surfaces follow it: the painted gauge, the painted cells, the Canvas topology and the exported image. Beside them sits a plain table listing every reading, which is what makes the information available to somebody who cannot use the graphics at all.

Finally the evidence. The painted gauge came down from about eleven milliseconds to four, the export from roughly three hundred and ten milliseconds to a hundred and twenty-eight, and the test matrix covers Windows, Linux, the hybrid targets and three browsers. A measured decision not to optimise counts too, as long as it is written down.

The final lab is the capstone: one model behind all four surfaces, a metrics helper, one optimisation you measured before and after, four degraded paths that fail gracefully, and the notes that explain the architecture and the boundary it respects.