Hi,
I'm working on an implementation using a Sitronix 7796S LCD controller, which is driven direct, with no frame buffer, by EmWin. All works fine except a problem with alpha blending. When reading out from the display (using 8-bit 8080 interface, 16bpp), which happens for pixels that are less than 100% opaque, the read scheme has additional and unwanted dummy read cycles, leading to corrupt pixel reads. I currently have the NumDummyReads parameter of the CONFIG_FLEXCOLOR struct set to 1: if there's a 5-pix readout, I see a 4-byte read, followed by 4 3-byte reads. I expect a 3-byte read (1 dummy + 16 bits RGB), followed by 4 2-byte reads (just RGB). If I change the NumDummyReads to -1, I get 5x3 bytes. I'm not sure why FlexColor uses 3-byte reads (assuming that it's a dummy read on each byte).
Additionally, When drawing an AA shape (e.g. GUI_AA_FillCircle()), I can see the devFunc callback LCD_DEVFUNC_READPIXEL is called once per pixel, on the boundary where the AA pixels are. I control the read in this case, so the sequence is OK (1 dummy read + 2 bytes RGB). When calling GUI_DrawBitmap(), in the case that the bitmap has alpha content (8bpp alpha-only in this case), I expect the LCD_DEVFUNC_READMPIXELS or LCD_DEVFUNC_READPIXEL to be called for all alpha areas, but neither is called: FlexColor does the reads itself, resulting in the corrupt read above. Why should this be the case; that I supply the callbacks but they aren't used?
Thanks,
Henry
I'm working on an implementation using a Sitronix 7796S LCD controller, which is driven direct, with no frame buffer, by EmWin. All works fine except a problem with alpha blending. When reading out from the display (using 8-bit 8080 interface, 16bpp), which happens for pixels that are less than 100% opaque, the read scheme has additional and unwanted dummy read cycles, leading to corrupt pixel reads. I currently have the NumDummyReads parameter of the CONFIG_FLEXCOLOR struct set to 1: if there's a 5-pix readout, I see a 4-byte read, followed by 4 3-byte reads. I expect a 3-byte read (1 dummy + 16 bits RGB), followed by 4 2-byte reads (just RGB). If I change the NumDummyReads to -1, I get 5x3 bytes. I'm not sure why FlexColor uses 3-byte reads (assuming that it's a dummy read on each byte).
Additionally, When drawing an AA shape (e.g. GUI_AA_FillCircle()), I can see the devFunc callback LCD_DEVFUNC_READPIXEL is called once per pixel, on the boundary where the AA pixels are. I control the read in this case, so the sequence is OK (1 dummy read + 2 bytes RGB). When calling GUI_DrawBitmap(), in the case that the bitmap has alpha content (8bpp alpha-only in this case), I expect the LCD_DEVFUNC_READMPIXELS or LCD_DEVFUNC_READPIXEL to be called for all alpha areas, but neither is called: FlexColor does the reads itself, resulting in the corrupt read above. Why should this be the case; that I supply the callbacks but they aren't used?
Thanks,
Henry