I've spent a few hours this afternoon tracing through the code to Media (1.x) to discover why the thumbnail display takes, for my sample content, 70 times longer to display than the list. Eventually, it boiled down to the call to `image_load` in the `file_entity_file_formatter_file_image_view` function. Removing this call (and hardcoding the `#width` and `#height` values in the `$element` returned by the formatter) result in runtimes which are approximately equivalent to the list view.

I've not tried 2.x, but I have examined the code for `file_entity` (4db2744b1d3d1f5e50a2390bb48dc45645365ed6) and find the same call in the same place, so I expect the same problem applies.

I'm not sure what the correct solution is (either ditching the dimension attributes on the rendered `` tag and letting the image style return whatever, or caching image dimensions when the file is created) but invoking `image_load` every time it's displayed seems to me to be unsupportable.

Is it really necessary to create a new table? I suggest the following..

1. try to get the data saved with the image field using file_usage in a db query
2. if that fails, fall back to using image_get_info
3. if that also fails, null values will be passed as width and height, which should avoid the php notices

I have tried to modify the file_entity_file_formatter_file_image_view function. (from 7.x-1.0-rc3, where I have the same problem) Here it is:

But as you say, I agree, it would be more relevant to save the width and height with the file data in stead of the field data.. Or it would be a good idea to add which field uses the file in the file_usage table, because, that would make it easier to get the field data.

image_theme() defines defaults for width and height, so you only get warnings when width and height are not provided if you haven't cleared the cache or you are calling theme_image_style() directly (illegal).

Here is a patch implementing the solution suggested in #2. Image dimensions are loaded from the {image_dimensions} table in file_entity_file_load as $file->image_dimensions. In file_entity_file_formatter_file_image_view, if $file->image_dimensions is not set, the dimensions are loaded using image_get_info and stored in {image_dimensions}.

Here is an updated patch with hook_file_insert, hook_file_update abd hook_file_delete support. There is no more code to load image dimensions file_entity_file_formatter_file_image_view since it is always done on file_save and file_load. I did write tests for the patch, but I'm issue running the test cases locally.

Ouch, this is huge. Took me a while to track this down as it only happened on production. We have the files on a relatively slow NFS storage and this is absolutely killing the site, as we have tons of images displayed everywhere. I'm talking about 60s+ response times.

I have commented it out for now, this site has it's own handing for that anyway as it was built before this existed. Will have a closer look when I find the time.

I read through this thread and I wonder why I am having this problem. See I'm not using images. I have a folder with a few hundred MP3 files. These obviously do not have a height or width. Yet when I load a piece of media from the library, the full list does not load. And I have to scroll down the list and wait for Ajax to load it bit by bit.

It used to take over a minute to load the full list. I got it down a little. I visited admin/config/media/browser
and switched the allowed field extensions from:
jpg jpeg gif png txt doc docx xls xlsx pdf ppt pptx pps ppsx odt ods odp mp3 mov m4v mp4 mpeg avi ogg oga ogv wmv ico

to mp3

This has obvious drawbacks if I ever want to use the Media module to manage any other media besides MP3.

It now loads in about 20 seconds or so. But I would ask, why is it not possible for me to load all the songs instantly?

Just tested this. and it worked perfectly. I don't know what update function is being talked about here, but this should be in 7.x-1.x-dev ASAP. After adding a couple of large files and in a server with 128Mb PHP max mem, this prevented the media browser from working.

After reading more I've noticed that in File Entity it uses !$file->filesize instead of !filesize($file->uri) for determining if the file is empty. Since filesize() doesn't prevent the warning mentioned in the code comments (http://drupal.org/node/681042) I've updated the patch to use $file->filesize.