EVM Silverlight graphical artifacts (bsp_xrplugin_opengl=1)

Hi Magnus,

Did you ever resolve this issue? I'm having exactly the same problem. I've had to revert to using Direct Draw XAML rendering for now as it's such a problem but I'm very keen to go back to OpenGL XAML rendering.

Many thanks,

Chris Chambers.

Hi Chris!

Actually there is no support for OpenGL accelerated Silverlight support according to Adeneo - at least for AM335x and the Beaglebone (which is based on the AM335x BSP).

However it was quite unfortunate that the BSP comes with the bsp_xrplugin_opengl=1 set as default, but it does not work - I spent quite a lot of hours in vain. We suffered from memory leaks, crashing and graphical artifacts until I finally completely removed the bsp_xrplugin_opengl environment variable.  Now everything is rendered by the MCU, but at least it is not crashing. Our Silverlight interface does not use any effects, animations or transforms, as they are very slow and costly.

Did you manage to get DirectX XAML rendering to work properly? I ran the CETK Display driver tests, and a lot of them failed, so I figured Direct X was out of the picture as well.

Best Regards,
/Magnus

Hi Magnus,

Thanks for your reply.

I must admit, I'm using a Freescale iMX53 on a Karo Triton module so I'm not using exactly the same platform as you, but clearly we both have the same problem so it's more likely something to do with XAML rendering using OpenGL ES rather than anything pltform specific (beyond the XAML renderer). 

I have actually asked Adenneo to take a look at this issue, as we evaluated their OpenGL XAML renderer for the iMX53 and found it suffered with the same problem - a disappointment as I was hoping they'd have seen it and fixed it themselves.

We are using Direct Draw XAML rendering on our current image and it's largely OK, although it's not as quick as OpenGL and it doesn't appear to support rotating animations. Also, it's not very forgiving when you don't tune your XAML to use hardware acceleration correctly - anything that needs bitmap caching turned on must have it, otherwise it seems to render pretty poorly.

I plan to spend a little more time investigating this issue - we have to as our XAML application needs to use scrolling animation. If I find anymore information I'll be sure to come back and let you know what I find.

Regards,

Chris.

Hi Chris,

Thank you, I would be very interesting to hear about your findings, and also if you got any response from Adeneo regarding the OpenGLES XAML rendering. 

I ran the CETK Silverlight test, (in the test application a virtual keyboard does a quite intense vertical translation, while some spaced-out graphics animate in the background). I checked the CPU load, which was around 20% for the OpenGLES XAML, and the I ran the same test using unaccellerated XAML - it totally bogged down the MCU (100% load). So the translation was accellerated  to some degree I guess, besides the artifacts, memoryleaks and crashing.

Perhaps you've already seen this article if you plan to look into a customizing the OpenGL XAML renderer, but here goes:

Implement Hardware Acceleration for Graphics in Silverlight for Windows Embedded [Reference] (Windows Embedded Compact 7)

http://msdn.microsoft.com/en-us/library/jj919286.aspx

Cheers,
/Magnus 

We also use Adeneo bsp and are having xaml(sileverlight) crashing problems. I tend to believe in bsp and doubt in our own code.

If you suggest not use opengl, I will give it a try.

The artifacts (and memory leaks) did not only appear in our Silverlight application, the problems showed up in Microsoft Silverlight applications too. But sure, for the most part I think the Adeneo AM335x BSP  code quality is OK. For our project we actually got better rendering performance when completely removing the bsp_xrplugin_opengl env variable (this disables the hardware acceleration), and most importantly - the memory leaks stopped.

Please note that we do not use any (storyboard) animations or transforms in our application. 

Hi guys,

Just a quick update from my side.

The artifact rendering problem is in Microsofts implementation of the OpenGL XAML Renderer. It's not platform/BSP specific, as this is a common component in the Windows Embedded installation and I've heard reports of it happening on at least Texas and Freescale platforms. As far as I can tell it's a problem with obtaining an OpenGL surface context, as per the error output from the XAML renderer itself:

