Rework TFT Color UI layout

[jmz52]

Description

Improvements:

• Separated UI layout from code. UI layout for every resolution are defined in individual header files.
• Added support for themes where bootscreen logo, colors and UI elements locations can be customized.
  Theme can also be used to enable some UI features:
  #define MOVE_AXIS_SCREEN // Special "Move Axis" screen activated by touching coordinates area

Fix multiple UI layout issues in Color_UI:

• 320x240
  • SD card icon is flickering when card is not inserted
• 240x320
  • Two SD card icons, one always white (like card is inserted)
  • Two Menu icons, one is off the screen
  • Print time misaligned, it overlaps with progress bar and SD card icon
• 480x320
  • SD card and Menu icons are not displayed making it impossible to enter menu without encoder
  • Navigation icons misaligned
• 320x480
  • SD card and Menu icons are not displayed making it impossible to enter menu without encoder
  • Navigation icons misaligned
  • Fan icon misaligned
  • Coordinates bar is too small for XYZ coordinates
• 480x272
  • SD card and Menu icons are not displayed making it impossible to enter menu without encoder
  • Navigation icons misaligned
  • Heaters and Fans areas overlaps with Coordinates bar, causing flickering

Requirements

Color_UI

Benefits

Simplified Layout development for new screen resolutions.
Simplified color and UI layout customization.

Related Issues

Fixes #26064

Conflicts with #26068

[jmz52]

ui.move_axis_screen() functions for each resolution were left intact, so there is some code duplication left in them.

Updated layouts with various fonts and colors:

320 x 240

240 x 320

480 x 320

320 x 480

480 x 272

[lukasradek]

ui.move_axis_screen() functions for each resolution were left intact, so there is some code duplication left in them.

Great job 🙂. I am working on a small rework of Move Axis Screen, so I will take care of the duplication soon.

[thinkyhead]

Ah, I was just working on this same stuff for like a week. Was going to keep posting my progress in #26068. It looks like you've at least got more comprehensive work done on it than I have so far. A big part of my work was to move more of the very similar and reused code to the ui_common.cpp file, and to remove some of the redundancies within each implementation of draw_status_screen. I'll be sure to review this and compare to what I have so far, and we'll end up commiting a mashup of these two PRs.

[thinkyhead]

One of the things I started on was PORTRAIT layouts for TFT_RES_480x272 and TFT_RES_1024x600. How much extra work will those be?

[thinkyhead]

Review notes:

• Well this is a thing of beauty and supersedes my efforts by a mile. Very nice to have layout separated from the drawing code, and should make it much easier to deal with new screen sizes.
• Those 1024 x 600 screens are particularly large, so we should show the E total value in addition to XYZ. We could probably fit E onto the 480-pixel wide screens as well.
• I would love to have the option to set a very large font size for these screens, but if these are bitmap fonts then obviously that is a tall order. But, if a font is magnified to intentionally have a blocky appearance and is not anti-aliased that could be a nice look. We should play with that, as it would be great to be able to see the current progress and values from across the room.
• As mentioned above, portrait layouts for 272 x 480 and 600 x 1024 would be a nice addition to complete the package.

So I will just have a quick peek through all the drawing code and see if it's worth making any tweaky tweaks. I expect this is pretty complete and I don't expect to change much. Overall, excellent job. This is a heroic effort, and thank you for making it.

[jmz52]

For PORTRAIT mode your changes to Conditionals_LCD.h should be incorporated to this PR to define appropriate TFT_WIDTH, TFT_HEIGHT and LCD_HEIGHT.
Then you need can copy ui_240x320.h to ui_272x480.h and ui_320x480 to ui_600x1024.h to get instant ugly portrait UI for these new resolutions. Then it just pixel hunting to update elements sizes and locations in these two new headers files to get a better layout. Code it the same for all resolution with one exception - ui.moxe_axis_screen().

The ui.moxe_axis_screen() is not my code and I have not looked into it yet, right now elements locations for this screen are part of these 3 files:

ui_move_axis_screen_320.cpp
ui_move_axis_screen_480.cpp
ui_move_axis_screen_1024.cpp

[jmz52]

