Rewrite boot UI

[chenxiaolong]

The current boot UI implementation is based on TWRP. The original thought was to take advantage of its rendering and layout code to reduce the effort in adding support for hardware and integrating DBP features into the UI. However, this has been more trouble than it's worth. The UI code was heavily forked due to how entangled the UI and business logic is and updates to dependencies sometimes result in rendering issues. With the android-9.0.0_r30 libpixelflinger, the DBP fork of TWRP fails to render anything. I'm planning on dropping this code and starting from scratch.

The plan is to:

• Use AOSP recovery's minui for framebuffer abstraction. Android Q drops all #ifs in minui and replaces them with properties, making cross-device support easier.
• ~Use libpixelflinger as a 2D renderer~
• ~Use Dear ImGui as the layout/widget library~
• ~Create a custom evdev input handler~

Currently undecided:

• Use libpng for reading PNG images (DBP logo, etc.). Could also use stb_image.
• Use libwebp for reading WEBP images (ROM icons, etc.). Could also update the app to write PNG images instead.
• ~Use imgui's bundled stb_truetype for font rendering. Could also use AOSP's fork of freetype2.~

Milestones:

• [X] ~Get imgui demo running on a test device with a 32-bit ABGR framebuffer (jfltetmo) rendered using imgui_software_renderer. Complete! (Picture: 20190207_230003)~
• [ ] ~Fork and bundle libpixelflinger, replacing libcutils, libutils, and liblog with what's already available in the DBP libraries~
• [ ] ~Integrate libpixelflinger with minui to allow rendering to any supported framebuffer type and pixel format~
• [ ] ~Write custom imgui renderer that targets libpixelflinger~
• [ ] ~Write custom evdev input handler to pass touch screen and volume/power button events to imgui~
• [ ] ~Add HIDPI support. Can look at magnum for ideas~
• [ ] ~Add DBP features (autobooting, ROM switching, rebooting)~

[chenxiaolong]

I'm abandoning the idea of using imgui and am currently looking for pure 2D alternatives.

• imgui_software_renderer is too slow. On jflte, it takes >50ms for just the software rasterization stage (15-20FPS). In addition, it only works with ABGR framebuffers.
• libpixelflinger is too limited to do the software rasterization
• libpixelflinger + libagl pulls in libui, libhardware, etc. and isn't even fully GLES2 compliant
• swiftshader no longer works properly with the Subzero backend on x86_64 and using the LLVM backend results in >15MB binaries
• mesa + openswr is x86_64 only
• mesa + llvmpipe is too slow and the binaries are too large

[chenxiaolong]

Qt5 + linuxfb + evdev is also out of the question.

• QImage (and thus, QLinuxFbScreen) does not support the RGBX8888, RGBA8888, and BGRA8888 pixel formats, which are used by 134, 59, and 24 devices, respectively, as of today. The only common formats found on Android devices that are supported are ABGR8888 (drm/adf only) and RGB565.
• QLinuxFbScreen and QFbScreen do not support double buffering or page flipping.

EDIT: Maybe Qt5 is not out of the question. Just got RGBA8888 working (for jflte). HiDPI scaling just works, which is really nice. Maybe I'll just implement the missing pixel formats.

[chenxiaolong]

Qt5 + Qt Quick on jflte (RGBA8888 big endian) with working HiDPI UI and font scaling: 20190218_210435

The qtquickcontrols2 Material theme does not render properly with the software renderer (QT_QUICK_BACKEND=software), so I won't be using that. The "Universal" theme that mimic's Windows' UI works great though and achieves almost 60fps even with scrolling and animations.