Image overlap

bio_med · December 8, 2020 at 3:05 PM

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

SEGGER - Schoenen · December 8, 2020 at 3:55 PM

Hi,

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

Regards,
Sven

bio_med · December 8, 2020 at 4:03 PM

Sven,

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

Best regards,
BMD

Code

#include "DIALOG.h"
#include "FS.h"


static const GUI_WIDGET_CREATE_INFO _aDialogCreate[] = 
{
    {WINDOW_CreateIndirect, "", TOOLS_3_SCREEN_WINDOW, 0, 0, 320, 240, 0, 0, 0},
    {HEADER_CreateIndirect, "", TOOLS_3_SCREEN_HEADER, 0, 0, 320, 40, 0, 0, 0},
    {BUTTON_CreateIndirect, "", SERVICE_BUTTON, 25, 40, 185, 35, 0, 0, 0},
    {BUTTON_CreateIndirect, "", ABOUT_BUTTON, 25, 90, 185, 35, 0, 0, 0},
    {IMAGE_CreateIndirect, "", SERVICE_ICON, 260, 40, 35, 35, 0, 0, 0},
    {IMAGE_CreateIndirect, "", ABOUT_ICON, 260, 90, 35, 35, 0, 0, 0}


};




static void _cbServiceIcon(WM_MESSAGE* pMsg) 
{
    if(pMsg->MsgId == WM_PAINT) 
    {
        drawBMP_ExternalMemory("Service.bmp");


    }// end if
    else
    {
        IMAGE_Callback(pMsg);


    }// end else


}// end function _cbServiceIcon


static void _cbAboutIcon(WM_MESSAGE* pMsg) 
{
    if(pMsg->MsgId == WM_PAINT) 
    {
        drawBMP_ExternalMemory("About.bmp");


    }// end if
    else
    {
        IMAGE_Callback(pMsg);


    }// end else


}// end function _cbAboutIcon


static void _cbTools3Screen(WM_MESSAGE* pMsg) 
{
    BUTTON_Handle hButton;
    HEADER_Handle hHeader;
    IMAGE_Handle hImage;
    WM_HWIN hWin;
    int Id;
    int NCode;


    hWin = pMsg->hWin;


    switch(pMsg->MsgId) 
    {
        case WM_PAINT:
            // Draw the background. This is quite important because otherwise we would
            // still see the child window although it gets deleted.
            GUI_SetBkColor(GUI_BEIGE_BACKGROUND);
            GUI_Clear();
            break;
            
        case WM_INIT_DIALOG:
            // Initialize Tools header object.
            hHeader = WM_GetDialogItem(hWin, TOOLS_3_SCREEN_HEADER);
            WM_ClrHasTrans(hHeader);
            HEADER_SetFont(hHeader, GUI_FONT_20B_1);
            HEADER_SetTextColor(hHeader, GUI_BLACK);
            HEADER_AddItem(hHeader, 320, "Tools", GUI_TA_CENTER);


            // Initialize Service button object. 
            hButton = WM_GetDialogItem(hWin, SERVICE_BUTTON);           
            WM_ClrHasTrans(hButton);
            BUTTON_SetText(hButton, "Service");




            // Initialize About button object.
            hButton = WM_GetDialogItem(hWin, ABOUT_BUTTON);          
            WM_ClrHasTrans(hButton);
            BUTTON_SetText(hButton, "About");


            // Initialize Service icon object.
            hImage = WM_GetDialogItem(hWin, SERVICE_ICON);
            WM_ClrHasTrans(hImage);
            WM_SetCallback(hImage, _cbServiceIcon); 


            // Initialize About icon object.
            hImage = WM_GetDialogItem(hWin, ABOUT_ICON);
            WM_ClrHasTrans(hImage);
            WM_SetCallback(hImage, _cbAboutIcon);            


            break;    
   
        case WM_NOTIFY_PARENT:
            Id = WM_GetId(pMsg->hWinSrc);
            NCode = pMsg->Data.v;
            
            switch(NCode) 
            { 
                case WM_NOTIFICATION_CLICKED:
                    CurrentButton.Id = Id;
                    CurrentButton.State = CLICKED;
                    break;                
                
                case WM_NOTIFICATION_RELEASED:
                    CurrentButton.State = RELEASED;


                    WM_DeleteWindow(hWin);


                    switch(Id)
                    {
                        case SERVICE_BUTTON:
                            serviceScreen();
                            break;


                        case ABOUT_BUTTON:
                            aboutScreen();                        
                            break;
                    
                        case BACK_3_BUTTON:
                            tools2Screen();
                            break;
                    
                        case HOME_3_BUTTON:
                            mainScreen();


                    }// end switch
                    
            }// end switch             


            break;


        default:
            WM_DefaultProc(pMsg);
    
    }// end switch


}// end function _cbTools3Screen


