Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5827 > unrolled thread
| Started by | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| First post | 2012-05-06 11:12 +0200 |
| Last post | 2012-05-08 09:49 +0200 |
| Articles | 20 on this page of 143 — 18 participants |
Back to article view | Back to comp.lang.php
Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 11:12 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-06 11:51 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 17:23 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-06 18:11 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-07 20:05 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-07 20:23 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 17:16 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-07 16:49 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 15:01 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 20:15 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 20:37 -0700
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-08 09:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-08 08:21 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-08 11:17 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:14 -0400
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 17:05 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:21 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-09 19:36 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 21:31 +0200
Re: Windows binaries 64bit for PHP Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-12 11:12 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:56 +0100
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:51 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 10:17 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-14 19:26 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:52 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:50 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:01 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:01 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:12 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:50 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 13:57 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:32 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 20:01 +0100
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-08 22:25 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-08 21:29 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 09:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:17 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 10:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:23 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 13:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 07:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 15:44 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:30 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:38 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:48 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-09 11:34 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 11:30 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 15:52 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 13:46 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:10 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:19 +0200
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 15:28 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 13:15 -0700
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-10 21:48 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 17:05 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 14:29 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 19:35 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 18:50 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 22:22 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-11 10:03 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 13:56 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:51 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:29 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:11 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-12 01:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:44 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:36 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 14:01 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:34 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 20:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:30 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 21:46 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:14 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 14:42 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 11:04 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 18:40 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 15:49 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:59 +0100
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 13:46 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 07:50 -0500
Re: Windows binaries 64bit for PHP Anders Wegge Keller <wegge@wegge.dk> - 2012-05-13 16:15 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 10:36 -0400
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 09:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 18:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 13:27 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 22:26 -0500
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 09:51 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 08:04 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 14:25 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 09:37 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 16:22 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 16:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:07 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 22:37 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:47 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 16:53 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-14 20:36 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:04 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:48 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:57 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:46 -0400
Re: Windows binaries 64bit for PHP PlastiqueMAN <plastique@man.com> - 2012-05-23 22:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 00:18 -0400
Re: Windows binaries 64bit for PHP Stig Vestøl <stig@vestoldata.no> - 2012-05-24 11:40 +0200
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 12:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 09:12 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 16:29 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-24 20:41 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 15:17 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:15 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-12 10:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 07:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-12 06:47 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:40 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 01:07 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:49 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:02 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:09 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:32 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 17:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-16 12:35 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 19:35 +0200
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-06 18:30 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-12 16:45 +0200
Re: Windows binaries 64bit for PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-05-08 09:49 +0200
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Shake <alex.estevezQUENO@QUENOfilnet.es> |
|---|---|
| Date | 2012-05-11 20:58 +0200 |
| Message-ID | <jojngk$bjr$1@dont-email.me> |
| In reply to | #5967 |
Jerry Stuckle a couché sur son écran : > > Loading the script, starting the scripting module, initializing the > environment, interpreting and running the script, checking for the presence > of the image, storing a resized script if necessary, loading the image and > sending it, and cleaning up the environment. > > This vs. sending the image directly via an <img ...> tag. > > Nope, no extra overhead! And no way to send the image without a script! > The Extra overhead is something like in the code that generate the page: <?php if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file); ?> Not look like an "application killer" to me. Greetings.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 15:30 -0400 |
| Message-ID | <jojpbu$n7f$2@dont-email.me> |
| In reply to | #5972 |
On 5/11/2012 2:58 PM, Shake wrote: > Jerry Stuckle a couché sur son écran : >> >> Loading the script, starting the scripting module, initializing the >> environment, interpreting and running the script, checking for the >> presence of the image, storing a resized script if necessary, loading >> the image and sending it, and cleaning up the environment. >> >> This vs. sending the image directly via an <img ...> tag. >> >> Nope, no extra overhead! And no way to send the image without a script! >> > > The Extra overhead is something like in the code that generate the page: > > <?php > if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file); > ?> > > Not look like an "application killer" to me. > > Greetings. > > There's a lot more to the overhead than that! -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Shake <alex.estevezQUENO@QUENOfilnet.es> |
|---|---|
| Date | 2012-05-11 21:46 +0200 |
| Message-ID | <jojqbd$tik$1@dont-email.me> |
| In reply to | #5976 |
Jerry Stuckle avait écrit le 11/05/2012 : > On 5/11/2012 2:58 PM, Shake wrote: >> Jerry Stuckle a couché sur son écran : >>> >>> Loading the script, starting the scripting module, initializing the >>> environment, interpreting and running the script, checking for the >>> presence of the image, storing a resized script if necessary, loading >>> the image and sending it, and cleaning up the environment. >>> >>> This vs. sending the image directly via an <img ...> tag. >>> >>> Nope, no extra overhead! And no way to send the image without a script! >>> >> >> The Extra overhead is something like in the code that generate the page: >> >> <?php >> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file); >> ?> >> >> Not look like an "application killer" to me. >> >> Greetings. >> >> > > There's a lot more to the overhead than that! Which? Is the image going to be accessed directly by its URL, or is loaded inside a webpage? I am sure is this last case. So Loading a PHP script will occur 99.999% if you reescaled the image previously with a batch or not. All the work of load an script, will be done always. I don't believe that "react" to a 404 error is the good aproach, but generating dinamically the scaled images when the page that show them is required. And this only need the few lines to test if file exists and generate the images if not. The fact that the image is directly accessed without pasing first for the php script... Someone talked about a catalog of image... I am sure they are accessed through a we, not directly. Even if they are accessed via search engines, these search engines have to visit the scripts that would generate the scaled images. Greetings.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 18:14 -0400 |
| Message-ID | <jok303$hom$2@dont-email.me> |
| In reply to | #5977 |
On 5/11/2012 3:46 PM, Shake wrote: > Jerry Stuckle avait écrit le 11/05/2012 : >> On 5/11/2012 2:58 PM, Shake wrote: >>> Jerry Stuckle a couché sur son écran : >>>> >>>> Loading the script, starting the scripting module, initializing the >>>> environment, interpreting and running the script, checking for the >>>> presence of the image, storing a resized script if necessary, loading >>>> the image and sending it, and cleaning up the environment. >>>> >>>> This vs. sending the image directly via an <img ...> tag. >>>> >>>> Nope, no extra overhead! And no way to send the image without a script! >>>> >>> >>> The Extra overhead is something like in the code that generate the page: >>> >>> <?php >>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file); >>> ?> >>> >>> Not look like an "application killer" to me. >>> >>> Greetings. >>> >>> >> >> There's a lot more to the overhead than that! > > Which? > See my other posts. It is actually quite involved, and I'm not going to repeat it (again). > Is the image going to be accessed directly by its URL, or is loaded > inside a webpage? I am sure is this last case. > > So Loading a PHP script will occur 99.999% if you reescaled the image > previously with a batch or not. All the work of load an script, will be > done always. > Nope. If you rescaled the image via a batch script, the image is there and it can be served directly. > I don't believe that "react" to a 404 error is the good aproach, but > generating dinamically the scaled images when the page that show them is > required. > Which has significant overhead, as I've pointed out in my other posts. > And this only need the few lines to test if file exists and generate the > images if not. > There's a lot more to it than that. > The fact that the image is directly accessed without pasing first for > the php script... > > Someone talked about a catalog of image... I am sure they are accessed > through a we, not directly. > A catalog of images doesn't mean the images aren't being served directly. > Even if they are accessed via search engines, these search engines have > to visit the scripts that would generate the scaled images. > > Greetings. > > More unnecessary overhead. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Shake <alex.estevezQUENO@QUENOfilnet.es> |
|---|---|
| Date | 2012-05-12 14:42 +0200 |
| Message-ID | <jolls8$q60$1@dont-email.me> |
| In reply to | #5981 |
I thought you don't understood. I would use the catalogue example: People visits this page to see the image catalogue. Search engines visits this page to index images. If nobody human or machine have entered to this page, there is no directy linked image nowhere. So, at this point nobody knows any url to any image of this site. And there is no image that could be accessed. The only way to knwo about one of these images is when anyone enter the php page. And when this occurs, reescaling process will be done if necesary. Never, any image will be directly delivered without previosly have been executed the php. We have the image /catalogue/images/size_1/123213.jpg Original We have the image /catalogue/images/size_2/123213.jpg Scaled We have the image /catalogue/images/size_3/123213.jpg No Scaled. The catalogue was listed throught /catalogue/index.php that yesterday was modified using a new size fo thumbnails (size_3). The third size was created yesterday. Nobody knows his existence, there is no link to it in any web, search engine or human brain. So nobody could access. That is a lucky thing, because the image no exist. When the first visit is done to the /catalogue/index.php the size_2 images start to be generated. If the visit is from a search engine, then the new images are indexed and could be directly accessed. so /catalogue/index.php is executed always previous to put on the net the existence of new images. Included if we have batch reescaled them. These images will not have internet existence never if the catalogue/index.php is not executed. with or without reescaling. And then, this mean that all the supossed overhead about executing PHP always happen even if you batched the process. And it's obvious. we are talking about web pages that are created with php. I worked for four years in a website for artists. Not the bigger company but with reasonable traffic, 8 millions page visits per month, por than 250.000 pages per day. And about 1 million image artwork. A lot of them of big resolucion. And in this company we fight against this problem. In some cases we decided to use batch process and in other cases we decided to do "on-the-fly". Big images requires watermarking and some other processes, too slow to do on-fly. The reescaling required 3 weeks to be done , using three 3 computers. Other times, for new set of small sizes, we used on the fly. withouth usign 404 to react to. Just first time any one enters a page that have new images, new images were generated. And never happened that any image have been accesses directly previous to its generation. The images are always served directly throught lighttp, the php necesary to generate images was always inside the php app that generate the web pages. Greetings
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-12 11:04 -0400 |
| Message-ID | <jolu6j$98t$1@dont-email.me> |
| In reply to | #5994 |
On 5/12/2012 8:42 AM, Shake wrote: > I thought you don't understood. > > I would use the catalogue example: > > People visits this page to see the image catalogue. Search engines > visits this page to index images. > > If nobody human or machine have entered to this page, there is no > directy linked image nowhere. > The link is there, whether a human or machine has requested the page or not. Links don't just magically appear! Whether the link has been accessed or not is a different story - but immaterial to whether it exists or not. > So, at this point nobody knows any url to any image of this site. And > there is no image that could be accessed. > Still doesn't make any difference whether someone knows about the image or not. > The only way to knwo about one of these images is when anyone enter the > php page. And when this occurs, reescaling process will be done if > necesary. > At additional overhead to the server. This overhead can be completely eliminated by simply resizing the images offline. > Never, any image will be directly delivered without previosly have been > executed the php. > And once the images have been created offline, the server doesn't have to execute ANY PHP to deliver the image. > We have the image /catalogue/images/size_1/123213.jpg Original > We have the image /catalogue/images/size_2/123213.jpg Scaled > We have the image /catalogue/images/size_3/123213.jpg No Scaled. > > The catalogue was listed throught /catalogue/index.php that yesterday > was modified using a new size fo thumbnails (size_3). > > The third size was created yesterday. Nobody knows his existence, there > is no link to it in any web, search engine or human brain. So nobody > could access. That is a lucky thing, because the image no exist. > If there is no link, then why would the image be created? > When the first visit is done to the /catalogue/index.php the size_2 > images start to be generated. If the visit is from a search engine, then > the new images are indexed and could be directly accessed. > And if the images are created offline, none of that needs to be done. The images can be sent without any PHP involvement at all. > so /catalogue/index.php is executed always previous to put on the net > the existence of new images. Included if we have batch reescaled them. > These images will not have internet existence never if the > catalogue/index.php is not executed. with or without reescaling. > But if you're listing them in the catalog, then there is a link to them. > And then, this mean that all the supossed overhead about executing PHP > always happen even if you batched the process. > Sure, but the batch process is done on another machine, taking unnecessary work off the server. > And it's obvious. we are talking about web pages that are created with php. > Which has nothing to do with resizing of images. The page with the link MAY be a PHP page. But it could also be a Perl page, a Python page, a Ruby (on Rails) page or even static HTML. > I worked for four years in a website for artists. Not the bigger company > but with reasonable traffic, 8 millions page visits per month, por than > 250.000 pages per day. And about 1 million image artwork. A lot of them > of big resolucion. > 8 million hits a month is a bit below average, but a lot more than most of the people in this newsgroup work on. > And in this company we fight against this problem. In some cases we > decided to use batch process and in other cases we decided to do > "on-the-fly". > Sure, doing the batch process means less work for the server. > Big images requires watermarking and some other processes, too slow to > do on-fly. The reescaling required 3 weeks to be done , using three 3 > computers. > You need to get some better computers. 1M images shouldn't take anywhere near 9 computer weeks to do! But then maybe you're using Windows, which has significant overhead. Of course you could also do it in a compiled language like C, which will also tremendously speed up the process (a C program to do something like this is pretty simple). > Other times, for new set of small sizes, we used on the fly. withouth > usign 404 to react to. > Good you're not using the 404. But it's still a lot of unnecessary overhead. How long would it take your 3 computers to resize all the images you're currently doing on your server? You're dumping that amount of overhead plus more on the server. > Just first time any one enters a page that have new images, new images > were generated. And never happened that any image have been accesses > directly previous to its generation. > Which is putting unnecessary overhead on the server. > The images are always served directly throught lighttp, the php necesary > to generate images was always inside the php app that generate the web > pages. > > Greetings > > You still have significant overhead on the server. Plus now you've added unnecessary complexity to your application. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Shake <alex.estevezQUENO@QUENOfilnet.es> |
|---|---|
| Date | 2012-05-12 18:40 +0200 |
| Message-ID | <jom3q2$atj$1@dont-email.me> |
| In reply to | #5996 |
WTF you don't understand nothing of what I wrote... Probably the problem it's me and my lack of knowledge of english language... The thing is in: "And once the images have been created offline, the server doesn't have to execute ANY PHP to deliver the image." Yes you have... the image will never exists on the net, without first having executed a PHP. (Not to deliver the image). And this is what I could not explain to you. GReetings.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-12 15:49 -0400 |
| Message-ID | <jomese$lpq$1@dont-email.me> |
| In reply to | #5997 |
On 5/12/2012 12:40 PM, Shake wrote: > WTF > > > you don't understand nothing of what I wrote... Probably the problem > it's me and my lack of knowledge of english language... > > The thing is in: > > "And once the images have been created offline, the server doesn't have > to execute ANY PHP to deliver the image." > > Yes you have... the image will never exists on the net, without first > having executed a PHP. (Not to deliver the image). And this is what I > could not explain to you. > > GReetings. > > I do understand what you're saying. And I'm saying you create the image offline and upload it to the server. The server should not have to spend its time resizing images - it has a lot more important things to do. Whether the server executes PHP other than resizing the image is completely immaterial to the issue. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-12 22:59 +0100 |
| Message-ID | <jommfc$rt7$3@news.albasani.net> |
| In reply to | #5997 |
Shake wrote: > WTF > > > you don't understand nothing of what I wrote... Probably the problem > it's me and my lack of knowledge of english language... > > The thing is in: > > "And once the images have been created offline, the server doesn't have > to execute ANY PHP to deliver the image." > > Yes you have... the image will never exists on the net, without first > having executed a PHP. (Not to deliver the image). And this is what I > could not explain to you. > Probably because its nonsense. there is no law of nature that says that PHP must exist on the internet. Nor that anything it can accomplish cant be accomplished in some other way. images have been on the net before PHP existed. > GReetings. > > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | Shake <alex.estevezQUENO@QUENOfilnet.es> |
|---|---|
| Date | 2012-05-13 13:46 +0200 |
| Message-ID | <joo6tv$oo5$1@dont-email.me> |
| In reply to | #5996 |
Après mûre réflexion, Jerry Stuckle a écrit : > You need to get some better computers. NOT. Only if I try to batch. On-the-fly everything goes well. SO on-the-fly works better. Batch requieres a lot of cpu and space to do all the work, On-the-fly requires a little amount of cpu and space diluted in the normal server work. Greetings
[toc] | [prev] | [next] | [standalone]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2012-05-13 07:50 -0500 |
| Message-ID | <slrnjqvbh9.4ci.hellsop@nibelheim.ninehells.com> |
| In reply to | #6002 |
On Sun, 13 May 2012 13:46:06 +0200, Shake wrote:
> Apr?s m?re r?flexion, Jerry Stuckle a ?crit :
>
>> You need to get some better computers.
>
> NOT. Only if I try to batch. On-the-fly everything goes well. SO
> on-the-fly works better.
>
> Batch requieres a lot of cpu and space to do all the work, On-the-fly
> requires a little amount of cpu and space diluted in the normal server
> work.
'cause it takes SO MUCH LONGER to resize images on a computer that's
doing nothing but resize images than it does on a computer that's also
trying to answer http requests on a timely basis. Though I suppose it
would make a certain amount of sense if no one ever visited the website.
Then, you'd never need the images.
--
41. Once my power is secure, I will destroy all those pesky time-travel
devices.
--Peter Anspach's list of things to do as an Evil Overlord
[toc] | [prev] | [next] | [standalone]
| From | Anders Wegge Keller <wegge@wegge.dk> |
|---|---|
| Date | 2012-05-13 16:15 +0200 |
| Message-ID | <871umo6uba.fsf@huddi.jernurt.dk> |
| In reply to | #6003 |
"Peter H. Coffin" <hellsop@ninehells.com> writes: > 'cause it takes SO MUCH LONGER to resize images on a computer that's > doing nothing but resize images than it does on a computer that's > also trying to answer http requests on a timely basis. Indeed it does, if you happen to have seven and a half million images. I haven't followed this thread that m,uch, but ISTR that figure being mentioned. Even if you had the hardware to resize 10 images a second, you are still looking at close to 10 days of processing time. What do you propose to do in that period, when a request for an image that has not yet been processed, arrives? > Though I suppose it would make a certain amount of sense if no one > ever visited the website. Then, you'd never need the images. Ohh, the maturity of people in this group. It takes me back to my kindergarten days :) -- /Wegge Leder efter redundant peering af dk.*,linux.debian.*
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-13 10:36 -0400 |
| Message-ID | <joogub$fbq$1@dont-email.me> |
| In reply to | #6005 |
On 5/13/2012 10:15 AM, Anders Wegge Keller wrote: > "Peter H. Coffin"<hellsop@ninehells.com> writes: > >> 'cause it takes SO MUCH LONGER to resize images on a computer that's >> doing nothing but resize images than it does on a computer that's >> also trying to answer http requests on a timely basis. > > Indeed it does, if you happen to have seven and a half million > images. I haven't followed this thread that m,uch, but ISTR that > figure being mentioned. Even if you had the hardware to resize 10 > images a second, you are still looking at close to 10 days of > processing time. What do you propose to do in that period, when a > request for an image that has not yet been processed, arrives? > So you're going to force the server to waste its time resizing pages instead of doing it's job (of serving web pages). Of course, it's not a problem if you only bet 200 hits/day. But any even moderately busy server has much better things to do. >> Though I suppose it would make a certain amount of sense if no one >> ever visited the website. Then, you'd never need the images. > > Ohh, the maturity of people in this group. It takes me back to my > kindergarten days :) > He called it straight. I don't think anyone on this newsgroup has any idea what an even moderately busy site is. They are amazed at 1M hits/ mo. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-13 09:06 -0400 |
| Message-ID | <joobl2$h0h$1@dont-email.me> |
| In reply to | #6002 |
On 5/13/2012 7:46 AM, Shake wrote: > Après mûre réflexion, Jerry Stuckle a écrit : > >> You need to get some better computers. > > NOT. Only if I try to batch. On-the-fly everything goes well. SO > on-the-fly works better. > > Batch requieres a lot of cpu and space to do all the work, On-the-fly > requires a little amount of cpu and space diluted in the normal server > work. > > Greetings > > You aren't making any sense. Why would it take a server which is doing more important things LESS time and resources to do the same job as another machine not doing anything. The answer is, it doesn't. In fact, overall, it takes the server MORE time and resources to do the same job. You have just shown you have absolutely no idea what load you're putting on your server. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Shake <alex.estevezQUENO@QUENOfilnet.es> |
|---|---|
| Date | 2012-05-13 18:54 +0200 |
| Message-ID | <jooovb$vhi$1@dont-email.me> |
| In reply to | #6004 |
Jerry Stuckle a exposé le 13/05/2012 : > > You aren't making any sense. Why would it take a server which is doing more > important things LESS time and resources to do the same job as another > machine not doing anything. This means you have to have two machines. At least. > > The answer is, it doesn't. In fact, overall, it takes the server MORE time > and resources to do the same job. But you have a server with MORE resources to do the job. > You have just shown you have absolutely no idea what load you're putting on > your server. That's not true, simply you don't know which structure I had. And you supposed I have a server doing all the job. For generating little (thumbnails) images from other scaled image. The resources used are really not so much. And the resources available by the servers whre enought to do not change in a measurable way the time delivering pages. Tha fact is that having more machine more powerfull not doing nothing else that reescaling images when required in batch proceses is a waste of money and resources. In the other side, reescaling on the fly, of course, implies some more process but not noticable. Greetings
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-13 13:27 -0400 |
| Message-ID | <jooqut$bru$1@dont-email.me> |
| In reply to | #6007 |
On 5/13/2012 12:54 PM, Shake wrote: > Jerry Stuckle a exposé le 13/05/2012 : >> >> You aren't making any sense. Why would it take a server which is doing >> more important things LESS time and resources to do the same job as >> another machine not doing anything. > > This means you have to have two machines. At least. > You need a development machine in addition to your server, anyway. Or do you do development on a live system? And anyone who has 7.5M images has more than one machine! >> >> The answer is, it doesn't. In fact, overall, it takes the server MORE >> time and resources to do the same job. > > But you have a server with MORE resources to do the job. > And more work to do. Of course, if you're only getting 200 hit/day, that's not a problem. >> You have just shown you have absolutely no idea what load you're >> putting on your server. > > That's not true, simply you don't know which structure I had. And you > supposed I have a server doing all the job. > Oh, I understand. What do you think will happen when you get to 300 hits/day? > For generating little (thumbnails) images from other scaled image. The > resources used are really not so much. And the resources available by > the servers whre enought to do not change in a measurable way the time > delivering pages. > You really have no idea how many resources it takes, that's obvious. But then when you're only getting 200 hits/day you can do anything on your server. > Tha fact is that having more machine more powerfull not doing nothing > else that reescaling images when required in batch proceses is a waste > of money and resources. In the other side, reescaling on the fly, of > course, implies some more process but not noticable. > > Greetings > > The fact is, forcing a server with more important things to do to rescale images is a complete waste of money and resources. But when you only get 200 hits/day you have the resources to waste. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2012-05-13 22:26 -0500 |
| Message-ID | <slrnjr0ur0.4ci.hellsop@nibelheim.ninehells.com> |
| In reply to | #6007 |
On Sun, 13 May 2012 18:54:01 +0200, Shake wrote:
> Jerry Stuckle a expos? le 13/05/2012 :
>
>> You aren't making any sense. Why would it take a server which is
>> doing more important things LESS time and resources to do the same
>> job as another machine not doing anything.
>
> This means you have to have two machines. At least.
Yes. Of course. That's what real websites do. They have multiple
webserver that JUST serve page data to the outside world. They have
a dedicated database machine. Usually at least two of those, some
accessable by the webservers, some not accessable from the outside at
all except through the sync connections to the outside db server. They
have at least one development server and a separate test server, for
website development alone. Other departments have their own machines as
well. What did you think we were talking about? Some little toy website
selling railroad models at a rate of three or four wagons a week?
--
The pluses in my current job include laughing in the face of Nobel
laureates who have just lost the only copy of their data. (Hey,
I'm still a BOFH).
-- Bob Dowling
[toc] | [prev] | [next] | [standalone]
| From | Shake <QUITAESTO@QUITAESTO.NOES> |
|---|---|
| Date | 2012-05-14 09:51 +0200 |
| Message-ID | <joqdhs$a2t$1@dont-email.me> |
| In reply to | #6010 |
El 14/05/2012 5:26, Peter H. Coffin escribió: > On Sun, 13 May 2012 18:54:01 +0200, Shake wrote: > >> Jerry Stuckle a expos? le 13/05/2012 : >> >>> You aren't making any sense. Why would it take a server which is >>> doing more important things LESS time and resources to do the same >>> job as another machine not doing anything. >> >> This means you have to have two machines. At least. > > Yes. Of course. That's what real websites do. I was talking about the "server" like an entity, not entering on how these one is "phisicaly". For example the website I put as example, have two balanced front-ends with php and apache, and two other machines with mysql, sphinx and a few other servers. Images are on Amazon S3, and also we used (use) some ec2 machines. But for me all this stuff is "the server". And to batch the image scalating we are talking about using another "machine". For example the machines for developers, or testing. They, of course, ar not powerful machines. Don't need to be. And I put numbers, about 266.000 page views per day. I am talking about a real case. Not teorethical. And we tried both methods, batching and on-the-fly. And the result is: On the fly is more flexible, more quick to put on production new sizes. And it have to be used when images are not so big. If we have to scale the originals to a big size, on the fly could be a big problem. The true is that always is a problem in any manner when you have to scale to big sizes. But when you need a new little image size, and you can use the nearest bigger scaled image, process is quick enough to do on-the-fly without penalizing speed, or overload on the server. Greetings
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-14 08:04 -0400 |
| Message-ID | <joqscr$nr7$1@dont-email.me> |
| In reply to | #6016 |
On 5/14/2012 3:51 AM, Shake wrote: > El 14/05/2012 5:26, Peter H. Coffin escribió: >> On Sun, 13 May 2012 18:54:01 +0200, Shake wrote: >> >>> Jerry Stuckle a expos? le 13/05/2012 : >>> >>>> You aren't making any sense. Why would it take a server which is >>>> doing more important things LESS time and resources to do the same >>>> job as another machine not doing anything. >>> >>> This means you have to have two machines. At least. >> >> Yes. Of course. That's what real websites do. > > I was talking about the "server" like an entity, not entering on how > these one is "phisicaly". > > For example the website I put as example, have two balanced front-ends > with php and apache, and two other machines with mysql, sphinx and a few > other servers. Images are on Amazon S3, and also we used (use) some ec2 > machines. > > But for me all this stuff is "the server". And to batch the image > scalating we are talking about using another "machine". For example the > machines for developers, or testing. They, of course, ar not powerful > machines. Don't need to be. > > And I put numbers, about 266.000 page views per day. I am talking about > a real case. Not teorethical. And we tried both methods, batching and > on-the-fly. > > And the result is: On the fly is more flexible, more quick to put on > production new sizes. And it have to be used when images are not so big. > > If we have to scale the originals to a big size, on the fly could be a > big problem. The true is that always is a problem in any manner when you > have to scale to big sizes. > > But when you need a new little image size, and you can use the nearest > bigger scaled image, process is quick enough to do on-the-fly without > penalizing speed, or overload on the server. > > Greetings You can do that when you have such a light load. Get a real load and you're in trouble. But even with that, you should be resizing offline and not requiring the server to do it. But it sounds like you're too cheap to get your developers decent machines, and have no idea how to scale images. The "nearest bigger scaled image" will almost certainly give a substandard image, especially when you repeatedly rescale them. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Shake <QUITAESTO@QUITAESTO.NOES> |
|---|---|
| Date | 2012-05-14 14:25 +0200 |
| Message-ID | <joqtjq$ute$1@dont-email.me> |
| In reply to | #6022 |
El 14/05/2012 14:04, Jerry Stuckle escribió: > > You can do that when you have such a light load. Get a real load and > you're in trouble. No. The EC2 machines does the image scaling and save the results on S3. The thing is that first user getting the image will have to wait a little more. That's true, but the server will not be overloaded. Ec2 could "grow" when necesary getting more CPU to "battle" the overload without troubles. And cheapest than buying big machines to process millions ob images offline, and then put online wasting a lot of traffic... > But even with that, you should be resizing offline and not requiring the > server to do it. Not always possible, My way, first user, 2 second delay (in worst cases, reescaling 4x3 images). Your way, all users three weeks of waiting. In real traffic, new images are scaled dilued inside normal traffic in an unnoticeable wat. After putting on a new size.. next weeks or average time per pages have no noticeable changes. > > But it sounds like you're too cheap to get your developers decent > machines, Me? I am a developer. Not the boss. And as a developer I don't need powerfull machines able to reescale milions of images :) > and have no idea how to scale images. The "nearest bigger > scaled image" will almost certainly give a substandard image, especially > when you repeatedly rescale them. Of course I know. I don't repeatedly scale all of them. You talk a lot about things you don't know. I try to don't put every detail because I though yoou can at least get the chance to believe that people have do its work. How we scale images (at lest since a few months) Original size -> Big Size (watermarked if user wants) Original size -> profile Size (Watermarked if user wants) profile Size (previous to watermarking) -> Thumb_orig profile Size (previous to watermarking) -> Thumb_size_2 profile Size (previous to watermarking) -> Thumb_size_3 Thumb orig_ is the bigger thumbs we have. And new are always smaller. So from this point we use thumb_orig to create new thumb sizes. Its of course a second reescale, but for this little images is enought. And the alternative was to use the original, that usually is a to big image. Using an >5Mpixels image to generate a 100x70px (for example) image have no sense. The "important" images are original, big and profile. The others are just web little images. Greetings
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web