Failure [EGL Error: 0x3003, ThreadId: 0x63c0116] [Expression: s_eglContext = eglCreateContext(s_eglDisplay, s_eglActiveConfig, EGL_NO_CONTEXT, nContextAttribs)] [Called In: COpenGLDevice::Initialize: Line 353]
ERROR: COpenGLDevice::Initialize(), hr = 0x80563003

EGL error 0x3003 is 'Could not create the EGL surface'. After scouting around I think it's something to do with the renderer not correctly driving the OpenGL API for multi-window environments. Anyway, the upshot is that I have made a number of Microsoft partners in the UK aware of the problem and I have raised a paid support incident with Microsoft themselves. As I find out more information I will post it here for you, and everyone else, to see.

Chris.

Hello,

I started to look into this issue, but before I did, I tried to reproduce the issue described on a AM335x EVM reference board as a baseline. Using the TI A8.02.30.00 BSP source code, I enabled the silverlight SIP, silverlight control panel, and silverlight IE browser, and left the BSP_XRPLUGIN_OPENGL flag set. Sysgening and booting this image on the 1.1A rev EVM board, I do not see the glitch with the SIP keyboard, nor do I see any artifacts when rendering the control panel. Below is a list of the SYSGEN variables I have enabled in the BSP (related to silverlight):

* SYSGEN_IE7_IEEXR

* SYSGEN_IE7_INETCPL_EXR

* SYSGEN_XAML_RUNTIME

* SYSGEN_CTLPNL2

The EVM uses the AM3359ZCZ, in case this is different from the version of SoC you are testing with. I will also test the AM335x StarterKit to see if I observe any artifacts with that hardware.

Do you know what version of the PowerVR binaries you have? I see two main versions myself:

* 1.7.17.4352 U7010

* 1.7.17.4352 U7006

I see the opengl artifacts and error messages on the StarterKit mentioned in the previous posts with the U7006 build but not with the U7010 build.

I'm beginning to think that my problem is not the same as the OPs problem. 

I'm using a Freescale iMX53 on a Karo Triton TX53 using the Karo BSP (which, I believe, was originally developed by Adeneo). I'm seeing rendering issues when Silverlight applications are restarted a number of times (i.e. launch and close the silverlight control panel a number of times) whereby the application window either appears as solid black or transparent, or various artefacts within the window are black and sometimes flickering). It never happens the first time the application is run, it requires that the application is re-run at least two or three times, and sometimes as many as eight to ten times.

Our issue is that we have a silverlight program which shows/hides a lot of small dialogs. Easy way to reproduce the issue is to show message box several times. From 3 to 10 times, the program will crash.

Chris Chambers1 said:

it requires that the application is re-run at least two or three times, and sometimes as many as eight to ten times.

Thanks Chris for sharing this info, and raising the issue to Microsoft! 

I recognize this error, I've remember seeing it on Beaglebone (TI AM3359) and EVM when debugging.

At least for the AM335x platform, according to the recent response from Adeneo TI support (below) it may (also) be a problem in the PowerVR library (which I believe provides the OpenGLES support for the graphics accellerator SGX530). I'll try to find some time to check this out on our Beaglebone platform. 

Thanks for looking into this. Did you have all the latest updates to WEC7 when you ran this test? (Current is May 2013)

BSP and board
We are using BSP_WINCE_ARM_A8_02_30_00, and using the (SGX Core Revision 1.21) Our AM335x EVM board is version 1.1A.

PowerVR
According to C:\WINCE700\public\PowerVR\version.txt (if this is the correct file) we've got this version.
PowerVR version: 1.7.17.4352 TI:U7010 

I was using the CoreRev125 of PowerVR libraries when testing this. I did not test v121. Since you are at the same build level of the libraries as I am at and are still seeing this issue, perhaps it is related to the core revision.

Sorry, I meant to say v125 for the PowerVR libraries.