Choosing SkiaControls to display a game that is mainly a "Game Level" map plus HUD overlay with interactive elements.

[ToolmakerSteve]

Most of game takes place on a Bird's-Eye View scrollable and zoomable map. Orthographic "Fake 3D" composed of many small images.
Most user actions are by touching something on the map.

But also, along the bottom, top, and sometimes popping in from corners or edges, are various interactive UI. Think "HUD overlay".
These interactive widgets I currently draw with Maui (all in c# markup - no XAML).
I decided to eliminate the use of Maui rendering; do everything in SkiaSharp.
I didn't want to reinvent the wheel; searched for SkiaSharp-based interactive widgets.
I found nothing even remotely decent. Until I saw the youtube of DrawnUI.
This is way more than I dreamed of. Simply Awesome.

I have a rough idea of how to architect this in DrawnUI. Seeking feedback.

---

Think of the map as tile-based, though the tiles overlap, and are not on a rectangular grid.
The map will be a custom control. Most of the game logic revolves around user touching somewhere on the map, resulting in feedback directly on the map, followed by movement of player-controlled units (game pieces) and AI-controlled units.

In addition to these units, there are many small features that are part of the map world, that may appear or disappear.
I'll treat both the units and the changeable features as sprites.

There may be hundreds of small sprites on the map. Most of the time, most will not be moving. But sometimes there are many moving at once. Movement is slow; sprites are generally just moving from one tile to the next, or perhaps battling at edge between two tile-centers. Or appearing/disappearing with some animation.

For performance, I plan to "snapshot" sprites that rarely appear/move/disappear, along with the dynamically composed map behind them.

Moving sprites may need to visually move behind snapshotted sprites; because many sprites might move at same time, I'll likely just redraw any snapshotted sprites that overlap any of the moving sprites.

The back-to-front rendering while sprites are moving is:

• copy fullscreen "snapshot" of "behind" stuff that is not moving during this animation;
• render all moving sprites plus any stationary sprites that are "in front of" any moving one;
• (optionally) render rectangles as needed from a snapshot of "foreground" stuff that is not moving.
• Then render a snapshot of all HUD elements. Grouped into a small number of rectangles around the map, sometimes overlapping some of the map. (delineated from map by semi-transparent transition area or blurred glass that fades out.)
  If HUD blocks anything user wants to see, they can pan the map a bit.

Primary target: lightweight tablet.
But I'll make it work everywhere else also. Thus, .Net 8+ as platform.
SkiaSharp, to "render everywhere".

Maximizing battery life is important.
But maximizing developer productivity, and minimizing time to market, are more important.

---

After spending a day looking at code and demos, this is my best guess at how to structure this:

• App opens MainPage (no Shell).

MainPage : ContentPage
	draw:Canvas
		MyGame : MauiGame
			ZoomContent
				MyGameMap : SkiaControl or SkiaLayout? *
			MyHUD : SkiaLayout

• Sprites should be children of MyGameMap, because they Zoom with Map?

---

Some questions:

1. Do I need an explicit draw:Canvas element? Or is that handled by some other DrawnUI class? In my previous approach, I have an SKCanvasView for Skia PaintSurface and Touch.
2. Should MyGameMap, which is my screen-filling custom control, be a SkiaControl, SkiaLayout, or something else?
3. ZoomContent needs to zoom MyGameMap and all the sprites. I think sprites are children of MyGameMap, because it manipulates them. Make sense?
4. I'm unclear on relationship between MyGame : MauiGame and MyGameMap. Currently MyGame is an invisible wrapper, to hold the ActionOnTickAnimator and GameLoop-related stuff. Should I try to minimize the number of levels in the hierarchy, incorporate that into MyGameMap somehow?

All feedback and suggestions welcome :)

[taublast]

Hey,
I would see 2 ways here:

Way 1. Reuse your existing rendering code to go along with drawnui HUD and other layout stuff. This is easy, just need to create a custom SkiaControl-subclassed control that would wrap your existing rendering logic. Examples of that are:

