+1

Thank you to agree, plg! ;-)

[Bugtracker] ticket 1791

so I managed to add the fonction

[Subversion] r10157

in the back-office :
- add the high dimensions to the db (they are already calculated)
- calculate dimensions during local synchronisation
- calculate dimensions during distant listing

and a kind of progressive update : for each picture which has_high I verify that high dimensions exist, I not I try to calculate them (here it can fails for some remote servers... but I add the @ operator)

I choose to overwrite websize information for the displaying : if datas exist only high filesize/dimensions are displayed

Last edited by mistic100 (2011-04-08 11:33:31)

I've forgot a word ^^
- add the high dimensions to the db during upload(they are already calculated)

arg I've forgot the Webservice, will add it soon

I think it would be easier to remove the "calculate dimensions during local synchronisation" and let your "progressive update" method do the job. No need to slow down or complexify the synchronization.

I don't understand this point of view :s why not add datas during synchronisation ? yes it's a bit slower but with this way there is no slow down when a visitor load a new photo. I think admins can endure that, visitors can't :D

Hum, I don't know if it's a good idea. I know we do it on the web size, but the HD might be much bigger. Did you perform some tests on remote servers?

I've made some tests with a remote server hsted by OVH : it works fine, I've also tried the "progressive update" with a distant picture, It takes 1-2 seconds more to load the page (just the time to download the picture)

why the is the @ operator not a good idea ? If I don't add it I must try before if the file is accessible, I don't know if it is faster...

What about web upload? (see admin/include/functions_upload.inc.php)