[wp-trac] [WordPress Trac] #23102: Thumbnails and medium-sized images always show unconstrained dimensions in the Media panel size drop-down
WordPress Trac
noreply at wordpress.org
Wed Jan 2 11:16:33 UTC 2013
#23102: Thumbnails and medium-sized images always show unconstrained dimensions in
the Media panel size drop-down
-----------------------------+--------------------------
Reporter: jond3r | Type: defect (bug)
Status: new | Priority: normal
Milestone: Awaiting Review | Component: Media
Version: 3.5 | Severity: normal
Keywords: has-patch |
-----------------------------+--------------------------
... though they can actually be constrained! This will not happen
frequently, and might be resolved as a won't fix.
However, as I was partly responsible for the code fix in #22738, which led
to this defect, and it is a regression compared to 3.4, I thought I should
report it. So here goes ... (For more context, you may have a look at the
longer article I wrote about this on jond3r.org.)
In [23096], the fix to #22738, thumbnails and medium-sized images were
bypassed {{{image_constrain_size_for_editor()}}}, since it was thought
that they were never constrained. However this can happen if the image
size settings in the Media Settings administration panel have been
decreased between upload and use of the images. If this is the case,
{{{image_constrain_size_for_editor()}}} will constrain all the standard
image sizes to those values that currently are in effect (through the
Media Settings panel), which thus also will affect thumbnails and medium-
sized images.
To reproduce:
Upload an image large enough for medium size to be created using the
default medium size settings in the Media Settings panel (300px). Decrease
the setting to 200px. Mark the previously uploaded image for insertion in
the Insert Media panel. Choose medium size and look at the displayed
dimension (300px). Insert the image and observe how the dimension has been
decreased to 200px (through the width and/or height attributes). Thus the
inserted image is constrained, even though it is not shown in the size
drop-down.
The fix is simply to pass all image sizes (except Full) through
{{{image_constrain_size_for_editor()}}} as the provided patch shows.
Performance worries have been put forward (#22598) calling
{{{image_downsize()}}} repeatedly for many images. #22738 showed that it
was enough to call {{{image_constrain_size_for_editor()}}}, which
apparently is faster. The proposed fix implies that all processed
thumbnails and medium-sized images will have to go through
{{{image_constrain_size_for_editor()}}}, which leads to some increased
execution time.
To quantify this I did some timing tests. The code used for the tests are
shown in the file {{{timing_code.diff}}}, and the test results are shown
in {{{timing_dump.txt}}}. The absolute execution times obtained are not
that interesting, as they depend on the execution environment, which in
this case is a few years old Windows desktop. In a production environment,
considerably faster execution time is probable.
The results show an average execution time of 0.439 ms per image calling
{{{image_constrain_size_for_editor()}}}, which multiplied by 80 for a full
page of images, yields ca 35 ms in increased execution time, compared to
the code in 3.5.0. This would hardly be noticeable, and is probably
acceptable.
Out of curiosity I also tested to call {{{image_downsize()}}}, which was
used in 3.4. A call to {{{image_downsize()}}} took on average 9.78 ms per
image, which yields 782 ms for a full page, which is not that easy to
ignore. Note that {{{image_downsize()}}} fetches the attachment meta data,
which can be costly if the data is not cached, but as far as I can see
that is the case, since the meta data is fetched earlier in the function
{{{wp_prepare_attachment_for_js()}}}. Nevertheless a call to
{{{image_downsize()}}} is 22 times more costly than a call to
{{{image_constrain_size_for_editor()}}}, which gives some credit to the
worry put forward in #22598, and to the solution proposed in #22738.
Criticism is welcome, especially of the performance tests.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/23102>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list