after checkin for bug https://bugzilla.mozilla.org/show_bug.cgi?id=269280 SeaMonkey DownloadManager is so slow that it is actually unusable. There are two reason. 1)Flawed DL-manager implementation, which seems re-acquiring info for all list elements at each event (at least fpr painting events) 2)Our nsIconChannel implementation. Obstacle in icon channel implementation is block which permanently calls nsCOMPtr<nsIMIMEService> mimeService (do_GetService("@mozilla.org/mime;1", &rv)); if (NS_SUCCEEDED(rv)) mimeService->GetTypeFromExtension(fileExtension, contentType); as contentType appears permanently empty.

Looks like nsXPIDLCString contentType returned by ExtractIconInfoFromUrl(...,nsACString &aContentType,...) is always empty, inspite Extract... just calls iconURI->GetContentType(nsACString &aContentType); and it always assigns literal NS_IMETHODIMP nsIconChannel::GetContentType(nsACString &aContentType) { aContentType.AssignLiteral("image/icon"); printf("GCCT %s\n", aContentType); return NS_OK; }

no, it calls that on the URI, not on the channel.

if file exists, attempts to get contentType from node, if no file or no icon in file, tries to get mime-type with native sniffing. Works in orders faster.

Comment on attachment 211600 [details] [diff] [review] patch + if (contentType.IsEmpty()) + { + // getting content type for no-bitmap fallback + char tmpmimestring[B_MIME_TYPE_LENGTH]; + localNodeInfo.GetType(tmpmimestring); + contentType = tmpmimestring; why not do this in the no-bitmap fallback code instead? Then you could also avoid assigning this to contentType and instead use mimeType.SetTo. + BMimeType tmpType; + if(B_OK == mimeType.GuessMimeType(fileExtension.get(), &tmpType)) + mimeType.SetTo(tmpType.Type()); + else + mimeType.SetTo("application/octet-stream"); why not: if (B_OK != BMimeType::GuessMimeType(fileExtension.get(), &mimeType)) mimeType.SetTo("application/octet-stream");

Per Comment 4: "why not do this in the no-bitmap fallback code instead?" 1)in place where it is currently, we already know that file exists. 2)if getting icon from files appear to be really slow with long list pupulated with image downloads, i go to replace GetTrackerIcon with GetIconForType() - or what it was - at same place. 3)Getting type from extension in BeOS is really hack and workaround, so it should be really last fallback, not preffered case. "why not:if (B_OK != BMimeType::GuessMimeType(fileExtension.get(), &mimeType)) mimeType.SetTo("application/octet-stream");" That may be refactored a bit. Though, we have two cases - if there is contentType already, and we failed in this case, or no contentType at all. may be i add soom boolean, may be find other way.

Btw, inspite it works now much faster, it still takes some time to populate and navigate list, very noticeable in comparison with pre-icon implementations. So i'm still considering icon-cache implementation, but in this case we will drop FileNode.GetTrackerIcon() - it is real overhead and space waste to have cached icons for unpredictable number of individial files.

Second variant of patch. Does not use individual icons, but always type-icons. Bit restructured logic, more ready for caching. Image conversion code may be more optimized, but as images aren't too large, only small change made in this regard.

I think we should use here GetMIMEInfoFromOS() and rewrite GetMimeInfoFromExtension() mozilla/source/uriloader/exthandler/beos/nsOSHelperAppService.cpp

setting dependance. Though, i'm considering to use here native mime utilities directly, without involving uriloader methods, as icons/iconChannel is actually very platfrom dependent. Biesi, what's your opinion on that problem?

yeah, iconchannel should produce the same icon as what the native file managers produce, so yeah, it should probably use native mime functions.

Unfortunately, BeOS support was dropped a long ago making this bug obsolete, so I'm closing it.