• MapsUi control https://github.com/taublast/DrawnUi.Maui/blob/main/src/Addons/DrawnUi.Maui.MapsUi/src/SkiaMapsUi.cs
• SkiaGraphics control https://github.com/taublast/DrawnUi.Maui/blob/main/src/Addons/DrawnUi.MauiGraphics/SkiaGraphics.cs

Here we have an existing code that was using SkiaSharp that integrates into drawnui layout system with minimal effort.

Way 2. Create an optimized drawnui game with custom controls appropriate for a specific game.

Actually thinking of the following:

1. skiascroll already supports multidirectional scrolling:

Sandbox_yCQH7mUbIS.webm

It supports also zooming (gestures and mousewheel) and we know that canvas works fine with keyboard for desktop. When using a preview skiasharp3 version you can already have hardware acceleration for WinUI, it makes a huge difference if you need Windows.

2. A custom control skiatiles was created for spaceshooter (https://github.com/taublast/AppoMobi.Maui.DrawnUi.SpaceShooter) for repeating tiles. I was thinking of creating a control for drawing sprites too but wasn't needed as was using lottie so.. But its easy. So this brings that a custom control for drawing tiles/sprites to be drawn inside such scrollview might be a good and doable choice. At the same time scrollview can render using virtualization, so it will only render what is visible in the viewport, saving memory and cpu/gpu.

Didn't totally catch if you had an existing code already or building from zero.. I you have existing code you could start with path Nb1 for a fast proof of concept. Then when you could spend more time optimizing on the path Nb2.

So in path nb 1: can take spasehooter code, delete content inside the canvas and place a custom control wrapper for the existing code. Could help with the wrapper np.

For the path nb 2: Almost same, just instead of the wrapper would come:

<draw:Canvas>
<game:MauiGame>

<skiascroll>
   <myworld/>
</skiascroll>

<myhudwhatever/>

</game:MauiGame>
</draw:Canvas>

That myworld would be a subclassed skialayout, to place/manage sprites inside.

A very important point is that drawnui already comes with a caching system, that has to be used for scrolling to be smooth while content is animated and avoid using usual gavedev tech like "save background" "blit", "restore background" "blit elsewhere"..

Might have not much time this month, but still could help: only use-cases make this engine develop and get rid of bugs so I'll follow :)

[ToolmakerSteve]

Good. I'll work the next couple of days trying out the approach you suggest.

Will post here as I make progress, or want to know how to fit with the DrawnUI classes you mention.

DrawnUI's caching is a strong point, that very much appeals to me. I haven't worked on that aspect yet. Just had a concept of what I need to do.

---

I have existing code that renders map tiles and game units, user can touch map, stuff happens. Lots of methods that make SkiaSharp calls. Looks like a rough prototype of my game. Can "play the game", though its only 10% there. Almost fun :)

I have c# classes such as Map, Tile, and GameUnit, with Draw methods.

But no optimization. No dirty flags. No snapshots of what isn't moving. Every detail is rendered every frame.

Can't pan/zoom.

UI widgets are minimal, and done in a Maui panel along the bottom.

Enough of a prototype to feel good about the game concept.

Now I am ready to put this into a polished form.

[ToolmakerSteve]

Way 1 sounds like what I had in mind to start. Benefits I seek ASAP:

• HUD overlay.

• Only render sprites that are visible on screen. I already tell sprite an origin and scale. Just add visible rectangle, and sprite can decide if it overlaps.

• Pan/Zoom of larger than screen map.

• Pre-draw the map into a separate bitmap, rather than redraw every tile every frame. Because tiles may have several overlapping layers, this should speed up a lot. Sounds like scrollview has caching that will help when I decide to be more efficient, or to handle larger map.

---

FUTURE:
My map content unfortunately has a lot of overlap; can't easily/efficiently break it into many small recyclable cells.

I see how to do infinite map scrolling using a single bitmap.
Without having to "slide" the existing pixels w/i the bitmap, as scroll.
OTOH, these days that is quick enough, that maybe everything below here is moot.

Ignore below description; I just don't want to delete it completely:

As map scrolls, new area is drawn only in a thin vertical strip and a thin horizontal strip, that is initially offscreen.  
Where those strips are, "moves" across the bitmap as pan.  