Unifont is a pixel map in it core, and it does not scale well. It has to be an integer (x2 , x3, etc) scaling to get an ok looking font.
NotoSans does not look good without AA, at least on 320x240 and 480x320 screens.

Here are next scale of Unifont (x3) and few bigger sizes on AA Notosans, fresh from the oven.
No idea how they are looking on the screen though, they are just generated.

[thinkyhead]

Unifont is a pixel map in it core, and it does not scale well…

Integer scaling of x2 or x3 could work on the 1024 screens, but pretty much only that one. It's only numerical values, progress bar, and maybe a couple other elements that really need to be enlarged.

On the larger screen layouts we could draw the progress bar as a circle — i.e., a pie chart with a large hole in the middle. I've also been thinking of implementing the heater bars and additional icon states that I previously implemented for the standard graphical displays. They would look much nicer on these screens, and the "leveled bed" indicator might be more obvious.

I'll play around with these ideas and those portrait layouts in the near future. There are some more important issues to tackle for the next release before getting too distracted by the joy of design.

I've been working on an Inkscape project redoing the "Outrun" style Marlin logo and associated elements. I have a bit more work to do on that, then I'll add it to the Marlin project pile in buildroot/share/pixmaps. That way we can make a new assortment of boot logos for ColorUI, Ender 3 V2, etc. that have better compression and a cleaner look. If future versions of Marlin have an improved appearance it will be another cause for users and vendors to update, which would be nice.

[thinkyhead]

On another note, a major part of my layout testing was trying to make sure the Time Elapsed and Remaining were looking good, moving the time icons above or doing whatever else was needed to keep them from being overlapped by the SD Card and Settings buttons. To help with that work I made a temporary change to Stopwatch::duration to return 2*60*60 + 12*60 + 34 (or whatever) … but of course this could also be done at the string level in the layouts. When these times get very long, like over a day, the appearance can get a bit messy. We should definitely fix these up if that's not already sorted out.

Another idea would be to simply implement HAS_EXTRA_PROGRESS instead of showing them both at once. That would allow Color UI to show Elapsed / Remaining / Percent Complete / Interaction Time as intended, according to the configured options, by calling ui.rotate_progress(). If we want to preserve the current layouts, we could adjust the HAS_EXTRA_PROGRESS flag according to how many items need to be shown, and only do the rotation when the configuration specifies more times than we can fit on the screen.

[jmz52]

x2 Unifont (20px) is for 480x320 displays, it is already there and you can see how it looks on screenshots above.

I've also been thinking of implementing the heater bars and additional icon states that I previously implemented for the standard graphical displays. They would look much nicer on these screens, and the "leveled bed" indicator might be more obvious.

I was thinking it that direction too. My idea was to make 4-6 new fancy looking screens (idle, printing, temperature, motion, media browser, bed leveling) and use them as a foundation for new "modern ui" (which is why existing ui file is called ui_color_ui.cpp) with an ability to enter existing menu system. This way the new UI can be gradually improved while still retaining power of complete menu system.
This potential new UI requires new vector icons that can be converted to bitmaps of different scale, so then can look good on any resolution. And it will probably requires multi-font or multi-size support, which will lead to the necessity of external storage for fonts and icons.

On another note, a major part of my layout testing was trying to make sure the Time Elapsed and Remaining were looking good, moving the time icons above or doing whatever else was needed to keep them from being overlapped by the SD Card and Settings buttons.

Time Elapsed and Remaining will not overlap with SD and menu icons, but can be clipped if text is too long.
My idea for future improvement is to use custom int to text translation, to show top 3 (days, hours, minutes / hours, minutes, seconds) or two (hours, minutes / days, hours) parts only depending on screens' resolution, but the ui.rotate_progress() might allow to display more then just two different options.

Those 1024 x 600 screens are particularly large, so we should show the E total value in addition to XYZ. We could probably fit E onto the 480-pixel wide screens as well.

For 1024x600 UI all 4 XYEZ values are already displayed (just no screenshots for this resolution), but for 480x320 this might be too tight placement.
However for smaller screens in "landscape" mode we can use printingIsActive() to display most relevant information - XYZ when idle and EZ when printing.