使用异步 AJAX 时 Silverlight 应用程序不会变为空闲状态
我目前正在使用一个 Silverlight 5 应用程序,该应用程序支持自身与 JavaScript 之间的双向通信。 Silverlight 应用程序负责渲染 3D 内容,JavaScript 负责收集和准备渲染数据。
我面临的问题是,Silverlight 5 DrawingSurface 仅在 DrawingSurface 失效并且应用程序变为空闲后才重新绘制。不幸的是,当使用异步 AJAX 请求从服务器下载所需的数据时,DrawingSurface 不会重新绘制,直到下载完所有数据(尽管在下载每条数据后使 DrawingSurface 无效)。
我理解这一点,但令我困惑的是,当我在 Silverlight 中使用 WebClient 执行完全相同风格的异步下载请求时,DrawingSurface 在大多数失效调用后成功重新绘制。
最初,我认为这可能是由于某些线程问题造成的,但所有调用(和回调)都在同一线程上运行。我尝试过使用 jQuery 的 AJAX API 并用 JavaScript 编写我自己的 XmlHttpRequest 处理程序;但两种方式我都得到相同的结果。我最初注意到 jQuery 以与我请求数据相同的顺序返回数据(而 Silverlight 的 WebClient 则不然),这导致我创建自己的 XmlHttpRequest 处理程序,因为我认为重新排序可能会导致脚本在异步调用期间保持活动状态。
有人以前遇到过这个问题和/或有人对解决方法/修复有任何建议吗?
I'm currently working with a Silverlight 5 application that supports two-way communication between itself and JavaScript. The Silverlight application is responsible for rendering 3D content and the JavaScript is responsible for collecting and preparing the data for rendering.
The problem I am faced with, is that the Silverlight 5 DrawingSurface only re-draws after the DrawingSurface is invalidated and the application becomes Idle. Unfortunately, when downloading the data that I require from the server using asynchronous AJAX requests, the DrawingSurface does not re-draw until all of the data has been downloaded (despite invalidating the DrawingSurface after each piece of data has been downloaded).
I understand this, but what confuses me is that when I do exactly the same style of asynchronous download requests using the WebClient within Silverlight, the DrawingSurface successfully re-draws after most of the invalidation calls.
Originally, I thought this might have been due to some threading issue, but all calls (and callbacks) operate on the same thread. I've tried using both jQuery's AJAX API and writing my own XmlHttpRequest handler in JavaScript; but I get the same result both ways. I originally noticed that jQuery was returning the data in the same order that I was requesting it in (whereas Silverlight's WebClient was not), which is what lead me to creating my own XmlHttpRequest handler as I thought that re-ordering might have caused the script to remain active during asynchronous calls.
Has anyone had this issue before and/or does anyone have any suggestions for workarounds/fixes?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
根据您的解释,在每次绘制调用结束时使表面无效(我不太喜欢游戏的绘制循环)不应该是一个简单的解决方法吗?您的帧速率会增加,但在大多数情况下,这不会成为问题(并且它将使相机和资源管理变得更加容易)。
无论如何,不要忘记渲染逻辑是在其自己的线程上执行的:您必须适当锁定共享实例。
From what you explain, shouldn't invalidating the surface at the end of each draw calls (I little like a game's drawing loop) be an easy workaround? Your frame rate will grow, but in most scenarios, it won't be an issue (and it will make camera and resource management a lot easier).
Don't forget anyway that the rendering logic is executed on its own thread: You will have to lock appropriately your shared instances.