Consider real-world map with large grid laid over it.  
Result is large squares (grid cells), each of which will contain many of my small tiles.  
My small tiles are not on a regular pattern; some will cross grid lines, must render into 2 or 4 large cells.  
[Also need this 2/4 rendering, to snapshot stationary objects that may be positioned at any pixel.]
The bitmap acts like a viewport-sized background that repeats as scrolls. Such an image can be rendered to a viewport, at any scroll position, in up to 4 bitmap draws.
BUT each "repetition" is actually data from the next large grid cell in that direction.
Bitmap enough larger than visible area, to handle what is needed as pan/zoom.  
Drawing of stuff from next grid row/column is clipped to the appropriate grid line(s) [cell edges], which fall somewhere within the bitmap.  
[Referring to the edges that are NOT edges between ADJACENT row/column; rather are the far boundaries of the visible area, which we have broken into 4 rectangles that correspond to the 4 bitmap draws needed. Again, think of rendering  a repeating background image.]  
Those invisible grid lines move across the bitmap, to scroll the map.  
The spacing between grid lines grows/shrinks, as zoom in/out of the map.  
[A couple of diagrams would make this much easier to understand.]

A major change in zoom scale requires preparing (in a background thread) a second bitmap. Up or down a power of 2 in scale.

[ToolmakerSteve]

Questions.

---

1. In this xaml fromMainPageScroll (scrolling dungeon map sample). :

<draw:SkiaScroll>

    <draw:SkiaLayout
        UseCache="Image">
        
        <draw:SkiaImage>

Is SkiaLayout there for smoother scrolling?

Feels like it is helping look less jerky, though frame rate is same. Maybe help more on less powerful device?

---

2. Maybe I go straight to Way 2, subclass SkiaLayout. Run all my on-map code there. Especially the sprite drawing.

However, the map itself could be thought of as a double-buffered image.

Consider the XAML above; when an altered map is ready (after any change), I could have SkiaImage take it in the next frame?

Pondering whether SkiaImage gives any benefits. Or since I already have custom code, and have a method that renders everything as needed, I might as well just do it all in the SkiaLayout?

Leaning towards doing everything [except HUD] in my one custom class.
Seems simplest for a first attempt.
Unless there is some good reason to use SkiaImage.

[taublast]

SkiaLayout is the main container inside the SKiaScroll to hold multiple controls if needed.
Otherwise skiascroll can hold only 1 control as child.
For smoother scrolling you see here UseCache="Image", this saves content as 1 rasterized bitmap to be scrolled. But you still can a smooth scrolling without it, for example when children inside are cached insteador the content container has UseCache="ImageComposite" that basically is that game tech it draws only changed area, compositing over unchanged.
Still there are more ways for optimization, depends on whats inside the scroll.

[ToolmakerSteve]

SkiaScroll. How make mouse wheel do zoom?

I found Wheel code in ZoomContent. Comparing the two classes now.

UPDATE Never mind - found out my SkiaScroll has ZoomLocked=true.

[ToolmakerSteve]

I have MyWorld : MauiGame inside SkiaScroll. I override my Draw, can draw on ctx.Canvas.
That is good.
I know scroll is working, because I added a SkiaImage. Which does scroll.
I can even nest SkiaImage as a child of MyWorld; see it scrolling behind my custom drawing. Cool.
BUT what I render in Draw does not scroll. It is at a fixed position.

I need to override something different?
Or apply some transform?
(Not yet trying to cache the map - want to see it draw live.)

UPDATE Never mind - I had stopped looking at dstRect because it was always at (0,0).
Oops - that was BEFORE I scrolled. NOW it has a negative (x,y), indicating the change in origin.
Scroll works!

Then applied "scale" to my logic.
Zoom works!

DOCUMENT this step:

