Silveright OpenGL XAML rendering issue

Technical Support
, , , ,
1

We have a Silverlight Embedded application running on WEC7 that has been widely used for a number of years.

We have recently upgraded from an OS based on the WEC7 v1.1 beta 4 BSP to the v2.3 BSP and have started to see occasional rendering issues.

If we change the visibility of controls on the Silverlight display whilst the device is busy sometimes part of the display is rendered incorrectly. This was mostly seen just after the device was first booted or when rapidly changing between different “pages” (Silverlight user control containing different controls)

For instance instead of showing:

[upload|IF3wAcH2roaOapGKr3Q+3aSe5DQ=]

It might show something like this just after booting (ignore the different number and the size of the blue gradient)

[upload|CEYwqBu6znihwCX5l6zEKGPCf6U=]

Or when rapidly changing between “pages” it would show (the green rectangle with the yellow border was the control previously shown):

[upload|GQWHPt1Tz/RM8YKL5CS/X153vfE=]

It only happened rarely - perhaps 1 in 20 times with a heavily loaded device…

We narrowed it down to the OpenGL rendering and starting from the public code for the OpenGL XAML renderer plugin (xrrendereropengl.dll which is renamed xamlrenderplugin.dll) we believe we have identified the issue. In the OpenGL Surface class (public\common\oak\XamlRenderPlugin\OpenGL\openglsurface.cpp) the AddDirty method does not check to see if the surface has already been marked as dirty, and so overrides the existing dirty area (m_rcDirty) rather than setting the dirty area to a rectangle that includes both dirty areas.

As the Silverlight core in the OS seems to combine the XAML elements on to a smaller number of OpenGL surfaces, we’d often get the “page” background element combined with some XAML elements from other smaller controls on a single OpenGL surface. This could result in the page background’s “mark as dirty”, being replaced by the small control’s “mark as dirty” which meant only the small control’s area was rendered to the surface with the rest being whatever was previously in the surface’s pixel buffer (either uninitialized memory or whatever was previously shown).

It would only occur when the device was busy because it would only happen if the UI thread had updated a second element on the same surface before the rendering thread had rendered the first one.

We wanted to ask if you had made any changes to the version of the OpenGL XAML renderer that you supply as part of the Silverlight installer for WEC7 compared with the public WEC7 code?

If you hadn’t made any other functional changes we can use the version of the DLL we have created based off the public WEC7 code, but obviously don’t want to do that if you’ve made other changes to the DLL you supply.

2

Hi @prmartin ,

Your issue looks like this known one here:

I’m really sorry that you had to go through the debugging of the opengl renederer by yourself.
Probably we fixed the same issue.
We had another customer having similar issues, so we sent him the imx6 patched renderer to test, unfortunately we still did not integrate those fixes in out standard Silverlight installer.

I can do it now if you can confirm that the changes we did are similar to what you changed.

We also did some additional fixes to some int to float conversions where there was some precision lost and was producing little misalignment artifacts.

Additionally there are also some imx6 specific optimizations that were added to create the opengl renderer in directdraw surface, which makes it faster, but on Tegra this is done “automagically” if the target window has the exact dimentions of the screen.

4

Hi @germano.tx

I’ve attached the changes that we made - patch file

We had scoured the changelogs and had noticed that item. However given it said it was “Fixed” in v2.3b2 and the workaround only mentioned that we should contact you for an imx6 optimised renderer (which wasn’t relevant for the T20), we discounted it as not being relevant to the issue we were seeing.

I know how hard it is to come up with succinct information for release notes and changelogs, but it might be worth rewording that so it is clear the fix isn’t included in that version or in any publicly accessible files, and that the we need to ask you for a the XAML renderer for all hardware platforms.

You mention that the Tegra automagically creates an opengl renderer in a directdraw surface. At what level are we talking about? Do we need to include the DirectDraw catalog components in our OS image?

5

Hi @prmartin ,

So it looks like our changes were almost identical.

Take a look also at the float conversion stuff we fixed, i heard from that customer we fixed it for that is also fixes some other visual issues.

As for the DirectDraw on Tegra… maybe i should not have used the word DirectDraw… it’s actually using the MainFramebuffer directly, bypassing GDI, so it does not need to use the GDI Blit routines (so no need to include any DirectDraw components)

You can notice this if you have a Silverlight fullscreen app and then try to show some other windowed app (non Silverlight) in front of your application it will only shortly flash, but then be overdrawn by your Silverlight app as soon as your app draws something.

6

Hi @germano.tx ,

That is good.

Where was the float conversion stuff that you fixed? Do you have a patch or similar I could see?

Thanks for the clarification on DirectDraw.