为什么我的图像有时会在恢复时重新加载(并且WriteableBitmaps消失)? [英] Why do my images sometimes reload (and WriteableBitmaps disappear) on resume?

问题描述

当我恢复我的应用程序时，有时会丢失其图像.我什至可以在微不足道的应用程序中重现这一点.

When I resume my app, sometimes it loses its images. I can reproduce this even in trivial apps.

这以两种不同的方式体现出来，具体取决于图像的来源:

This manifests in two different ways, depending on where the image came from:

• 如果我做了类似<Image Source="/Assets/Logo.png"/>的操作(即，通过URI从我的应用包中加载图片)，则该图片会短暂消失，然后重新加载.当屏幕上包含许多图像时，这很容易看到；它们会按顺序重新加载，因此我可以在屏幕上看到图像加载的波纹.
• 如果我创建了WriteableBitmap并将其绑定到Image.Source，则位图将完全消失，不再返回.

• If I did something like <Image Source="/Assets/Logo.png"/> (i.e., loading an image from my app package by URI), the image will disappear briefly, and then reload. This is easier to see when the screen contains many images; they reload in sequence, so I can watch the image loading ripple across the screen.
• If I created a WriteableBitmap and bound it to Image.Source, then the bitmap disappears entirely, never to return.

如果它只是重​​新加载图像，我可能会忍受(尽管涟漪效果令人不快)，但是我做了很多动态图像生成，而且我的所有WriteableBitmap消失都不是一件很酷的事情.

I could probably live with this if it was just reloading images (though the ripple effect is unpleasant), but I do quite a bit of dynamic image generation, and it's not cool for all my WriteableBitmaps to disappear.

这种情况并非在每次应用程序暂停和恢复时都会发生，仅在某些情况下会发生.我还没有确定可靠的repro案例，但似乎它被暂停的时间越长，以及在此期间我正在做的其他事情越多(在台式机Chrome浏览器中上网，玩TapTiles和Microsoft Minesweeper之类的全屏DirectX游戏) ，更有可能的是，当我切换回我的应用程序时，这些图像将丢失. (应用程序不是被终止并重新启动，它仍然是相同的应用程序实例.)

This doesn't happen every time the app suspends and resumes, only sometimes. I haven't nailed down a reliable repro case, but it seems that the longer it's suspended, and the more other things I'm doing in the interim (surfing the web in desktop Chrome, playing fullscreen DirectX games like TapTiles and Microsoft Minesweeper), the more likely it is that, when I switch back to my app, the images will be lost. (The app is not getting terminated and re-launched -- it's still the same app instance.)

我想知道这是否与从显存中刷新图像有关.但是我不知道如何检验这个假设，所以在这一点上只是个猜测.

I wonder if it's something to do with images getting flushed from video memory. But I have no idea how to test this hypothesis, so at this point it's just a guess.

到目前为止，我还没有找到让程序知道WriteableBitmaps正在丢失的任何方法.事件的顺序与正常的暂停和恢复相同:

So far, I haven't found any way for my program to even tell that WriteableBitmaps are being lost. The sequence of events is identical to a normal suspend and resume:

• 使用args.WindowActivationState ==停用的Window.Current.Activated
• 使用args.Visible == false触发Window.Current.VisibilityChanged
• Application.Suspending fires
• (时间流逝)
• 应用程序.恢复火灾
• 使用args.Visible == true触发Window.Current.VisibilityChanged
• 使用args.WindowActivationState == CodeActivated触发Window.Current.Activated

我没有碰到一个顺便说一句，所有图像都消失了"的事件. WriteableBitmap 没有事件. 图像具有ImageOpened和ImageFailed事件，但是只有当我从中加载图像时才会触发一个URI-当Source是WriteableBitmap时，它们永远不会触发.

I haven't had any luck finding an "and by the way, all your images went away" event. WriteableBitmap has no events. Image has ImageOpened and ImageFailed events, but those only fire when I load an image from a URI -- they never fire when Source is a WriteableBitmap.

我已经能够在微不足道的应用程序中重现此内容，因此它不是由某些第三方库引起的.如果该应用已暂停了一段时间，然后您将其恢复，则带有URI加载的图像的空白页将再次触发ImageOpened(并且图像将在完成重新加载之前短暂闪烁).如果该应用已暂停了一段时间，然后您将其恢复，则其图像初始化为WriteableBitmap的空白页将消失.

I've been able to reproduce this in trivial apps, so it's not caused by some third-party library. A blank page with an Image loaded by URI will fire ImageOpened again (and the image will flicker briefly before it finishes reloading) if the app has been suspended for a while and then you resume it. A blank page with an image initialized to a WriteableBitmap will disappear if the app has been suspended for a while and then you resume it.

如何解决WriteableBitmap(如果可能的话，还包括内容URI图像)的丢失?有什么办法可以防止图像从一开始就丢失?如果没有，我有什么办法可以检测到它们已经丢失，因此可以重新创建我的WriteableBitmaps?

How can I fix the loss of WriteableBitmaps (and, if possible, content-URI images too)? Is there any way that I can prevent the images from getting lost in the first place? If not, is there any way I can detect that they've been lost, so I can re-create my WriteableBitmaps?

(为了获得加分，我很想知道为什么为什么消失了，但是那部分是完全可选的.我已经很久没想到WinRT才有意义了.)

(For bonus points, I'd love to know why the images disappear, but that part is entirely optional. I've long since given up on expecting WinRT to make sense.)

推荐答案

我做过一些实验，清楚地表明WinRT只是丢失WriteableBitmap的内容，而不是WriteableBitmap本身. WriteableBitmap实例仍然可行.如果您给它新的像素数据，它将正常工作.只是有时候，在应用履历表上，其内容被一大堆透明像素所取代.

I've done some experiments that made it clear that WinRT is just losing the contents of the WriteableBitmap, not the WriteableBitmap itself. The WriteableBitmap instance is still viable; if you give it new pixel data, it works fine. It's just that sometimes, on app resume, its contents get replaced with a swath of transparent pixels.

通过挂钩应用程序的OnResuming事件，并使用该事件来获取我的WriteableBitmap的PixelBuffer.AsStream()，写入新的像素并调用WriteableBitmap.Invalidate()，我能够解决此问题.如果重新生成图像的代码是同步的，则在应用恢复时图像甚至不会闪烁.

I've been able to work around this problem by hooking my app's OnResuming event, and using that event to grab my WriteableBitmap's PixelBuffer.AsStream(), write new pixels, and call WriteableBitmap.Invalidate(). If the code that regenerates the image is synchronous, then the image doesn't even flicker when the app resumes.

我怀疑普通位图(通过Source URI加载)也会丢失其像素缓冲区，并且在应用恢复后必须重新加载其像素.图像加载是异步的，这说明了在内容重新出现之前的延迟/闪烁.

I suspect that ordinary bitmaps (loaded via a Source URI) are also losing their pixel buffers, and having to reload their pixels after the app resumes. Image loading is async, which explains the delay / flicker before their contents reappear.

我还没有找到一种方法来知道图像是否丢失了像素(尽管显然URI加载的图像具有某种了解方式，因为它们会自动重新加载自身).因此，使用WriteableBitmaps，最安全的方法似乎是始终在应用履历表中重新填充它们.

I haven't found a way to know whether the image lost its pixels (though obviously URI-loaded images have some way of knowing, since they reload themselves automatically). So with WriteableBitmaps, the safest thing seems to be to always repopulate them on app resume.

这篇关于为什么我的图像有时会在恢复时重新加载(并且WriteableBitmaps消失)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！