In article <out-4db86571.md-1.4.17.chris.yo...@unsatisfactorysoftware.co.uk>, Chris Young <chris.yo...@unsatisfactorysoftware.co.uk> wrote:
> Images without sizes always seem to load stretched initially before > they find their proper size. Initially, we layout the document before we have the images (unless they happen to be cached). If the document tells us what size to make an image (e.g. with <img width="M" height="N" href=...> or via CSS) then we can make the box the correct size from the start. If the document doesn't tell us what size the image will be displayed at, we need to wait until we have fetched it to set the box to the correct size. However, since we show the document before fetching the image, we have to make it some size initially. Before the image is available we show the image's alt text, so the size of any alt text becomes the (currently imageless) image box's size. Until my recent change, we always used to do the latter, ignoring an image's given dimensions. The render code always renders images to the size of the image box, regardless of the image's intrinsic dimensions. This is correct e.g. for <img width="M" height="N" href=...> where the image is to be shown at MxN, whatever the image's intrinsic dimensions. So to get back to the question, you are seeing an image plotted at the alt text box size. This is simply because something has caused that part of the document to be redrawn between the image becoming available (fetched and decoded), and the document being reflowed to give the box the correct new size. The document needs to be "reflowed" (i.e. have the layout code run on it again) when images without given dimensions are fetched because the presence of an image can affect the layout of other content on the document. Are scaled image plots particularly expensive on your system? It should be less common now. -- Michael Drake (tlsa) http://www.netsurf-browser.org/
