Thank you for looking into this issue, please find enclosed sample projects for 15.2 and 13.1. We are able to see the difference between the two versions. In our application, it's worse.

Thanks,

Crystal.

Hi,

I work with Crystal (OP) at the same company. We have had more clients reporting the performance issue while scrolling the grid. I have more details to add to this case.

The issue is indeed with the FormattedTextEditor and is specific to when the formatted text contains icons. In our application, there is an option to turn on/off the presence of icons in the FormattedTextEditor column. When the column does not have any icons being rendered, there is a bit of noticeable lag while scrolling. When the column does have icons being rendered, there is a great amount of lag while scrolling. My test data only has about 400 rows of data, nowhere near the 1000 that Crystal original suggested.

When Crystal originally opened this case, our application was using Infragistics Professional 2015 Volume 2 (as indicated by the dll versions mentioned above in the notes from Crystal). This is also the version that our current clients are using where they are reporting this lag.

Since the release of our application which uses Infragistics Professional 2015 Volume 2 we have since upgraded our next release to use Infragistics Professional 2017 Volume 1. In this newer release, we do not see any lag at all during scrolling of the grid, with or without icons present in the column. I am using the exact same data for the older release as I am for the new release.

As a test, I updated the dependencies in our previous release from Infragistics Professional 2015 Volume 2 to now use Infragistics Professional 2017 Volume 1. I did not see any lag while scrolling. Although this worked in my test environment, this is not a viable option for us to update our older release of the application to use the newer Infragistics assemblies. This would be a major regression of the application both for us and our clients.

There is clearly a difference between the performance of Infragistics Professional 2015 Volume 2 and Infragistics Professional 2017 Volume 1 in regards to scrolling in the grid when there are icons present.

Are there any patches available that address this performance issue? If not, can you please provide a patch. This is becoming a major issue for our clients. We would really appreciate any help that you can provide.

Thanks,

Lindos.

Hi Lindos, 

I'm afraid I don't understand what you are asking. You say you cannot update your older applications to the newer version because you are concerned about regression - but then you are asking for a patch. But any patch we were to give you would have the same risks as a new version. You would still have to update you application to use new assemblies, re-test, rebuild, and re-distribute it to your users. So that seems like a contradiction to me. 

Having said that, if you can post a small sample project here that we can run and debug, then we can try to track down exactly what changed between v15.1 and v17.1 and I might be able to tell you what version that change was made. That would limit the number of changes you would be exposing your application to - you wouldn't have to necessarily make a two-year jump.

And maybe even potentially give you a workaround so you wouldn't have to change assemblies at all. But any way you slice it, there's no getting around rebuilding and re-distributing your application. 

Hi Mike,

In regards to the regression of the application. My concern is that if we were to upgrade the application to use a full new release of the Infragistics assemblies that this would require a full regression of the application. Instead, a small patch of the assemblies which have the performance fix would allow us to target regression to the specific areas of our application which would be affected. This is by far a much smaller area of regression. I agree that some level of regression would need to be done, however, limiting the scope would be the ideal solution.

I have done some further testing with the Infragistics dlls. I downloaded the latest release you have for v15.2 (15.2.20152.2118). Our application is currently using v15.2 (15.2.20152.2052) in which we see the performance issue.

I updated our application to use the 2118 dlls and discovered that there is no performance issues with this release. I further narrowed this down by progressively swapping out the 2052 versions with the 2118 versions. This lead to Infragistics4.Win.UltraWinGrid.v15.2.dll being the one dll where the performance issue was noticed as being fixed (note this also required me to reference the 2118 versions of Infragistics4.Shared.v15.2.dll and Infragistics4.Win.v15.2.dll as they are dependencies).

This test has at least helped to narrow down the scope of versions of where the fix may have been introduced to somewhere between the release of 2052 and 2118. I hope this can help you to take a look at what may have changed that would affect scrolling of the grid where there are icons in the FormattedTextEditor column type. I suspect the issue is not necessarily in the scrolling but more in the rendering of the field.

In the meantime, I am working on putting together a sample application which demonstrates the performance issue. This may take some time as I need to migrate the production code for the grid over to the sample application.

Would it be possible for us to distribute the three 2118 versions of the dlls alongside the 2052 ones (which are all installed in the GAC)? This could be considered a kind of patch. Do you foresee any possible conflicts which could arise from having mixed version references in our project? In other words, would 2118 be backwards compatible with 2052?

Thanks for your time,

Lindos.

Hi Lindos, 

That's great that you narrowed it down. Build 2118 might be your best best, then. I am not even sure if there were any service releases in between those two, or if they are still available. 

