我正在使用Fine Uploader为社区网站创建模拟文件上传工具。
我已将会话设置为从服务器检索初始文件以及缩略图网址。
一切都很好,但缩略图的渲染非常慢。 我无法解决原因。所以我硬编码为四个文件中的每一个使用一个非常小的缩略图。这没什么区别。
服务器端不是问题。信息很快就会回来。
我做错了吗?为什么fineuploader这么慢?这是屏幕抓取。它需要四秒钟来渲染四个缩略图。
我使用的是最新的Chrome。它是一台功能相当强大的机器上的NancyFX项目。将其他大页面上的图片重新打印出来是非常活泼的。
客户端代码:
thumbnails: {
placeholders: {
waitingPath: '/Content/js/fine-uploader/placeholders/waiting-generic.png',
notAvailablePath: '/Content/js/fine-uploader/placeholders/not_available-generic.png'
}
},
session: {
endpoint: "/getfiles/FlickaId/342"
},
服务器端代码:
// Fine uploader makes session request to get existing files
Get["/getfiles/FlickaId/{FlickaId}"] = parameters =>
{
//get the image files from the server
var i = FilesDatabase.GetFlickaImagesById(parameters.FlickaId);
// list to hold the files
var list = new List<UploadedFiles>();
// build the response data object list
foreach (var imageFile in i)
{
var f = new UploadedFiles();
f.name = "test-thumb-small.jpg"; // imageFile.ImageFileName;
f.size = 1;
f.uuid = imageFile.FileGuid;
f.thumbnailUrl = "/Content/images/flickabase/thumbnails/" + "test-thumb-small.jpg"; // imageFile.ImageFileName;
list.Add(f);
}
return Response.AsJson(list); // our model is serialised by Nancy as Json!
};
答案 0 :(得分:3)
这是设计使用的,并且都是为了防止UI线程充满图像缩放逻辑并防止Chrome特有的内存泄漏问题而实现的。这在文档的缩略图和预览部分进行了解释,特别是在the "performance considerations" area:
中对于支持客户端生成的图像预览的浏览器(qq.supportedFeatures.imagePreviews === true),模板生成的预览之间的可配置暂停生效。这是为了防止生成预览的复杂过程在很长一段时间内压倒客户端计算机的CPU。如果没有此限制,浏览器的UI线程将面临阻止风险,阻止任何用户交互(滚动等),直到生成所有预览。
您可以通过the thumbnails
option调整或删除此暂停,但我建议您不执行此操作,除非您确定用户不会删除大量复杂的图像文件。