[popcornmix]

Now that the GUI can be run more easily at 1080p I'm just wondering if it's a good idea to re-cache fanart which has been converted from 1920x1080 to 1280x720 as a result of <fanartres>720</fanartres> in advancedsettings.xml.

I've never tried fanartres of 1080p. I don't think there will be any problems with performance, but I'm more nervous about memory usage.
Lets have a think about what's required:

Textures are generally lazily destroyed after 5 seconds of not being used.
A 32bpp 1080p texture requires 8MB on GPU. If you scroll through fanarts at, say, 2 per second then you may have 80MB of fanart textures.

The cover art tends to be even worse. If using Amber with widgets enabled (like in my video) there are 16 covers visible on Movies tab,
16 covers on TV tab, and 8 covers on favourites. (plus the skin background).

The widgets don't get freed when entering the libraries views. So if you no go into the movies view and the thumbnail view, there are 10 covers visible.
It also keeps one row above and below in memory, so there are 20 covers loaded (there is actually one extra too, probabably due to the ".." placeholder).

So now we have 21+16+16+8 = 61 covers in GPU memory.

Plus the number we can load in 5 seconds (maybe an extra 50), so 121 covers.

In my video we had imageres=512 (*), so they are 352x512 = 720K each, or 87MB.

So, if you add in the last 5 seconds of fan art. We may have up to 5 encodes/decodes in progress requiring additional decoded jpeg buffers (in YUV format).
There's the 1080p framebuffer (triple buffered) is another 24MB.
Code and data for general GPU use (maybe 16MB). There's various control lists for 3D hardware and compiled shader code (maybe 16MB)

So, you are now above 220MB of GPU memory. With gpu_mem=256 you might be okay but it could be pretty tight.

If you were to find a skin that offered a fanart thumbnail view, then you could see all bets are off.

There's also the slightly unpleasant possibility that you are decoding a 1080p video (with 8 reference frames) and you hit tab and then start scrolling your movie wall
(fortunately that scenerio is probably sluggish enough that you won't scroll very quickly through your movies).

This has been assuming 32bpp textures. You can run with 16bpp textures (and that's the default, switchable in GUI), which will halve much of this memory use.
The nice thing about 16bpp textures is it is purely transient. It doesn't affect texture cache.
In theory it could be adjusted dynamically (i.e. switch to 16bpp when gpu memory is 3/4 full).

So. My current thought is:
512M Pi: 1080p gui. 32bpp textures. imageres=512. fanartres=720. gpu_mem=256
256M Pi: 1080p gui. 16bpp textures. imageres=512. fanartres=720. gpu_mem=128

A custom option that you would probably get away with is fanartres=1080, but there may be skins or use cases that break that.

Setting <fanartres> to 1080 should result in more-or-less original resolution fanart, shouldn't it? (It actually results in 1920x1088 artwork, is that slightly unusual height anything to worry about?)

Yes, 1080 is actually an inconvenient value. Videos are encoded with a height of 1088, and 8 pixels are cropped (as macroblocks are typically 16x16).
Textures are generally padded to multiples of 16, and slower code is involved when they don't match that.
However the world is quite different now, and this sort of code (https://github.com/xbmc/xbmc/blob/master...re.cpp#L95) is not really involved, so I need to step through the code and find out it a less aligned height does actually cause any problems.
(I'm suspecting at the moment that the texture cache images are resized to 1920x1088 and then gets resized to 1920x1080 on screen, so may have a small aspect ratio error, and more resize smoothing that necesary).