Image overlap

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Image overlap

      Hi,

      I have been using emWin for quite sometime now and haven't come across this before. On a window widget I am displaying few 2 buttons and 2 images. For some reason I see 2nd image in the background of first image. I checked the parameters and made sure I am not displaying the image twice. I have been using the same procedure on a couple other windows but haven't had any problems with it.

      I'd really appreciate it if someone came across this problem and could help me or any suggestions will do.

      Thank you,
      BMD

    • Hi,

      Do you have some code which shows how to reproduce it?

      Regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • Sven,

      Thank you for quick response. Please see attached code and Images I am currently using.

      Best regards,
      BMD

      Source Code

      1. #include "DIALOG.h"
      2. #include "FS.h"
      4. static const GUI_WIDGET_CREATE_INFO _aDialogCreate[] =
      5. {
      6. {WINDOW_CreateIndirect, "", TOOLS_3_SCREEN_WINDOW, 0, 0, 320, 240, 0, 0, 0},
      7. {HEADER_CreateIndirect, "", TOOLS_3_SCREEN_HEADER, 0, 0, 320, 40, 0, 0, 0},
      8. {BUTTON_CreateIndirect, "", SERVICE_BUTTON, 25, 40, 185, 35, 0, 0, 0},
      9. {BUTTON_CreateIndirect, "", ABOUT_BUTTON, 25, 90, 185, 35, 0, 0, 0},
      10. {IMAGE_CreateIndirect, "", SERVICE_ICON, 260, 40, 35, 35, 0, 0, 0},
      11. {IMAGE_CreateIndirect, "", ABOUT_ICON, 260, 90, 35, 35, 0, 0, 0}
      13. };
      16. static void _cbServiceIcon(WM_MESSAGE* pMsg)
      17. {
      18. if(pMsg->MsgId == WM_PAINT)
      19. {
      20. drawBMP_ExternalMemory("Service.bmp");
      22. }// end if
      23. else
      24. {
      25. IMAGE_Callback(pMsg);
      27. }// end else
      29. }// end function _cbServiceIcon
      31. static void _cbAboutIcon(WM_MESSAGE* pMsg)
      32. {
      33. if(pMsg->MsgId == WM_PAINT)
      34. {
      35. drawBMP_ExternalMemory("About.bmp");
      37. }// end if
      38. else
      39. {
      40. IMAGE_Callback(pMsg);
      42. }// end else
      44. }// end function _cbAboutIcon
      46. static void _cbTools3Screen(WM_MESSAGE* pMsg)
      47. {
      48. BUTTON_Handle hButton;
      49. HEADER_Handle hHeader;
      50. IMAGE_Handle hImage;
      51. WM_HWIN hWin;
      52. int Id;
      53. int NCode;
      55. hWin = pMsg->hWin;
      57. switch(pMsg->MsgId)
      58. {
      59. case WM_PAINT:
      60. // Draw the background. This is quite important because otherwise we would
      61. // still see the child window although it gets deleted.
      62. GUI_SetBkColor(GUI_BEIGE_BACKGROUND);
      63. GUI_Clear();
      64. break;
      66. case WM_INIT_DIALOG:
      67. // Initialize Tools header object.
      68. hHeader = WM_GetDialogItem(hWin, TOOLS_3_SCREEN_HEADER);
      69. WM_ClrHasTrans(hHeader);
      70. HEADER_SetFont(hHeader, GUI_FONT_20B_1);
      71. HEADER_SetTextColor(hHeader, GUI_BLACK);
      72. HEADER_AddItem(hHeader, 320, "Tools", GUI_TA_CENTER);
      74. // Initialize Service button object.
      75. hButton = WM_GetDialogItem(hWin, SERVICE_BUTTON);
      76. WM_ClrHasTrans(hButton);
      77. BUTTON_SetText(hButton, "Service");
      80. // Initialize About button object.
      81. hButton = WM_GetDialogItem(hWin, ABOUT_BUTTON);
      82. WM_ClrHasTrans(hButton);
      83. BUTTON_SetText(hButton, "About");
      85. // Initialize Service icon object.
      86. hImage = WM_GetDialogItem(hWin, SERVICE_ICON);
      87. WM_ClrHasTrans(hImage);
      88. WM_SetCallback(hImage, _cbServiceIcon);
      90. // Initialize About icon object.
      91. hImage = WM_GetDialogItem(hWin, ABOUT_ICON);
      92. WM_ClrHasTrans(hImage);
      93. WM_SetCallback(hImage, _cbAboutIcon);
      95. break;
      97. case WM_NOTIFY_PARENT:
      98. Id = WM_GetId(pMsg->hWinSrc);
      99. NCode = pMsg->Data.v;
      101. switch(NCode)
      102. {
      103. case WM_NOTIFICATION_CLICKED:
      104. CurrentButton.Id = Id;
      105. CurrentButton.State = CLICKED;
      106. break;
      108. case WM_NOTIFICATION_RELEASED:
      109. CurrentButton.State = RELEASED;
      111. WM_DeleteWindow(hWin);
      113. switch(Id)
      114. {
      115. case SERVICE_BUTTON:
      116. serviceScreen();
      117. break;
      119. case ABOUT_BUTTON:
      120. aboutScreen();
      121. break;
      123. case BACK_3_BUTTON:
      124. tools2Screen();
      125. break;
      127. case HOME_3_BUTTON:
      128. mainScreen();
      130. }// end switch
      132. }// end switch
      134. break;
      136. default:
      137. WM_DefaultProc(pMsg);
      139. }// end switch
      141. }// end function _cbTools3Screen
      143. void tools3Screen(void)
      144. {
      145. // Check if recommended memory for the sample is available.
      146. if(GUI_ALLOC_GetNumFreeBytes() < RECOMMENDED_MEMORY)
      147. {
      148. return;
      150. }// end if
      152. // Use memory devices for all windows.
      153. #if GUI_SUPPORT_MEMDEV
      154. WM_SetCreateFlags(WM_CF_MEMDEV);
      155. WM_EnableMemdev(WM_HBKWIN);
      156. #endif
      158. WM_MULTIBUF_Enable(TRUE); // Enable multibuffering prior to drawing the screen.
      160. GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), &_cbTools3Screen, 0,
      161. 0, 0);
      163. }// end function tools3Screen
      Display All


      Source Code

      1. #include "cytypes.h"
      2. #include "FS.h"
      3. #include "GUI.h"
      5. int getDataBMP(void* p, const uint8** ppData, unsigned NumBytes, uint32 Off)
      6. {
      7. #define MAX_LINE_BYTES 640 // 320 pixels, 16-bit color.
      9. static uint8 acBuffer[MAX_LINE_BYTES];
      10. int16 NumBytesRead;
      11. FS_FILE* pFile;
      13. pFile = (FS_FILE *)p;
      15. // Check buffer size.
      16. if(NumBytes > MAX_LINE_BYTES)
      17. {
      18. NumBytes = MAX_LINE_BYTES;
      20. }// end if
      22. // Set file pointer to the required position.
      23. FS_SetFilePos(pFile, Off, FS_FILE_BEGIN);
      25. NumBytesRead = FS_FRead(acBuffer, 1, NumBytes, pFile); // Read data into buffer.
      27. *ppData = (const uint8 *)acBuffer; // Set data pointer to the beginning of the buffer.
      29. return NumBytesRead; // Return number of available bytes.
      31. }// end function getDataBMP
      33. void drawBMP_ExternalMemory(const char * filename)
      34. {
      35. FS_FILE * pFile;
      37. pFile = FS_FOpen(filename, "rb"); // Open the file.
      39. // Draw the bmp image by passing a pointer to the file handle and the GetData
      40. // function.
      41. GUI_BMP_DrawEx(getDataBMP, pFile, 0, 0);
      43. FS_FClose(pFile); // Close the file.
      45. }
      Display All
      Files

      • About.bmp

        (2.59 kB, downloaded 344 times, last: )

      • Service.bmp

        (1.81 kB, downloaded 344 times, last: )

    • Hi,

      Not sure why you see the second image in the background, but when removing the transparency flag of the image you should make sure you paint the entire widget area.

      In the callback functions of the image widgets you draw only the BMPs. The Service BMP is smaller than the widget and there will be some undefined space left. I could imagine that this undefined area will show any kind of artifact (on my end it was simply black).

      Try something like:

      C Source Code

      1. static void _cbServiceIcon(WM_MESSAGE* pMsg)
      2. {
      3. if(pMsg->MsgId == WM_PAINT)
      4. {
      5. GUI_SetBkColor(MyBkColor);
      6. GUI_Clear();
      7. drawBMP_ExternalMemory("Service.bmp");
      8. }// end if
      9. else
      10. {
      11. IMAGE_Callback(pMsg);
      12. }// end else
      13. }// end function _cbServiceIcon
      Display All

      Best regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • Sven,

      Appreciate the response. Thank you so much.
      Also, when the image is touched, it clears the entire scree. The only I know to stop that from happening is to disable the image. Is there any other efficient way of doing this?

      Best regards,
      BMD

    • Hi,


      bio_med wrote:

      Also, when the image is touched, it clears the entire scree.
      This shouldn't happen at all.

      For now I have no idea why this happens on your end.

      You could try to catch the touch events of the IMAGE widget and do nothing, like:

      C Source Code

      1. static void _cbImage1(WM_MESSAGE * pMsg) {
      2. switch (pMsg->MsgId) {
      3. case WM_PAINT:
      4. _DrawBMP("About.bmp");
      5. break;
      6. case WM_TOUCH:
      7. case WM_PID_STATE_CHANGED:
      8. break;
      9. default:
      10. IMAGE_Callback(pMsg);
      11. break;
      12. }
      13. }
      Display All

      Although, this shouldn't cause such a behavior, you could also try to remove these calls:

      C Source Code

      1. #if GUI_SUPPORT_MEMDEV
      2. WM_SetCreateFlags(WM_CF_MEMDEV);
      3. WM_EnableMemdev(WM_HBKWIN);
      4. #endif
      When using multibuffering there is little to no reason of using automatic memory devices. This will produce only an overhead in regards of drawing operations. With automatic memory devices on emWin will first write into the memory devices and then draw the memory devices onto the screen. Without memory devices emWin will write directly into the frambeuffer.

      Regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.

    • Sven,

      Thank you so much for helping me out in figuring a better way to do things.

      I tried to remove the automatic memory devices but that's causing bitmaps on buttons on each screen to flicker. Can you help me understand what could be causing this?

      Thanks and regards,
      BMD

    • Hi,

      When using memory devices for windows/widgets emWin will draw the bitmaps at first into the memory devices. Once this is done the memory device will be displayed at once. If you are using no memory devices you might experience a visual build up of the image because they will be drawn line wise. This will result in a flickering effect.

      The most efficient way to avoid this would be either multi buffering (GUIDRV_Lin) or a cache (almost any other driver, e.g. GUIDRV_FlexColor). If you don't have enough memory for multi buffering or a cache you can still use the automatic memory devices. For multi buffering or a cache you need at least as many additional bytes to hold one complete screen (xSize x ySize x bytes per pixel). The automatic memory devices require just as many memory as the size of the window/widget (xSizeWin x ySizeWin x byte per pixel).

      More information about multi buffering can be found here:
      wiki.segger.com/emWin_Multi-Buffering

      A lot of users using autom memory devices in combination with multi buffering. But this is a bit over the top because there are no benefits but an overhead in drawing.

      If you can't use multibuffering or a cache, then it is time to think about automatic memory devices.

      Regards,
      Sven
      Please read the forum rules before posting.

      Keep in mind, this is *not* a support forum.
      Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
      Should you be entitled to support you can contact us via our support system: segger.com/ticket/
      Or you can contact us via e-mail.