Performance question when printing to matrix-printer

[PJoyeux]

Hi,

I finally got some time to continue working on this issue...

Doing this I found out, that you don't have to start a print or export job to see the difference.

Just load the report in the designer and switch to the preview-tab. When you do this, the data is fetched and the report prepared. This works at the same speed for both reports (Test DB Laser.mrt and Test DB Matrix.mrt).

BUT...

When you then press the button for the special Matrix-Preview (the right-most button in the preview-window's toolbar) a new preview-window should could come up showing the special Matrix-Preview. And this where it starts to take VERY LONG! You can really easily try this yourself... Just create a similar Matrix-Report like mine using one of your database, let it use approximatly 5000 records, put a databand on it with 3-4 fields, then go to preview and then click the Matrix-Preview-Button.

Further, I have noticed that the more "Font-Tags" I have in my matrix-report (like <#doublewitdh> or <#b>) the longer it takes until the Matrix-Preview-Window comes up. This is direcly linked, just add some of those font-tags to the report you just created and call the Matrix-Preview-Button again...

Since I think that the rendering of the Matrix-Preview is similar to using PrintToDotMatrix() the source of the whole issue must be found there.

I have a feeling that the whole issue is related to the replacement of those Font-Tags with the actual Printer-ESC-Codes...

These are my settings:

Code: Select all

                StiOptions.Viewer.DotMatrix.CutLongLines = false;
                StiOptions.Viewer.DotMatrix.KillSpaceGraphLines = false;
                StiOptions.Viewer.DotMatrix.KillSpaceLines = false;
                StiOptions.Viewer.DotMatrix.DrawBorder = false;
                StiOptions.Viewer.DotMatrix.PutFeedPageCode = false;
                StiOptions.Viewer.DotMatrix.UseEscapeCodes = true;
                StiOptions.Viewer.DotMatrix.EscapeCodesCollectionName = "EpsonFX";

Could one of these settings influence the rendering so badly?

I hope you can now reproduce this using these informations and that you find the source of this behaviour and maybe even a solution/workaround...

Cheers,
Pascal

[HighAley]

Hello.

We have found the cause of the slowdown. It was in the internal WPF methods.
We have made an improvement.
Please, check our next prerelease build.

Thank you.

[PJoyeux]

Sounds good, thank you!

Please, check our next prerelease build.

Which is due when? Next friday as always?

Cheers,
Pascal

[HighAley]

Hello, Pascal.

Which is due when? Next friday as always?

Yes, our next prerelease build will be available tomorrow.

Thank you.

[PJoyeux]

Hi,

I just saw that friday's upload was rather monday's upload...

I noticed in the list of changes, that you wrote "DotMatrix preview. Optimizing the speed of work."

Well, I hope the optimization also works on the actual printing to DotMatrix, since this is what i really need. I had just showed you the problem using the preview so that you could reproduce the issue, but I really need this when printing...

I will download it tomorrow and we'll see. I'll keep you updated.

Cheers,
Pascal

[HighAley]

Hello, Pascal.

Please, inform us about results of your testing.

Thank you.

[PJoyeux]

Wow! You really, really nailed it!

I don't know what you changed, but this worked well! Printing 9234 records now takes only 10 seconds whereas it formerly took up to 15 Minutes at least... Thanks!

But the time it takes to finish the print job seems not to be directly related to the amount of records but rather increases exponentially the more records you have.

Here a few durations I logged (on a laptop with Core-i7@2GHz with 8GB ram):

Records, Time in seconds until printjob is visible in printer-queue, calculated Time per record
9234, 10, ~1 msec/record
16655, 22, ~1,3 msec/record
34209, 75, ~2,2 msec/record
68517, 240, ~3,5 msec/record

Why could that be the case?

Still, this is a giant step in the right direction!

BTW: Could you shed some light on the original cause of this issue? Just curious...

Cheers,
Pascal

[HighAley]

Hello.

We used RichText component that works very slow in WPF.
Also we have made some improvements in printing Escape codes.

Thank you.