void tools3Screen(void) 
{
    // Check if recommended memory for the sample is available.
    if(GUI_ALLOC_GetNumFreeBytes() < RECOMMENDED_MEMORY)
    {
        return;


    }// end if


    // Use memory devices for all windows.
    #if GUI_SUPPORT_MEMDEV
        WM_SetCreateFlags(WM_CF_MEMDEV);
        WM_EnableMemdev(WM_HBKWIN);
    #endif


    WM_MULTIBUF_Enable(TRUE); // Enable multibuffering prior to drawing the screen.


    GUI_CreateDialogBox(_aDialogCreate, GUI_COUNTOF(_aDialogCreate), &_cbTools3Screen, 0,
                        0, 0);


}// end function tools3Screen

Display More

Code

#include "cytypes.h"
#include "FS.h"
#include "GUI.h"


int getDataBMP(void* p, const uint8** ppData, unsigned NumBytes, uint32 Off)
{
    #define MAX_LINE_BYTES 640 // 320 pixels, 16-bit color.


    static uint8 acBuffer[MAX_LINE_BYTES];
    int16 NumBytesRead;
    FS_FILE* pFile;


    pFile = (FS_FILE *)p;


    // Check buffer size.
    if(NumBytes > MAX_LINE_BYTES) 
    {
        NumBytes = MAX_LINE_BYTES;


    }// end if


    // Set file pointer to the required position.
    FS_SetFilePos(pFile, Off, FS_FILE_BEGIN);


    NumBytesRead = FS_FRead(acBuffer, 1, NumBytes, pFile); // Read data into buffer.


    *ppData = (const uint8 *)acBuffer; // Set data pointer to the beginning of the buffer.


    return NumBytesRead; // Return number of available bytes.


}// end function getDataBMP


void drawBMP_ExternalMemory(const char * filename) 
{
    FS_FILE * pFile;


    pFile = FS_FOpen(filename, "rb"); // Open the file.


    // Draw the bmp image by passing a pointer to the file handle and the GetData
    // function.
    GUI_BMP_DrawEx(getDataBMP, pFile, 0, 0);


    FS_FClose(pFile); // Close the file.


}

Display More

SEGGER - Schoenen · December 10, 2020 at 3:01 PM

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

static void _cbServiceIcon(WM_MESSAGE* pMsg) 
{
    if(pMsg->MsgId == WM_PAINT) 
    {
        GUI_SetBkColor(MyBkColor);
        GUI_Clear();  
        drawBMP_ExternalMemory("Service.bmp");
    }// end if
    else
    {
        IMAGE_Callback(pMsg);
    }// end else
}// end function _cbServiceIcon

Display More

Best regards,
Sven

bio_med · December 10, 2020 at 3:21 PM

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

SEGGER - Schoenen · December 11, 2020 at 8:59 AM

Hi,

Quote from bio_med

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

static void _cbImage1(WM_MESSAGE * pMsg) {
  switch (pMsg->MsgId) {
  case WM_PAINT:
    _DrawBMP("About.bmp");
    break;
  case WM_TOUCH:
  case WM_PID_STATE_CHANGED:
    break;
  default:
    IMAGE_Callback(pMsg);
    break;
  }
}

Display More

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

C

#if GUI_SUPPORT_MEMDEV
        WM_SetCreateFlags(WM_CF_MEMDEV);
        WM_EnableMemdev(WM_HBKWIN);
    #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

bio_med · December 14, 2020 at 3:16 PM

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

SEGGER - Schoenen · December 15, 2020 at 8:21 AM

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:
https://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

Image overlap

Participate now!

Tags

Users Viewing This Thread