You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been trying to use CanvasVirtualControl to implement infinite canvas for my application.
Unfortunately, it doesn't seem to render correctly when i resize my window to larger size than initial size.
When CanvasVritualControl size is more than 2504 in width on my machine, it no longer reports whole visible region. Somehow, visible region width is clamped to 2504 width. This is exact value of initially opened window in my Application.
This causes the RegionsInvalidated event to be reported with too small VisibleRegion and InvalidatedRegions which breaks rendering of the surface when i try to render grid:
I'm using 1.6.3 version of winui3.
I've tracked source of the issue to winui3 code under debugger, connected to IVirtualSurfaceImageSource handling:
In CCoreServices::NWDrawTree method, called per frame, windowBounds under debugger has always width 2504, even when my window is resized. It does not seem to ever be updated from initial creation of window (both snippets are taken from winui3 sources)
// TODO: This is redundant. It should be replaced with the value from GetWindowSize.
XRECTF_RB windowBounds =
{
0.0f,
0.0f,
static_cast<XFLOAT>(pRenderTarget->GetWidth()),
static_cast<XFLOAT>(pRenderTarget->GetHeight())
};
This is passed later in this method to VirtualSurfaceImageSources to compute visible region, which get clamped by this incorrect window bounds:
// Now call any VirtualSurfaceImageSources (that are in the tree) so they re-compute visible bounds// and fire update events if neededIFC(VirtualSurfaceImageSourcePerFrameWork(&windowBounds));
Now, win2d does use IVirtualSurfaceImageSource->GetVisibleBounds later for reporting visible regions, and this value is clamped.
Any ideas if this is Win2d issue or Winui3? Some possible workaround? My current thinking is that I will have to move from CanvasVirtualControl to virtual composition surface with win2d drawing, and handle all of invalidation and trimming manually. I would prefer to stay on CanvasVirtualControl.
I've tried overdrawing in RegionsInvalidated event (increasing the width of update rects), but it predictably causes artifacts when scrolling.
The text was updated successfully, but these errors were encountered:
I've been trying to use
CanvasVirtualControl
to implement infinite canvas for my application.Unfortunately, it doesn't seem to render correctly when i resize my window to larger size than initial size.
When
CanvasVritualControl
size is more than 2504 in width on my machine, it no longer reports whole visible region. Somehow, visible region width is clamped to 2504 width. This is exact value of initially opened window in my Application.This causes the
RegionsInvalidated
event to be reported with too smallVisibleRegion
andInvalidatedRegions
which breaks rendering of the surface when i try to render grid:I'm using 1.6.3 version of winui3.
I've tracked source of the issue to winui3 code under debugger, connected to
IVirtualSurfaceImageSource
handling:In
CCoreServices::NWDrawTree
method, called per frame,windowBounds
under debugger has always width 2504, even when my window is resized. It does not seem to ever be updated from initial creation of window (both snippets are taken from winui3 sources)This is passed later in this method to VirtualSurfaceImageSources to compute visible region, which get clamped by this incorrect window bounds:
Now, win2d does use
IVirtualSurfaceImageSource->GetVisibleBounds
later for reporting visible regions, and this value is clamped.Any ideas if this is Win2d issue or Winui3? Some possible workaround? My current thinking is that I will have to move from
CanvasVirtualControl
to virtual composition surface with win2d drawing, and handle all of invalidation and trimming manually. I would prefer to stay onCanvasVirtualControl
.I've tried overdrawing in
RegionsInvalidated
event (increasing the width of update rects), but it predictably causes artifacts when scrolling.The text was updated successfully, but these errors were encountered: