On Fri, Apr 24, 2009 at 12:31 AM, Wu Zhe w...@madk.org wrote:
Asynchronous daemon doesn't make much sense if page purge occurs on
server side, but what if we put off page purge to the browser? It works
like this:
1. mw parser send request to daemon
2. daemon finds the work non-trivial, reply
2009/4/24 Aryeh Gregor simetrical+wikil...@gmail.com:
How long does it take to thumbnail a typical image, though? Even a
parser cache hit (but Squid miss) will take hundreds of milliseconds
to serve and hundreds of more milliseconds for network latency. If
we're talking about each image
All true. The images should not be rethumb'd unless
resolution changes, a new version is uploaded, or the
cache is otherwise purged. However, on initial rendering,
the thumb generation can be a large part (especially if
rendering multiple images) of overall page execution time.
Being able to
2009/4/24 Chad innocentkil...@gmail.com:
All true. The images should not be rethumb'd unless
resolution changes, a new version is uploaded, or the
cache is otherwise purged.
Repeat: this is what we do already (not sure if that's what you're
trying to say, but should implies differently).
Roan
I'm agreeing with you. By should I meant this should
be happening already and issues with this are bugs.
-Chad
On Apr 24, 2009 1:32 PM, Roan Kattouw roan.katt...@gmail.com wrote:
2009/4/24 Chad innocentkil...@gmail.com:
All true. The images should not be rethumb'd unless resolution changes,
On 4/24/09 10:32 AM, Roan Kattouw wrote:
2009/4/24 Chadinnocentkil...@gmail.com:
All true. The images should not be rethumb'd unless
resolution changes, a new version is uploaded, or the
cache is otherwise purged.
Repeat: this is what we do already (not sure if that's what you're
trying to
Hoi,
At the moment we have an upper limit of 100Mb. The people who do
restorations have one file that is 680Mb.. The corresponding jpg is also
quite big !!
Thanks,
GerardM
2009/4/24 Roan Kattouw roan.katt...@gmail.com
2009/4/24 Aryeh Gregor
Roan Kattouw wrote:
The problem here seems to be that thumbnail generation times vary a
lot, based on format and size of the original image. It could be 10 ms
for one image and 10 s for another, who knows.
yea again if we only issue the big resize operation on initial upload
with a memory
Hoi,
The library of Alexandria uses it for the display of their awesome
Napoleontic lithographs.. It would be awesome if we had that code.. It is
actually open source..
Thanks,
Gerard
2009/4/24 David Gerard dger...@gmail.com
2009/4/24 Aryeh Gregor
On 4/24/09 11:05 AM, Michael Dale wrote:
Roan Kattouw wrote:
The problem here seems to be that thumbnail generation times vary a
lot, based on format and size of the original image. It could be 10 ms
for one image and 10 s for another, who knows.
yea again if we only issue the big resize
with a memory friendly in-place library like vips I think we will be
oky. Since the user just waited like 10-15 minutes to upload their huge
image waiting an additional 10-30s at that point for thumbnail and
instant gratification of seeing your image on the upload page ... is
not such a big
On Fri, Apr 24, 2009 at 3:58 PM, Brion Vibber br...@wikimedia.org wrote:
Best to make it explicit rather than presume -- currently we have no
such locking for slow resizing requests. :)
Yes, definitely.
___
Wikitech-l mailing list
Michael Dale wrote:
yea again if we only issue the big resize operation on initial upload
with a memory friendly in-place library like vips I think we will be
oky. Since the user just waited like 10-15 minutes to upload their huge
image waiting an additional 10-30s at that point for
Also relevant: 17255 and 18201
And as this would be a new upload ssytem, also worth mentioning 18563
(new-upload branch)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Apr 24, 2009 at 07:08:05PM +0100, David Gerard wrote:
There was a spec in earlier versions of HTML to put a low-res
thumbnail up while the full image dribbled through your dialup - img
lowsrc=image-placeholder.gif src=image.gif - but it was so little
used (I know of no cases) that I
Michael Dale md...@wikimedia.org writes:
I recommended that the image daemon run semi-synchronously since the
changes needed to maintain multiple states and return non-cached
place-holder images while managing updates and page purges for when the
updated images are available within the
Michael Dale md...@wikimedia.org writes:
I recommended that the image daemon run semi-synchronously since the
changes needed to maintain multiple states and return non-cached
place-holder images while managing updates and page purges for when the
updated images are available within the
Michael Dale md...@wikimedia.org writes:
I recommended that the image daemon run semi-synchronously since the
changes needed to maintain multiple states and return non-cached
place-holder images while managing updates and page purges for when the
updated images are available within the
Aryeh Gregor wrote:
I'm not clear on why we don't just make the daemon synchronously
return a result the way ImageMagick effectively does. Given the level
of reuse of thumbnails, it seems unlikely that the latency is a
significant concern -- virtually no requests will ever actually wait
on
Thanks for taking care of the announce mail, Roan! I spent all day
yesterday at the dentists... whee :P
I've taken the liberty of reposting it on the tech blog:
http://techblog.wikimedia.org/2009/04/google-summer-of-code-student-projects-accepted/
I'd love for us to get the students set up on
On Wed, Apr 22, 2009 at 12:54 AM, Marco Schuster
ma...@harddisk.is-a-geek.org wrote:
On Wed, Apr 22, 2009 at 12:22 AM, Roan Kattouw roan.katt...@gmail.comwrote:
* Zhe Wu, mentored by Aryeh Gregor (Simetrical), will be building a
thumbnailing daemon, so image manipulation won't have to happen
Yesterday, the selection of GSoC projects was officially announced.
For MediaWiki, the following projects have been accepted:
* Niklas Laxström (Nikerabbit), mentored by Siebrand, will be working
on improving localization and internationalization in MediaWiki, as
well as improving the Translate
2009/4/22 Michael Dale md...@wikimedia.org:
Marco Schuster wrote:
On Wed, Apr 22, 2009 at 12:22 AM, Roan Kattouw roan.katt...@gmail.comwrote:
* Zhe Wu, mentored by Aryeh Gregor (Simetrical), will be building a
thumbnailing daemon, so image manipulation won't have to happen on the
Apache
On Tue, Apr 21, 2009 at 8:16 PM, David Gerard dger...@gmail.com wrote:
2009/4/22 Michael Dale md...@wikimedia.org:
Marco Schuster wrote:
On Wed, Apr 22, 2009 at 12:22 AM, Roan Kattouw
roan.katt...@gmail.comwrote:
* Zhe Wu, mentored by Aryeh Gregor (Simetrical), will be building a
On Tue, Apr 21, 2009 at 7:54 PM, Marco Schuster
ma...@harddisk.is-a-geek.org wrote:
Wow, I'm lookin' forward to this. Mighta be worth a try to give the upper
the ability to choose non-standard resizing filters or so... or full-fledged
image manipulation, something like a wiki-style photoshop.
On Tue, Apr 21, 2009 at 8:34 PM, Chad innocentkil...@gmail.com wrote:
The main issue with the daemon idea (which was discussed at length in
#mediawiki a few weeks ago) is that it requires a major change in how we
handle images.
Right now, the process involves rendering on-demand, rather than
26 matches
Mail list logo
