I have an issue with screens on the PV750 doing some funny things while in operation. The background images will blank out completely, leaving the needles and values showing on the screen. There is no direct sequence to make the backgrounds blank out, but I noticed that seems to happen more when switching between day and night modes. It also seemed to happen more frequently when and ECU or ECU simulator was connected to the PV750. It still does happen when only the PV750 is connected. One other time, the gauges on the screen produced double images. This only happened one time though. The background images blanking out happens almost every time I download the configuration into the unit and switch between screens and day/night mode. The only way to make the screens change back to normal is to remove power from the unit and power it back up again. Sometimes the problem returns, and sometimes it does not. The configuration was created by starting with the MSTD configuration. I have added a few pictures to show what is happening. Help will be greatly appreciated. I am using Build 2.1.10754 (10/22/2010) on a Windows Vista machine. Please let me know if there is a setting to adjust, if you need any more information, or if you would like me to try anything.

Thank you,
Jacob

Could you PM me your configuration zipped up. I will take a look and see if there is anything weird when i download it. I can also try creating a tar file for you to try out.

Also, can you verify that are you doing full installs from the configuration tool?

Sent this via email but thought others might benefit as well...

After chatting with our embedded guys and looking at what you're seeing and you're configuration i have a few thoughts that might be helpful to you and others as well. First of all, let me explain a bit about how the screen app (on the unit) handles images.

When you give the screen app an image to draw(such as your backgrounds) it renders it to a texture and caches it. This texture is basically screen data prerendered and ready to draw. It does this to achieve higher performance but there is a price…memory. Because textures are defined in Base2 sizes, using large images (full screen) can quickly eat up a lot of memory on the unit. For example….If you give it an 800x480 image it must store a 1024x512 texture (big enough to fit the whole image). The key to getting around this limitation is to use more smaller images rather than large ones. Basically you want images that are 128,256,512 pixels or less in each dimension(width/height)…going one pixel bigger means you jump to the next larger size….ie…a 129pixel image would be stored in a 256pixel texture. Hopefully that makes sense.

How does this affect you. Here is what I recommend you do. First off, there appears to be a caching bug in our screen application. I have made the embedded team aware and they are looking into it. But for now, I think these steps should help you get around it as well as improving the performance of your configuration.

1. Instead of storing a separate full screen image for day and night on each page cut the gauge images up. These smaller (300x300ish) images will take up a lot less texture memory.
2. Instead of putting the images on your background as image widgets, when you can place the images on the “Image” property of the rotary gauges. This will allow the rotary gauge itself to show and hide the image widgets and eliminate a gauge/widget form the screen. This also keeps the rotary gauge from having to draw its own transparent background.
3. Make sure you are using the same background image on all of the pages. (I think you are.)
4. If you can’t easily cut the images down to one image per gauge, try cutting the images in half and placing two 400x480 images on the screen for the background. This will half the texture memory with an easy change and should prevent the loss of texture your seeing.
5. As always, make sure your loading the latest firmware from the config tool via thumb drive.


Hope this helps.

Hi Jake and all others who provided support to help me resolve my issue. I appreciate the help that you all provided. Cutting the background images in half did not provide a work-around to the caching bug in the screen application. Cutting out all of the gauges individually did provide me with a stable configuration. It took a bit more time, but eventually I got it running.

In the future, will there be updated firmware that addresses this caching bug? The solution for now is to never use the full 800x480 images as background images, but hopefully this will be changed in the future.

Thanks again for the support.

Jacob

Jacob,

I have been looking at your configuration and I believe you are correct that cutting the bezels into individual sizes of each used rotary gauge and reusing them is the best solution in the short term. I have started to investigate this problem, however, it isn't a quick fix. In the future we will definitely have an update to handle using large quantities of images transparently to the user.

At the moment, you shouldn't have trouble if you can keep the amount of image memory used under 20MB of graphics memory. To roughly figure out this computation, it is the image size rounded to the nearest power of two for each dimension times 4 bytes per pixel. For example, 200 width x 200 height = 256 * 256 *4 = 262,144 bytes of image memory used. An image that is reused only takes one block of memory, so that is where you gain efficiencies.

--john

Hi John,

We ran into some more issues with these screen images. Everything seemed to be working fine, but as I started pressing more and more buttons (switching screens, entering menus, day/night, etc.), the screens started fouling up again. I changed the background images to JPEG instead of PNG (they are smaller in size).

The menus all seemed to fail more now (most are the same as that are in the MSTD 2.1). Please see the attached pictures to see what is going on. I will send my latest .db3 file to you for you to check out. I hope we can continue to work to find a better solution. In the MSTD 2.1 program, you guys have used the full 800x480 pixel images in the menus. After I added all of my graphics, the menu images all start to fail.

Once again, thanks for the help and support. I do appreciate it.

Jacob

Solution:
After several iterations with jbilleter over personal mail we have almost certainly determined the issues are with text rendering (and lots of it). The text rendering algorithms have been completely re-written in 2.2, and when we loaded this config into 2.2 to test, the problem jbilleter was experiencing went away.

2.2 should release by or before Feb 18th, 2011 (at least to the Forum)

john purdum