Re: Windows binaries 64bit for PHP [message #178047] |
Fri, 11 May 2012 11:23 |
Erwin Moller
Messages: 228 Registered: September 2010
Karma:
|
Senior Member |
|
|
On 5/9/2012 6:23 PM, Jerry Stuckle wrote:
> On 5/9/2012 10:54 AM, Erwin Moller wrote:
>> On 5/9/2012 4:38 PM, Jerry Stuckle wrote:
>>> On 5/9/2012 10:23 AM, Erwin Moller wrote:
>>>> On 5/9/2012 3:17 PM, Jerry Stuckle wrote:
>>>> > On 5/9/2012 3:56 AM, Erwin Moller wrote:
>>>> >> On 5/9/2012 4:29 AM, Peter H. Coffin wrote:
>>>> >>> On Tue, 08 May 2012 22:25:26 +0200, Michael Fesser wrote:
>>>> >>>> .oO(Jerry Stuckle)
>>>> >>>>
>>>> >>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote:
>>>> >>>>>> Exactly true, but if you scale to sizes you don't need, you
>>>> >>>>>> indeed
>>>> >>>>>> use
>>>> >>>>>> more processor time! Our disk space is definitely not the
>>>> >>>>>> bottleneck.
>>>> >>>>>
>>>> >>>>> And if you repeatedly rescale the same image to the same size,
>>>> >>>>> you're
>>>> >>>>> using even more processor time!
>>>> >>>>
>>>> >>>> You missed the word 'caching'. You rescale when needed, and only
>>>> >>>> once.
>>>> >>>
>>>> >>> How is this different than pre-scaling the images?
>>>> >>>
>>>> >>
>>>> >> Hi Peter,
>>>> >>
>>>> >> It is different because they are *only* rescaled when not found.
>>>> >>
>>>> >> One approach I used:
>>>> >>
>>>> >> 1) Need image xyz_2012_march_nr12_300x500.jpg
>>>> >> (The 300x500 is dimensions needed.)
>>>> >> 2) Check if it exists.
>>>> >> If not: Create it out of original (xyz_2012_march_nr12.jpg in this
>>>> >> case)
>>>> >> and store it.
>>>> >>
>>>> >> One can easily wrap this functionality in a function.
>>>> >>
>>>> >> So the difference is that you don't need a batchjob that apparently
>>>> >> needs months and that will resize many images that are never
>>>> >> needed, or
>>>> >> never needed on that size.
>>>> >> (I have my doubts about the alleged months, but that doesn't matter.)
>>>> >>
>>>> >> Regards,
>>>> >> Erwin Moller
>>>> >>
>>>> >
>>>> > And another waste of time. You should know what size(s) you need,
>>>> > and be
>>>> > able to prescale your images. I don't think I've ever seen a site
>>>> > which
>>>> > needs more than 3-4 sizes for an image, and most sites don't need
>>>> > that.
>>>> >
>>>>
>>>> It is not that simple, Jerry.
>>>> When you have simple design-once website: yes, then I agree.
>>>>
>>>> But when you deal with a team that uses lots of pictures, you don't
>>>> want
>>>> to come back every time some design-guru decides to change the looks of
>>>> the website and needs different formats for the existing pictures. I
>>>> rather make a routine and be done with the problem.
>>>>
>>>> Regards,
>>>> Erwin Moller
>>>>
>>>>
>>>
>>> It is even easier than that, Erwin. A quick batch file can easily
>>> convert pictures to any size you want.
>>>
>>
>> Yes, I understand that.
>> The point is that I expect less than 1% of them will be used in that
>> format eventually. So it feels like a waste of diskspace to produce them
>> in all formats.
>>
>>
>>> But how often does that happen? My clients don't generally make changes
>>> to their site layout very often. And when they do, there's a lot more to
>>> it than just converting images.
>>>
>>
>> In my case it is a website for city promotion.
>> There is a huge amount of image data, and most is seldom used.
>>
>> Regards,
>> Erwin Moller
>>
>>
>
> So? You know what sizes you need (or at least you should).
How should I know?
These web designers change their mind every congress they visit.
I think it is easier to offer a simple way with dynamic scaling (AND
storing) that takes the best of both worlds: little wasted diskspace and
fast performance.
You don't
> need every possible size from 1x1 to 1000x1000 pixels.
No, but since I don't know beforehand WHAT they want tomorrow, I think
this approach is handy.
Regards,
Erwin Moller
--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
|
|
|