FM layout

[AlexP]

That shares the image files, but you'd still end up having to keep track of them somehow. I can't imagine that the current method wastes space by remembering the filename once the WPS is tokenized and buffered, let alone if a different WPS is loaded, then they change back, etc. Separating them into two files means you need a fair bit of complexity to keep images from existing in memory twice.

How does it work currently with .wps and .rwps?

[Llorean]

The WPS and RWPS are displayed on different size and usually bit-depth screens. In all honesty my guess right now is that there's no logic at all. In the few rare cases where an image is duplicated it's just in RAM twice.

In the case of the remote screen, there's likely to be several repeated images. Backdrop, volume display, battery display, etc are (in many cases) likely to not only be repeated, but be using the majority of the image buffer. You'll want some way to "share" them between screens if they are the same.

[AlexP]

Yeah, that's sort of what I was getting out.  Either way, I'm sure people will cope fine with whichever system turns out to the easiest/best to implement.

[Llorean]

Well, but the image buffer for the rwps is TINY. They're mono, they don't have a backdrop buffer, and the resolution is small. Another full screen that's fully themable would either need to have another significant amount of memory put aside for it, or ideally it should have some method of reusing images.

[JdGordon]

nope... the image buffer for the RPWS atm is freeking HUGE! its the same size as the main screen buffer and 1/4 the bit depth... this is partly the reason for FS#9886 (which could do with testers )

[Llorean]

Well "the amount of memory needed for the RWPS" is tiny then, even if the amount currently used is huge.

It should be 1/16 the bit depth, right? 1bpp instead of 16bpp?

[JdGordon]

ah yeah, either way, a massive amount of RAM is being wasted currently for it. (well not really massive when you tihnk about it being used for compressed audio instead, but it does make the main binary look bloated.)