Hi we upgraded infragistics from 13.1 to 15.2, our client found out performance degraded when scrolling UltraGird with 1000+ rows. The more data shown in a row, the slower it is when dragging scroll bar down the page.
one of the column style is FormattedTextEditor.
We'd like to know if there is any change from 13.1 to 15.2 that affected the performance on scrolling UltraGrid.
Thanks,
Crystal,
Hello Crystal,
I followed the steps you described and I was unable to reproduce the issue with the grid’s slow scrolling. I have made two identical samples: one using 13.1, and the other – 15.2 version of NetAdvantage. In the samples, the grid has 1000 rows and FormattedTextEditor is embedded into the last column.
As I do not see any difference between the samples performance when scrolling the grid data, please feel free to modify the attached sample and send it back, or send a small sample project of your own that reproduces the issue you are describing.
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.
Crystal.
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?
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.
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.
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.
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.
So... I did a little bit of testing, but I don't think I was able to find the problem. I did find A problem in 15.2 where there is a scrolling performance issue. But in that case the images also don't display. And you didn't mention anything about your images not even showing up, so I suspect the thing I found was something else. Also, the problem I found happens with the latest build, and yours doesn't.
Anyway, at this point there's not much else I can think to do without a sample from you that reproduces the issue you are having. I have attached my sample here, just in case you want to use it as a jumping-off point.
Also, I thought of one other thing. I lot of times, performance issues are caused by Exception that are being caught and handled, so you don't see the Exception message. You might want to try setting Visual Studio to break on all run-time exceptions and see if any are occurring when you scroll the grid. It probably won't help much, but it might give us some clue.
WindowsFormsApp23.zip
The value of the field in the DataRow is being set when we update the UltraDataSource for the grid. This happens as we navigate from one business object to the next (the grid data is refreshed for each business object by first clearing the rows collection in the UltraDataSource). The code spins through a collection (the row data) in the business object and calls the UltraDataSource objects Rows.Add() method for each new row. Each new DataRow's column values are then updated. After all the data has been loaded we don't update it any further. From this point on (until the next business object is loaded) the data remains static.
In what event are you setting the value of the field in the DataRow. I assume that's done before you bind to the grid. Or are you dynamically building or changing the data as you scroll, like in the InitializeRow event of the grid or something?
Okay, that makes sense. Not sure why I was confused - it seems perfectly obvious from the code, now.