Canvas (re) drawing speed

Bodevinaat

Hi,

I use this code to draw a simple grid in a canvas:

Const BlockWidth As Integer = 10
Const BlockHeight As Integer = 10
Const Space As Integer = 1


G.DrawingColour = Colour.Grey

For I As Integer = 0 To G.Width Step BlockWidth + Space
  For J As Integer = 0 To G.Height Step BlockWidth + Space
    G.FillRectangle(I, J, BlockWidth, BlockHeight)
  Next
Next

I noticed that when eg resizing the window enforces the Paint event the drawing is rather slow. This happens in run and build unfortunately. Is there any chance this will be enhanced in coming releases?

Garry

Hmm. In debug mode on my MacBook Pro it's buttery smooth.

What are the specs of the computer you're using out of interest?

Bodevinaat

Garry Windows 11, Core i7, 32 GB, Nvidia RTX. On this machine a full screen redraw takes 22 ms.

Garry

For this specific grid, you can reduce work massively by drawing a grey background once, then drawing the white gap strips. That makes it roughly columns + rows draw calls instead of columns * rows.

rgb

Garry @Bodevinaat

Hi,
Before draw hit in Graphics Paint event:
Var start As Double = System.TicksMilliseconds

#5 .... your code graphics

Var elapsed As Double = System.TicksMilliseconds - start

Print("Paint Event Elapsed: " + elapsed.ToString("F5") + " ms")

You can see if big difference of time appear

rgb

Bodevinaat

Hi, i confirm when window are fullscreen draw is slow (85 ms in my MacBook Pro)

Using a buffer are good solution for reduce time (for me 14ms now)

Garry

OK. I’ve investigated this and you were right: there was a real performance cliff here.

Internally, Canvas stores drawing commands during Paint and then replays them through Avalonia when the Canvas renders. For this grid example, a large/full-screen Canvas can generate tens of thousands of FillRectangle commands on every repaint. On my machine, a 3236x1990 grid produced about 53,000 rectangle draw commands.

I’ve made a change for the next release so consecutive Graphics.FillRectangle calls with the same graphics state are batched internally before replay. That means this kind of grid still runs the same ObjoBasic Paint code, but Canvas no longer has to replay tens of thousands of separate rectangle commands.

In the benchmark I used, the large 3236x1990 grid improved like this:

Before:

about 53,396 draw commands
Canvas replay time about 22.8 ms

After:

2 draw commands
Canvas replay time about 0.5 ms

So this should be noticeably smoother during resizing/full redraws, especially on machines where the old replay cost was high.

One note: if the drawing is completely static, drawing it once into a Picture and then drawing that Picture in Paint is still a good pattern. But this internal fix should make the direct Canvas approach much more forgiving for repeated filled-rectangle workloads like this grid.

This fix is in the next release: https://feedback.objo.dev/bug/353

Bodevinaat

Garry Thanks for investigating this. Happy to contribute to this great product!

Cheers,

Sander

Bodevinaat

Garry Ok. I checked on a Mac M4. Great performance improvement. I rechecked on a Win Core I5 but there the improvement was not seen. Still very slow. It can’t catch up with the window resizing.

Sander

Ran some tests:

Garry

Thanks, I think you nailed the actual symptom.

The Windows issue was not that the grid drawing code was especially slow in isolation. It was that during live window resizing, Avalonia could ask the Canvas to render at the new size before Objo had finished producing a fresh Paint() command buffer for that size.

Previously, the Canvas filled its newly resized bounds, then replayed the previous drawing commands, which had been generated for the old width and height. That could leave a newly exposed strip visible as white until the next Paint() completed. On macOS that repaint cycle tends to be fast enough that the artefact is not really visible.

The fix now records the size associated with each Canvas command buffer. If a resize-triggered repaint is already pending and Avalonia needs an intermediate render at a different size, the previous frame is temporarily scaled to cover the new bounds. As soon as the new Paint() handler completes, the Canvas returns to exact, unscaled drawing.

The practical result is that the grey grid keeps covering the window edge during drag resize instead of flashing a white border.

The only expected side effect is that during very fast resizing, the Canvas may briefly show a stretched version of the previous frame for a frame or two. That only happens while waiting for the real resize Paint(), and it is immediately replaced by the correct drawing once that paint completes. Explicit Canvas.Refresh() behaviour is unchanged.

This is fixed and marked for the next release: https://feedback.objo.dev/bug/392

Bodevinaat

Great! Looking forward to a new release.

Thx!