This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Silverlight application does not work normally in WinEC7 which enabled both SGX and VRFB

Other Parts Discussed in Thread: DM3730, OMAP3530

Hi,

I build WinEC7 image for DM3730(TMDXEVM3730) with the following environment:
 BSP version:
 - WEC7 SDK for OMAP35x, AM35x and AM37x, v.02.00.00
  http://software-dl.ti.com/sdoemb/sdoemb_public_sw/wince_sdk/02_00_00/index_FDS.html
 Catalog Items checked:
 - Core OS
  - Windows Embedded Compact
   - Application - End User
    - *WordPad
 - Shell and User Interface
  - Shell
   - Graphical Shell (Choose 1)
    - *Standard Shell
  - Silverlight for Windows Embedded
    - *Silverlight for Windows Embedded
  - User Interface
   - Software Input Panel
    - Software-based Input Panel (SIP) (Choose 1 or more)
     - *SIP for Small Screens, Silverlight for Windows Embedded
 - Third Party
  - EVM_OMAP3530:ARMV7
   - Drivers
    - DISPLAY
     - *Display driver
     - *VRFB driver

When I start Wordpad application, then try to use XAMLIM(SIP, Silverlight for Windows Embedded), sometimes I can look a screen like "BlackScreen.jpg", that the softkey area in SIP window is filled with black.
And also, I can look other cases, it is written plural black lines, or it is filled with black partly.
When it works normally, I can look like "NormalScreen.jpg".

These issue are seen only when VRFB driver is enabled(VRFB SurfaceManager is used, HKEY_LOCAL_MACHINE\System\GDI\Drivers\SurfaceMgr=1).
If VRFB driver is disabled(FLAT SurfaceManager is used, HKEY_LOCAL_MACHINE\System\GDI\Drivers\SurfaceMgr=0), I can always look like "NormalScreen.jpg".

It may occur anytime when we use XAMLIM, and occurs often when Wordpad is running.
In addition, we may see similar behavior, not only XAMLIM but also other Silverlight application.

Are these known issue?
Can anyone help me to fix the issue?

Thanks and regards.

  • Hi

    Before we can figure what are the probable causes for the issues you are seeing, can you please help answer these questions:

    1. Are you doing any rotation with the display? If not, then is there any reason to enable VRFB (since it is needed only for display rotation)?

    2. Is Compositor enabled in your OS-design? If yes, then can you disable it and test your application again?

    Thanks

     Madhvi

  • Hi, Madhvi

    Thank you for your reply.

    1.
    I use a screen rotation dynamically.
    I think that enabling VRFB is necessary to play videos(WMV,etc.) when rotating a screen 90,180,270 degrees(except 0 degree), because the rotary processing with FLAT SurfaceManager(DISPC DMA) is a low performance.

    2.
    I was able to get normal behavior by disabling "sysgen_composition", even when enabling VRFB.
    But, it has a problem.
    I want to include Windows Video Player, Windows Photo Viewer, and Windows Music Player into my OS-Design.
    If selecting Windows Video Player(or Windows Photo Viewer), I can not disable it that be enabled automatically by Catalog Item Dependencies.

    Is there a good idea?

    Thanks and regards,
    Yasunori

  • Hi Yasunori

    Unfortunately, VRFB and compositor do not go well together. Here is the explanation as to why:

    http://processors.wiki.ti.com/index.php/Guidelines_for_Porting_CE6_based_DVSDK_release_to_WEC7#Limitations

    In your case, my guess is that your application is also optimized for h/w surfaces and since they are soon depleted by compositor, your application is not able to render correctly using system surfaces and hence the black regions.

    Solution: AFAIK, there are no permanent/attractive solutions, but here are a few suggestions

    1. You could ask Microsoft if the compositor can be disabled and still make Video player and photo viewer work. If not, can the compositor be changed/modified to use system surfaces and not h/w surfaces.

    2. Theoretically, you could change the VRFB surface manager to not allot views for every h/w surfaces allocated by the display driver. This way you could have many more h/w surfaces and still not use up the VRFB views (see OMAP TRM for understanding these terms). Now how to decide whether a surface needs to be associated with a VRFB view is your custom solution. You could base it off whether a surface is being used as an overlay or primary surface and is likely to need rotation OR if the surface is big enough (more than half or 1/4th the size of LCD). This is just a suggestion - how to implement this solution is an experiment for you and I am not sure about the changes needed or side effects created.

    Good Luck!

    -Madhvi

  • Also, just as an FYI you might also want to look at the release notes for WEC7 update #3.

    There have been some changes that effect some of the Silverlight apps.. like the video player. Specifically they removed some of the dependencies on the compositor.

  • Interesting, I have discovered this behaviour as well in the past, but did never know the reason for it!