Repository navigation
Panel_M5UnitLCD: fix ARGB image writes, reads after image writes and the first draw after reset - #355
Merged
Merged
Conversation
…the first draw after reset writeImageARGB set a one-row window and sent the first w pixels of src_data, ignoring h and the source position. pushAlphaImage passes the whole clipped rectangle, so only the first row was drawn, and with clipping on the left or top the wrong pixels were sent. Rows are now sent in a window of h rows, each indexed through src_x32 / src_y32 and src_bitwidth as the pixel copy functions do. They are streamed as one raw command without checking the unit's buffer in between, as the single-row version did: the unit consumes raw pixel data faster than the bus delivers it (a full 135x240 ARGB frame sent at 1 MHz arrives intact). writeImageARGB also byte-swapped every source pixel as if it were argb8888_t, while pushAlphaImage accepts bgra8888_t too, which keeps the bytes in the reverse order, so its colors came out wrong. Sources tagged argb8888_4Byte (bgra8888_t) are now sent without the swap; every other source, including the one-row buffer of the anti-aliased rotate/zoom path, keeps the previous swapped send. After CMD_RESET the unit answers READ_ID and consumes a NOP at once, but its first drawing command takes about 250 ms more. Pixel data streamed in that period is dropped: an image drawn right after init() lost its rows after the first dozen (both raw ARGB and RLE), while short fill commands were unaffected. The reset path now queues a one-pixel fill and waits until the unit has consumed it, the same buffer-count wait readRect uses. init() with reset takes about 250 ms longer; init_without_reset() is unchanged. After an image write, a read whose column range equals the cached one returned zeros: _set_window() skipped CASET because the range was unchanged, and the unit then answers the read with zeros. Reading a full-width row right after a full-width pushImage() or pushAlphaImage() therefore gave all zeros. readRect() now invalidates the window cache so CASET and RASET are always sent; this costs a few bytes per read.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes
writeImageARGBdrew only one row. It set a one-row window and sent the firstwpixels ofsrc_data, ignoringhand the source position.pushAlphaImage()passes the whole clipped rectangle, so only the first row appeared, and with clipping on the left or top the wrong pixels were sent. Rows are now sent in a window ofhrows, each pixel indexed throughsrc_x32/src_y32/src_bitwidthas the pixel copy functions do.bgra8888_timages came out in the wrong colors.pushAlphaImage()accepts bothargb8888_tandbgra8888_t, and every source pixel was byte-swapped as if it wereargb8888_t. Sources taggedargb8888_4Byte(bgra8888_t) are now sent without the swap; every other source, including the one-row buffer of the anti-aliased rotate/zoom path, is sent as before.Image data lost right after
init(). AfterCMD_RESETthe unit answersREAD_IDand consumes a NOP at once, but its first drawing command takes about 250 ms more, and pixel data streamed in that period is dropped. An image drawn right afterinit()lost its rows after the first dozen (both raw ARGB and RLE images); short fill commands were not affected. The reset path now queues a one-pixel fill and waits, with the same buffer-count waitreadRect()uses, until the unit has consumed it.init()with reset takes about 250 ms longer;init_without_reset()is unchanged.readRect()returned zeros right after an image write. When the read used the same column range as the cached window,_set_window()skipped CASET, and the unit then answered the read with zeros. Reading a full-width row right after a full-widthpushImage()orpushAlphaImage()therefore gave all zeros.readRect()now always sends the window; this costs a few bytes per read.Checked
readPixel()unless noted.pushAlphaImage(argb8888_t) 40x30 at (10,10)pushAlphaImage40x30 at (-10,-8) (clipped left and top)pushAlphaImage(bgra8888_t) 40x30pushImage(RGB565) 40x30 drawn right afterinit()readRect()of full-width rowspushAlphaImage135x240 in one call at 1 MHz