private void _Draw(SkiaDrawingContext ctx, SKRect dstRect, float scale)
{
    SKCanvas c = ctx.Canvas;
    
    // ORIGINAL: Does NOT Scroll or Zoom.
    //c.DrawRect(50, 50, 100, 100, new SKPaint { Color = SKColors.Aqua });
    
    // FIXED: DOES Scroll and Zoom.
    var d = dstRect;
    var s = scale;
    // TODO: In future may be clipped by dstRect. Skip entirely if content completely outside of dstRect.
    c.DrawRect(d.Left + s * 50, d.Top + s * 50, s * 100, s * 100, new SKPaint{ Color = SKColors.Aqua});
}

Just a test of Skia drawing - not my map yet.
Can't sleep now. I see how this works; should be straightforward to add this to my real project.

[taublast]

Hey,
Glad you're progressing!

1. I see a bug in zooming inside a multi-directional scroll, let me fix it today.
2. Please could you elaborate "BUT what I render in Draw"?

Normally if you override a skiacontrol in a usual way your drawing logic must reside inside the Paint override.
Maybe you created a wrapper and this issue is from it? Would you mind sharing some code so I could help?

[taublast]

Hey, Glad you're progressing!

1. I see a bug in zooming inside a multi-directional scroll, let me fix it today.
2. Please could you elaborate "BUT what I render in Draw"?

Normally if you override a skiacontrol in a usual way your drawing logic must reside inside the Paint override. Maybe you created a wrapper and this issue is from it? Would you mind sharing some code so I could help?

Fixing zoom center today failed epically, delayed just a small bit.. :/

[taublast]

I have mentioned a couple of examples of wrappers for maps and skiagraphs, look how its basically done:

• MapsUi control https://github.com/taublast/DrawnUi.Maui/blob/main/src/Addons/DrawnUi.Maui.MapsUi/src/SkiaMapsUi.cs
• SkiaGraphics control https://github.com/taublast/DrawnUi.Maui/blob/main/src/Addons/DrawnUi.MauiGraphics/SkiaGraphics.cs

example maps:

protected override void Paint(SkiaDrawingContext ctx, SKRect destination, float scale, object arguments)
    {
        base.Paint(ctx, destination, scale, arguments); //paint background

        ctx.Canvas.Save();
        ctx.Canvas.ClipRect(destination);
        ctx.Canvas.Translate(destination.Left, destination.Top);
        ctx.Canvas.Scale(PixelDensity, PixelDensity);

        //paint map into the layout area
        CommonDrawControl(ctx.Canvas); <-- maps drawing its control over drawnui canvas

        ctx.Canvas.Restore();
    }

and example 2:

protected override void Paint(SkiaDrawingContext ctx, SKRect destination, float scale, object arguments)
    {
        base.Paint(ctx, destination, scale, arguments);

        if (Drawable != null)
        {
            Canvas.Canvas = ctx.Canvas;

            var viewport = new RectF(0, 0, destination.Width, destination.Height);

            ctx.Canvas.Save();
            ctx.Canvas.Translate(destination.Left, destination.Top);

            Drawable.Draw(Canvas, viewport); // <--- SKiaGraphics drawing over drawnui canvas

            ctx.Canvas.Restore();
        }
    }

So for your case the wrapper might look similar for your own game code drawing over drawnui canvas

[ToolmakerSteve]

I did not know to override Paint instead of Draw.

I looked at those examples, but did not notice that they were using Paint to Render.

Spent more time studying code of DrawnUI controls. In the Engine itself. Lots of Draw overrides there.
Also, SpaceShooter overrides Draw. That is what I copied.

I'll try it with Paint now.

Paint has similar arguments. The difference between the two is unclear to me.

[taublast]

Draw is framework-tenchnical if i may say, used for creating deeply customized controls, while Paint (called by Draw) is acting purely for the drawing logic, "paint and forget", its result will be cached, transformed (and more) by the engine.

[ToolmakerSteve]

ok, good to know.

I've been thinking "close to the metal". Long term I might use Draw.

But sounds like DrawnUI does more for me if I use Paint. I'll give it a try.

[ToolmakerSteve]

Hopefully the "scale" seen by Paint is identical to "scale" seen by Draw.

I have a LOT of small bitmaps. If Paint is seeing a logical scale that differs from Draw, I almost certainly need to make a "deeply customized control". To avoid rescaling as much as possible. I'll live with SkiaScroll handling zoom for now. But think "mip maps" - In the future, I'll want a way to render to nearest power of 2 of the final pixel display.