I took a quick look at the history of the code for 15.2, but I can't narrow it down by control, only by assembly, and most of the code for the FormattedTextEditor is in the Win assembly, which has a ton of changes for that time period, so nothing really jumped out at me. 

If you can provide a smaple that I can run and debug that demonstrates the problem, I can definitely narrow down the exact change or bug fix that fixed it, though. 

Oh... I just checked and apparently 2118 was the only Service release for v15.2. 

Also, to answer your question, all of the versions are always backward compatible (aside from the occasion breaking change that has to be made for a bug fix).

But you can't mix versions. All of the Infragistics assemblies need to be the same version. 

Hi Mike,

Thanks for looking further into this issue and for answering my questions about the version compatibility.

I will continue to attempt to try and reproduce the issue in a sample app.

If I can get the sample app to show the issue, and you are able to track down the cause to a bug in 2052 that was fixed with 2118, what would be your recommended next steps in getting this fixed in our production code? Do you provide small patches/hot fixes for such occasions? Or, would we ultimately need to do a full upgrade to 2118?

Thanks,

Lindos.

Hi Lindos, 

Well, since 2118 is the only service release for 15.2, there aren't a lot of options. There's no real middle ground here. 

The best we could hope for is that if you are able to reproduce the issue in a sample, and I can track down exactly what change fixed it (which I am pretty sure I can), then it's possible that I could find a workaround that you could implement in your code and you would not need to update your Infragistics assemblies at all - you could just fix it in your own code and that would be the most limited possible change. 

Of course, it's also possible that there is no way to work around the issue in your code - that the problem is buried deep in the control and there's no way you can get around it. In which case, the best option for you would be to update to 2118.

Hi Mike,

While I was migrating our production code over to the sample application, I came upon the code where we build the HTML for the FormattedTextEditor. We keep our images as embedded resources in the project and use the following syntax for embedding the image in the cell:

var encodedImg = FormattedLinkEditor.EncodeImage(Properties.Resources.ImageX);
var html = $"<img data="{encodedImg}" />";
ultraDataRow["Column1"] = html;

I recalled that there is an alternate way of adding images to the cell by using the src tag, with a file path to the image, and tested the following in the production code:

var html = @"<img src=""C:\Test\Imagex.png""/>";;
ultraDataRow["Column1"] = html;

The performance issue immediately went away using the src tag. It seemed to even be more performant than the "fixed" 2118 SR version using the data tag. It looks like the issue is in rendering the image using the data tag. The images being loaded are all 16x16 32 bit png around 660 bytes, nothing huge.

I have implemented a work around for the performance issue in the production code by using the src tag and putting all the images in a folder on disk instead of embedding them as a resource. While this isn't a perfect solution, I believe it will work as a patch to our code for our customers as this will have minimal impact on regression testing.

Is there any way of loading the images from embedded resources and using them with the src tag instead of loading them from disk? This would remove the dependency of having the images deployed to disk and read from there. Do you see anything out of the ordinary with how we're using the data tag with an encoded embedded resource?

If you have any other suggestions, that would be greatly appreciated.

Thanks,

Lindos.

Hi Lindos, 

Just to be sure I understand, in the code you posted here, ImageX is a string that contains the encoded version of the image for the XML? So that means that the performance issue is occuring when the FormattedTextEditor is parsing the encoded image. Hm, I can't imagine how THAT would have changed. My guess is that it didn't, and it just always been more efficient to use a file instead of a string. But it's great that you found it.

To answer your question - no, you can't use an src tag and point to an embedded resource. Although I guess in theory, you could store the image in your application as an embedded resource, then load that image into memory and then save it to a file, rather than distributing it separately with the application. You could dump it into the same folder as the exe or maybe into the machines Temp folder. Not ideal, but probably not terrible, depending on the size of your images.

We're coming up on the release for 19.2, so I'm a bit swamped at the moment. If you can send me a sample, I'd still love to check it out. But if I can find some time, I will try to do a little testing myself using images with a data tag. 

Hi Mike,

Clarifying what ImageX is.

In the Visual Studio project, a Resource file (Resources.resx) is added to the project under the Properties folder. Opening up the Resource file in Visual Studio you can select the Images section from the dropdown. The Images are added to this section by drag and drop from Windows Explorer where the image filename becomes the key in the Resource file. The Resource file has a build action of Embedded Resource.

The embedded images are referenced from the Resource file in code using the following:

var image = Properties.Resources.ImageX;

Where ImageX is the name of the image in the resource file.

We did discuss keeping the images as is, embedded in a resource file, and writing them to disk at the time they were needed. This option was ultimately rejected due to business needs and the decision to deploy the images up front in a folder was made.

If I can reproduce the issue in a sample project I will definitely send it your way.

Thanks for your help.

Lindos.