Replies: 2 comments 3 replies
-
You may need to use |
Beta Was this translation helpful? Give feedback.
-
You are right, that some simpler primitives like geometry is possible to be built on secondary threads in theory. It wasn't implemented in supported in Avalonia yet, as we weren't prioritizing it. If you need to build really large primitives and render it on secondary threads, you might need to skip whole PathGeometry layer. |
Beta Was this translation helpful? Give feedback.
-
Hello all,
I'm having an issue with an application ported from WPF, where the application freezes while a complicated UI element is being constructed.
The UI element is essentially one big
DrawingGroup
, with many nested sub-elements, mostlyGeometryDrawing
and otherDrawingGroup
objects. In the WPF app, these are built in a background thread while the main app continues to be responsive for editing (imagine something a bit like an Overleaf-style editor, with text box on one side and a visual representation on the other).In WPF, this worked well enough, as it allows you to construct UI elements on a different thread as long as they're not active, but now in Avalonia I can't construct
DrawingGroup
,GeometryDrawing
, orPathGeometry
objects in this background thread. Otherwise I get something like:The issue is that the engine backing up this layout is doing quite a lot of work while building the UI elements - as it's quite an involved layout system. In theory I could build an intermediate representation of the geometry, but this seems like it's just going to shorten the freezing problem rather than really get around it, as this representation will still have to be converted into Avalonia elements at some point.
Now, I know Avalonia is constrained to be mono-threaded for the UI due to hardware restrictions for some devices, so I get why I can't build high level UI components on another thread. But why can't I build
PathGeometry
objects? Or, alternatively, how can I build my geometry objects on a background thread so that the UI remains responsive while building this large nested structure?I wondered about a custom rendering pass of some kind, but the UI would still pause while it was doing this, right? Can I use this "render to an off-screen location" trick I've been hearing about from a different thread? But then I'm rendering to a bitmap, right, and will need to deal with resolution issues (as this canvas needs to be zoomable)?
Or is the solution to build an intermediate representation and just try and make the conversion from representation to
DrawingGroup
as efficient as possible? This would preserve the vector representation for zooming with aLayoutTransform
, but maybe is inefficient in other ways I'm not appreciating?Your suggestions and wisdom are much appreciated.
Beta Was this translation helpful? Give feedback.
All reactions