Thinking about this more. Once the user stops zooming, I definitely want to re-render map at exactly the scale that matches pixels, for current Zoom. 90%+ of the time they are panning instead of zooming. The map needs to look as good as possible, at any scale. This is a "miniature world" with fine details. My current code is designed to render every detail 1:1 with pixels, at any scale. [When devices had lower resolutions, this was avoided by stopping zoom at a scale that exactly matched one of the mip-maps. Less of an issue these days.]

[taublast]

Hopefully the "scale" seen by Paint is identical to "scale" seen by Draw.

I have a LOT of small bitmaps. If Paint is seeing a logical scale that differs from Draw, I almost certainly need to make a "deeply customized control". To avoid rescaling as much as possible. I'll live with SkiaScroll handling zoom for now. But think "mip maps" - In the future, I'll need a way to render to nearest power of 2 of the final pixel display.

They share scale indeed.

[taublast]

Yeah basically speaking inside Draw you have the caching and transform system, so controls that want to change cache themself etc would need to override this, while the total majority of custom control, like labels, images just override Paint.

An example of Draw override, SkiaDecoratedGrid (subclassed SkiaLayout Type=Grid):

    protected override void Draw(SkiaDrawingContext context, SKRect destination, float scale)
    {
        //draw a grid layout as usual
        base.Draw(context, destination, scale);
        
        if (ContainerLines != null)
        {
            //overlay fancy lines between all cells
            ContainerLines.Render(context, GetDrawingRectForChildren(Destination, scale), scale);
        }

        // Execute post drawing operations, like post-animators etc
        // It MUST be called at the end of Draw. We wouldn't need to call it here 
        // if `base.Draw(context, destination, scale);` was invoked at the end but we invoked it at start
        // to draw overlay after the usual base logic
        FinalizeDrawingWithRenderObject(context, scale);
    }
}

[ToolmakerSteve]

Making good progress. My map is scrolling and zooming. Nice to see!

One serious issue. When scroll, MainThread is getting starved.

[I am deliberately not caching anything yet. Each map draw is ~11 ms.]

I know it is starved, because after each draw I queue something on MainThread. With a 1 ms delay, to make sure it won't run "synchronously". Let drawing code unwind, before it runs.
BUT during scrolling, none of those get a chance to run until AFTER scrolling stops.
(Debug messages to console tell me what is happening when.)

Maybe this doesn't happen with proper caching. But it needs to NEVER happen. After each PaintSurface completes, other queued code must get a turn to run.

I don't think my code can cause it - control goes back to DrawnUI.

Any idea what might be the cause?

[Not running my game animator yet. So when scrolling animator is done, it "catches up", finally does everything queued.]

Looking for a cause.

• StartLooperAsync waits 8 ms between each InvalidateSurface.

BUT it doesn't care whether drawing takes longer than that.

Looper's "elapsedMs" is measuring the time of this loop - which doesn't actually draw, so is always negligible. A fraction of a millisecond.

---

HYPOTHESIS: InvalidateSurface every 8 ms is preventing my queued events from running, until scrolling stops.\

WORKAROUND 1: Set TargetFps = 60, instead of 120.
RISK: Any glitch might drop a frame; not maintain 60 fps when it could.
CONFIRMED: My "After Drawing" code runs each frame, doesn't get delayed till end of scroll. Sometimes gets delayed by a frame; then runs twice after second frame. Good enough for now.

---

I just realized something puzzling.

When the scrolling animator is running, there is a PaintSurface (and my Map draw) on EVERY Looper loop. As if it is running synchronously. But even if InvalidateSurface is able to trigger PaintSurface immediately , I would expect 8 ms Task.Delay to give my queued task a turn.

FIXED IT IN MY CODE
I was queueing by Dispatcher.DispatchDelayed:

Dispatcher.DispatchDelayed(TimeSpan.FromMilliseconds(1), action);

The symptom implies those are at a lower priority than Task.Delay.
Changed to:

