Yes, effectively. It's checking that the fixed point arithmetic will not overflow the integer part. I can use UINT16_MAX instead (and if anyone ever tries to use an image with that many pixels I'm sure they'll hit other problems first)

If it doesn't fit then the backend routine - gfx_fb_cons_display() - will just not draw it on the screen. Although I've included some basic sanity checks in this function there does not seem to be any point in duplicating the checks from the backend.

Can you make a comment to note this, otherwise it's quite confusing to know that is the case and the fact that we're doing scaling here and there is probably going to be lost.

Although it's safe to draw off the screen, I've split the coordinate check in two so that the bottom right position is checked after the calculations. I think that's a better approach.

tem_image_display() marks a rectangular area of the screen so that scrolling is handled properly (the image is copied up when the screen is scrolled). The new flag allows this to be skipped meaning that you can put an image at the top right of the screen, say, and have it persist while the text scrolls (if you wish).
Braces added.

There is a bit more about scrolling. It surely is my bug not having good comment there... The original tem (and what we still have in our kernel) is built to work on small resolutions and not optimized for large screens - the operations are performed with full lines etc. To get screen to perform, currently in loader, we do build screen "map" with chars and attributes, and we will only copy differences (in simplest form atm -- we only check line tails). For images, I did add extra attribute in that map, and we always do copy the image areas. This optimiztion is done in terms of terminal char areas.
And yes, surely we can interpret this optimization in more than one way:)

I'm doing unsigned fixed point arithmetic and using the top 16 bits of the 32-bit value for the integer part and the lower 16 bits for the fractional part. To store an integer (png->width - 1) in this scheme, it needs to be shifted 16 bits left and it can then be divided by (fwidth - 1) to establish the number of pixels across in the source image that correspond to a single pixel in the target.

I think it's worth a comment that explains what's going on here as it's pretty hard to parse initialy that this is what we're doing.

It is built with:
/opt/gcc-4.4.4//bin/gcc -Os -fPIC -ffreestanding -Wformat -msoft-float -mno-mmx -mno-3dnow -mno-sse2 -mno-sse3 -mno-sse -mno-avx -fshort-wchar -mno-aes -std=gnu99 -Wno-pointer-sign -Wno-empty-body -m64 -D_STANDALONE -DEFI -nostdinc -I. ... -c ../../../common/gfx_fb.c

as is the rest of loader.

Yes, the entire loader is intended to be built as c99. I still have patch waiting to re-organize all makefiles and collect the build options/arguments to one single location.

I'm working out the contributions to each pixel value by combining adjacent pixels, assigning each a proportion of a total of 128

- effectively pixel1 * X + pixel2 * (128 - X) I do this for two pairs of pixels then I combine the two pairs in the same way. To get back to the integer result, I need to divide again by (128 * 128) which is achieved by shifting 14 bits right. Doing the shift once, at the end, provides greater precision.

Can you please elaborate in a comment about this? That way someone else reading it won't find it quite so magical either.

Yes, fixed, thanks.

Thanks, fixed.

Taking only the bottom 32-bits in that case is fine and consistent with the other fb-* functions.