summaryrefslogtreecommitdiffstats
path: root/minuitwrp/graphics_utils.cpp (follow)
Commit message (Collapse)AuthorAgeFilesLines
* TW_ROTATION: add flag to handle hardware-rotated display panelsVladimir Oltean2019-03-181-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * The existence of TW_ROTATION that implements this feature at the level of calls to libpixelflinger API closely mirrors the existence of ro.sf.hwrotation for surfaceflinger in LineageOS. * A brute-force approach was previously attempted via the BOARD_HAS_FLIPPED_SCREEN makefile flag. That code iterated over the active display surface in a double-buffered setup, and performed a "smart" memcpy from the UI drawing surface (gr_draw) onto the display surface. The problem was that, without heavy loop optimizations, that code could have never scaled for 90 and 270 degree rotation. I tried and you could literally see the for loop with the naked eye while the display surface was updating. * That code is now gone, but support for BOARD_HAS_FLIPPED_SCREEN := true is still there (now means TW_ROTATION := 180). * This patch relies on the assumption that it is impossibly difficult and non-portable to rotate whole framebuffer display surfaces, in a way that is not dependent upon the graphics backend (adf, fbdev, drm, overlay etc). Therefore, it identifies the rendering primitives that the TWRP graphics stack exposes to the GUI application above, and implements hwrotation inside each of those calls instead: - gr_line(), gr_fill() - 2D geometric shapes (lines, rectangles) - gr_blit() - graphical image resources - gr_ttf_textExWH() - font rendering - gr_fb_width(), gr_fb_height() - framebuffer resolution * The gist is to keep the backend and framebuffer (dimensions, row size etc) unchanged (because making changes there is asking for trouble), but present an altogether different reality to the calling API, according to the compile-time constant TW_ROTATION. * All (x, y) API coordinates and shapes are transformed before being actually rendered as (x_disp, y_disp) display coordinates. * With TW_ROTATION := 90 or 270 you can turn a landscape device into a portrait one, because the GUI is fooled by the reversed dimensions reported by gr_fb_width() and gr_fb_height() and renders the UI as for a different device. * For blit and text rendering operations, figuring out the transformed coordinates in display space is not enough, as the surfaces that are to be rendered have to be rotated themselves. This is handled by allocating an intermediary rotated surface on each rendering operation (not ideal), so the code with the intermediary surface is compiled out for the TW_ROTATION := 0 case. * This is still not as bad as rotating the whole framebuffer though, and on a msm8976 device the performance hit is not even noticeable (for software rendering). * Currently there is no attempt to make a connection between the TW_ROTATION and the { RECOVERY_TOUCHSCREEN_SWAP_XY, RECOVERY_TOUCHSCREEN_FLIP_X, RECOVERY_TOUCHSCREEN_FLIP_Y } settings. Change-Id: Ic8966ad5360c8a499649fdb16e242286640fd992 Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
* minuitwrp: Respect TARGET_RECOVERY_PIXEL_FORMAT config.notsyncing2019-01-161-0/+5
| | | | | | | Respect TARGET_RECOVERY_PIXEL_FORMAT config in screenshot, graphics. This fixes other wrong theme color in minuitwrp on Xiaomi MIX 2S. Change-Id: Ieb8480c411e2f0c72cc50ffca66943ab025e2b7e
* Update minuitwrp graphics in line with latest minuiEthan Yonker2016-01-271-0/+118
Note: events.cpp is still old code renamed to cpp to make it easier to call functions like gr_fb_width(). I had to modify AOSP fbdev code to provide a separate memory surface for drawing to as drawing directly to the framebuffer resulted in rendering taking about 5 times longer. I also modified AOSP adf code to provide a separate memory surface for drawing for the same performance reasons. The Nexus 9 supports adf graphics. Overlay graphics work on at least one device. Overlay provides a separate memory buffer already so performance is good. I do not have a drm device yet that I know of. I made some attempt to update the drm code to determine the correct pixel format based on the drm graphics format, but what is available in pixel flinger and what is available in drm do not line up all that well. Reports are that the Pixel C is using drm graphics, but performance is slow, likely due to the use of a mmap instead of a memory buffyer. Change-Id: Ibd45bccca6ac2cb826037aa9b2aa5065cf683eed