Dispatcher.Dispatch(async () =>
{   // Allow Paint methods to "unwind", before running my "After Draw" code. [This was needed in my previous version. Maybe can remove now.]
    await Task.Delay(1);
    action();
});

Now my after-draw actions are properly interleaved with looper.

Cranked target up to 500 fps -- looper every 2 ms -- and it never falls behind.

Of course it isn't really running at 500 fps, but everything happens in correct sequence now. Even at that ridiculous setting.

Stress-Test: Success.

[taublast]

• At the current state of MAUI SkiaSharp renderers we are temporarily (until this changes, how life goes might take a year) to rendering on UI thread.
• The looper always has to await a small delay otherwise it will just lock the ui thread and bindings etc will stop working
• You should not use main thread at all while using drawnui, contrary to how we use MAUI native controls. We can do anything, prepare surfaces, modify props, all in background. Again forget about this XF/MAUI restriction.
• Next month i'll have more time to totally switch drawnui to the new skiasharp preview, we will get windows hardware accelerated. This is a game changer:

winskia3.mp4

Here you see how smooth it is on windows with hardware acceleration. On this video we see the bug that was fixed in the latest skiasharp preview, that was present in first previews: lack of antialiasing in windows while accelerated.

• Without caching it's impossible to have complex animations to be smooth, by design. In the current "single threaded" rendering. This would change, again - some day, when we change renderers to all platforms to be able to use hardware acceleration in background, to switch to 2 threads rendering - prepare all in background thread A, render all in thread B in parallel, like in flutter.

[taublast]

Some Tweaking: Scroll / Fling FinalVelocity (when using my slow map drawing).

Two ideas:

• Occasional extreme Fling.
  While lowering MaxVelocity of SkiaScroll does help,
  what works even better is discarding those velocities.
  I verified that the extreme values are from args.Event.Distance.Velocity.
  DrawnUI uses them correctly; sometimes they are just bad.
  With my slow drawing, on a short fling, there might be only 1 or 2 events.
  So a single extreme velocity can cause an extreme average.
• Final Velocity still feels too high, on a short fling, when panning this (sluggish) map.
  Hopefully a non-issue once I cache --
  Seemed fine in the Scroll demo in Sandbox.

You have control over the scrolling and panning feel with skiascroll props:

• FrictionScrolled - use this to control how fast the scroll will decelerate. Values 0.1 - 0.9 are the best, default is 0.3. Usually you would set higher friction for ScrollView-like scrolls and much lower for CollectionView-like scrolls (0.1 or 0.2).
• ChangeVelocityScrolled - For when the finger is up and swipe is detected, default 1.33f
• ChangeDIstancePanned - For when the finger is down and panning default is 0.975f
• MaxBounceVelocity - Limit bounce velocity default 500
• MaxVelocity - default 3000
• AutoScrollingSpeedMs - For snap and ordered scrolling, default 600

[ToolmakerSteve]

You should not use main thread at all while using drawnui

Good to know! I won't worry about this any more. That is what I needed to know.

In my previous version, there was some timing glitch between my Maui UI and the map. Sometimes user would touch a Maui button, and that touch got lost. Not blaming Maui - it was how I was trying to combine SkiaSharp with Maui.

You have a superior approach in DrawnUI.

I can already see this will be great; just wanted to get a feel for any current limits.

[ToolmakerSteve]

You have control over the scrolling and panning feel with skiascroll props:

Thanks. I appreciate knowing what to tweak.

I can see that it is my non-cached drawing that is making the situation bad --
I went back to Sandbox demo, and verified that it works fine there. :)

Hope I don't wear you down with my feedback! I'll learn how to use this well.

[ToolmakerSteve]

What is the correct way to dynamically tell SkiaScroll how big my content is?

It is larger than the viewport. Equivalent of setting ScrollView.ContentSize.

The map size will vary. So is not known until after game is initialized.

UPDATE

I have override Measure. I just need to find call to tell parent to re-measure.

UPDATE #2

Never mind - MyWorld.DrawUsingRenderObject results in call to Measure.

[taublast]

