Slow performance of MatrixLEDMarquee control

Jul 6, 2009 at 3:46 PM

Hi,

Made a funky looking dashboard using your control library. From an appearance point of view, everything is good...unfortunately, while the Matrix LED runs fine on my dev machine (a quad core), it runs unacceptably slowly on the machine we wish to deploy to.

With the minimum allowable timespan, it still only scrolls two "dots" per second, which is less than half the speed it manages on my PC, and is too slow. I have tried EVERYTHING to get around this, from specifically coding all my brushes to be Frozen to changing the hardware acceleration on the client to turning off hyperthreading: nothing makes a big difference.

I am inclined to guess that the code that scrolls the characters could be optimised; however, the version of the source I downloaded wouldn't work with my dashboard (falls over in PlatformIndependentDashboard.cs in method GetChildDoubleAnimation (seems to require a storyboard???)), therefore I cannot test this hypothesis.

Your controls look the business but they need to run faster to be of use in a typical workplace, IMO. We are definitely bigger than a small company, but I find it hard to believe I'll be able to get a quad core just to run a data display screen.

Jul 6, 2009 at 4:08 PM

...OK, unless the source code I have is out of date, I know why it runs so slow:

In MatrixLEDCharacter.xaml.cs you have the following method:

private void TureLedOnOrOff(bool on, Ellipse el)

In said method, you have a line of code, thusly:

el.Fill = new SolidColorBrush(on ? this.LedOnColor : this.LedOffColor);

Creating a new brush for EVERY dot is HUGELY inefficient. Drawing with a brush that hasn't had Freeze called on it is HUGELY inefficient.

How I Would Fix:

Create two module variables, one a Brush for LedOn, one for LedOff. Create new brushes for these when the LedOnColor/LedOffColor is set, and then call the Freeze method on these brushes (this is important, will double performance). Then use these brushes for drawing, rather than creating a new brush per event.

Note: using Freeze on a brush before drawing with it is always a good idea when dealing with WPF, for future reference.

Jul 6, 2009 at 5:16 PM

Implemented this locally and have increased speed by 300%.

 

My source code is out of date, so I won't retro fit it, but it took me 3 minutes to fix and I'm a VB.NET programmer not C#, so you'll have no problems, here is my new version of the method(s) with the problem for your reference:

        private  void TureLedOnOrOff(bool on, Ellipse el)
        {
            if (el != null)
            {
                if (on)
                {
                    el.Fill = LEDOnColorBrush;
                }
                else
                {
                    el.Fill = LEDOffColorBrush;
                }
            }
        }

 
        public Color LedOffColor
        {
            get { return (Color)GetValue(LedOffColorProperty); }
            set
            {
                SetValue(LedOffColorProperty, value);
                LEDOffColorBrush = new SolidColorBrush(value);
                LEDOffColorBrush.Freeze();
            }
        }


        public Color LedOnColor
        {
            get { return (Color)GetValue(LedOnColorProperty); }
            set
            {
                SetValue(LedOnColorProperty, value);
                LEDOnColorBrush = new SolidColorBrush(value);
                LEDOnColorBrush.Freeze();
            }
        }

 

 

Coordinator
Jul 7, 2009 at 12:44 PM

Thanks Inferno.

I applied the fixes in a slightly different manner to deal with silverlight lack of a freeze method. A little experimentation last night seemed to show that the freeze was the bigger factor over the constant creation of brushes. This library started out in silverlight and has been ported to WPF, so I missed the requirement.

The marquee is more of a simulation than anything. It can be rewritten to be less pure and more efficient. For example using a fixed buffer for all leds rather than the matrix character class which commumicates using events. I will address these issues later. Is the performance acceptable now?

I was quite surprised that the performance was so poor on your machines as I write most of the code on a three year old laptop with a pretty cruddy graphics chip in it :-)

Thank you very much for the feedback and for the code, it's nice to know pepole are using the library.

If it's possible perhaps you could attach a screen shot of how you are using it? Obviously if it display sensitive data I understand it won't be possible. I would like to show some shots of real life uses on the pages soon. 

 

 

 

Jul 7, 2009 at 2:25 PM
Edited Jul 7, 2009 at 2:34 PM

"If it's possible perhaps you could attach a screen shot of how you are using it? Obviously if it display sensitive data I understand it won't be possible. I would like to show some shots of real life uses on the pages soon."

I'll ask my boss, though obviously we'd need to black out the company logo, considering the data being displayed...I think he will say no but worth a shot.

"I was quite surprised that the performance was so poor on your machines as I write most of the code on a three year old laptop with a pretty cruddy graphics chip in it :-)"

The screen has a looootttt of marquees on it!

"The marquee is more of a simulation than anything. It can be rewritten to be less pure and more efficient. For example using a fixed buffer for all leds rather than the matrix character class which commumicates using events. I will address these issues later. Is the performance acceptable now?"

Performance is OK since my fix, I am considering re-doing it to simply blit a bitmap rather than using filled elipses though, which should make it lightning.

Thanks for taking the time to write these controls: I wouldn't have had the patience with them and they do make our screen look good. I'll post a screenshot, permission allowing, later.

 

--Missed this first time

"I applied the fixes in a slightly different manner to deal with silverlight lack of a freeze method. A little experimentation last night seemed to show that the freeze was the bigger factor over the constant creation of brushes."

Sure, but it is still inarguably better to not create the new brush, whether or not it is the bigger part of the issue. Creating an object repeatedly on the fly when you don't need to is rarely good practice, would you not agree? :-)