Indeed is measures its content auto, the layout system is designed for a relaxed use all like in usual MAUI. WIth some differences targeting less measurement passes and more control.

Regarding the caching depends on your layout. You could cache every tile inside the grid or better blocks of tiles. for example decide that map that is constructed from tiles, like a grid, and take an design decision to have content constructed from cached SkiaControls each containing 8x8 map tiles. So at the end you cache bitmaps 8x8 and normally only those blocks visible in the viewport would be drawn saving memory and perf. Can experiment with the number, maybe 16x16, dunno, until cache/scroll works great for performance.

And then maybe override the content layout to process AFTER the renderingtree has been built, to process logic/overlay stuff for visible blocks only, that might be more complicated from start but becomes easy after you know how the SkiaLayout rendering works.

[ToolmakerSteve]

I understand. I'm avoiding that complication for now. The map terrain is composed of pieces that don't align with traditional grid. I've written logic before that, given a collection of images to be rendered, figures out which tiles they intersect. So I can render to the set of tiles that are being prepared for the area about to become visible. That project ended for reasons beyond my control. Determined this time to do a project with a small enough scope, and get it far enough, that I know I can make it succeed, before bogging down on those details.

I have confidence now that DrawnUI will do what I need. Even in its current state, it significantly helps what I have. The multi-year disaster that was Xamarin Forms makes me very cautious now!

In my opinion, DrawnUI is the missing piece that MAUI sorely needs.
Check StackOverflow - https://stackoverflow.com/tags/maui/topusers - before I stopped trying to help MAUI succeed, because I still can't in good faith tell my current client that MAUI has a solid future.

Too much time was lost. Too many people have moved on, to React or Flutter.

I can only infer that Microsoft VPs who talk to the VPs at large Enterprises who control budgets of IT departments, get more requests for Blazor enhancements, than for putting development muscle behind having MAUI be a top contender for UI that renders everywhere.

I don't get it myself - but even my day job's small client [not related to my Game] has now asked to be able to make forms for his app in HTML. He's right: relying on coders to make all your app UI is poor practice.

So we are about to switch to Maui Blazor. Assuming it passes my technical evaluation later this year. Is there even a drag-and-drop visual designer for Maui yet? Doesn't matter. Too late. 99% of the world has moved on. Momentum lost. Sad.

[taublast]

My small feeling is that people switching clients to Blazor is the sad but decided Microsoft intention as of today. Blazor is awesome. You would see an enhanced Blazor wrapper in MAUI .net 9, to make it all "Blazor for mobile apps". Then imagine a "we are happy to announce the merging of Blazor and MAUI teams", guess who would be in charge.

[ToolmakerSteve]

I made good progress in using DrawnUI.

My game runs steadily at 30 fps now. On a good pc, without hardware acceleration.
(At 60 fps, Gestures get locked out. Painting consumes all the time. I know that will be a non-issue in the future.)

Watching the really dumb AI play itself.

Can scroll around wildly. Zoom in, scroll some more. Zoom out, see the whole game level. While the AI plays.

Cached the base map, which is stable. Everything overlaid on the map, that could change or move, rendering only for tiles that are visible.
Much more could be cached, but that would be premature.

I have an interface ICanvas that I can switch between the Live canvas (on screen), and my TiledBitmap approach to tiling.
E.g. ICanvas.DrawCircle to TiledBitmap does ActOnTiles(BoundsForCircle(..), Action<Tile, SKRect> action), where action has same parameters as DrawCircle, adjusted for each tile. Sent only to tiles that intersect circle's Bounds (including StrokeWidth).

Not currently being smart about how many tiles are needed. I pre-allocate them to cover the entire game map. Improve that later. I do know which ones are visible, so will be easy to fix.

And from what you've said about improvements coming, this should work well even on weaker devices. I won't put any more into performance until much later in development.

I removed my MAUi widget panel to avoid interfering with performance.

Next, I do what I came to DrawnUI for: implement HUD layer with DrawnUI controls.

[taublast]

Hey sounds godly, glad to hear about the progress!
I guess hardware acceleration would bring that to 60 fps.
How do we remove the MAUi widget panel?