Speed of printing is slow for multiple ticket.row, ticket.text

[andrey-ushakov]

Speed of printing is slow for multiple ticket.row, ticket.text

[ileb325]

Hi @andrey-ushakov ,

Sorry for the late reply, I didn't have a chance to look earlier. My apologies.

Good news! After your fix, it runs very fast!

Before: https://drive.google.com/open?id=1uMTOArMP3Acw98-L9GYg55x1qSd7GZWV
After: https://drive.google.com/open?id=1c6XoiLi9D_Vpd1eTSgXfN_oUgpeaD_Bp

To answer your previous questions:
Does the printing become at least a bit faster with the new version?
(Assuming I didn't have your latest update :)) No, I think reset command does something to my printer where it halts for maybe ~50-75ms per instruction?

When you say that the printing takes about 8 seconds - do you mean that you have to wait 8 seconds before your printer actually starts to print? Or it starts to print instantly but it takes 8 seconds to print 100 lines?
It starts immediately but every line, it halts for maybe 50-75ms (Please watch before video link above)

Finally, do you have another printer the test in the same network?
Yes, hardwired :)

Thank you again!

[andrey-ushakov]

Hi @ileb325,

You mean you are creating multiple tickets and send them to your printer?
Could you please share your code?
What's your printer model? Wifi or Bluetooth?

Thank you!

[ileb325]

Hi @andrey-ushakov ,

Thank you for replying back.

My printer model is Epson TM-M30 LAN (using network, not Bluetooth). I used a single Ticket object and send it to the printer. Please see the code below:

sampleSpeedInSingleText() concatenates all numbers (1 - 100 with \n) into a single ticket.text() vs. sampleSpeedInMultipleText() appends to the ticket by calling .text 100 times (ticket.text(1)...ticket.text(100)).

Result:
sampleSpeedInSingleText() prints in < 2 seconds
sampleSpeedInMultipleText() prints in 8 seconds

When the number grows from 100 lines to 1000 lines, the time difference is even bigger.

// Fast
void sampleSpeedInSingleText() async {
  final Ticket ticket = Ticket(PaperSize.mm80);
  final String printString = List<int>.generate(100, (i) => i + 1).join("\n");
  ticket.text(printString);
  ticket.feed(5);
  ticket.cut();

  final PrinterNetworkManager printerManager = PrinterNetworkManager();
  printerManager.selectPrinter(this.ipaddress, port: this.port ?? 9100);
  final PosPrintResult res = await printerManager.printTicket(ticket);
  print('Print result: ${res.msg}');
}

// Slow
void sampleSpeedInMultipleText() async {
  final Ticket ticket = Ticket(PaperSize.mm80);
  List<int>.generate(100, (i) => i + 1)
      .forEach((number) => ticket.text(number.toString()));
  ticket.feed(5);
  ticket.cut();

  final PrinterNetworkManager printerManager = PrinterNetworkManager();
  printerManager.selectPrinter(this.ipaddress, port: this.port ?? 9100);
  final PosPrintResult res = await printerManager.printTicket(ticket);
  print('Print result: ${res.msg}');
}

Thank you!

[andrey-ushakov]

Hi @ileb325,

Thank you for the excellent test! The Ticket.text method in the latest version of the package has been improved. It doesn't generate unnecessary styling byte code anymore. This means that the final Ticket's bytecode is much shorter than before. I guess that was the problem that caused this issue.

I've just tested both functions - fast and slow - using my WiFi printer and both work fast (it takes around 2 seconds I think). I've used pure Dart and WiFi connection to run the code but using Flutter the result should be the same.

May I ask you to re-test it using your printer, please?

[ileb325]

Hi @andrey-ushakov ,

First of all, thank you again for providing such a great library.

Unfortunately, the bad news is that the new version didn't fix the problem with Epson TM-M30 LAN, but there is something odd when comparing the two ticket.bytes array side by side.

With the sample slow and fast functions, I was able to compare the diff between the 2 ticket.bytes array side by side and noticed the following:

(for sake of this example, I didn't print 1 to 100 but instead 1 to 10 to make the comparison shorter)

For sampleSpeedInSingleText:
27 64 27 97 48 27 36 0 0 28 46 49 10 50 10 51 10 52 10 53 10 54 10 55 10 56 10 57 10 49 48 10 27 64 27 100 5 10 10 10 10 10 29 86 48

For sampleSpeedInMultipleText:
27 64 27 97 48 27 36 0 0 28 46 49 10 27 64 27 97 48 27 36 0 0 28 46 50 10 27 64 27 97 48 27 36 0 0 28 46 51 10 27 64 27 97 48 27 36 0 0 28 46 52 10 27 64 27 97 48 27 36 0 0 28 46 53 10 27 64 27 97 48 27 36 0 0 28 46 54 10 27 64 27 97 48 27 36 0 0 28 46 55 10 27 64 27 97 48 27 36 0 0 28 46 56 10 27 64 27 97 48 27 36 0 0 28 46 57 10 27 64 27 97 48 27 36 0 0 28 46 49 48 10 27 64 27 100 5 10 10 10 10 10 29 86 48

1. sampleSpeedInMultipleText generates much larger bytes which seem very odd to compare because both should generate an identical byte stream.
2. I noticed that (marked in bold) seemed repetitive on every ticket.text. I am assuming this is the part of the styling byte code that cannot be removed further?

I will look deeper once I have more time and definitely update to this thread. In the meantime, which printer model do you use?

Thank you!

[andrey-ushakov]

Humm... That's really weird...

1. Does the printing become at least a bit faster with the new version?
2. When you say that the printing takes about 8 seconds - do you mean that you have to wait 8 seconds before your printer actually starts to print? Or it starts to print instantly but it takes 8 seconds to print 100 lines?
3. Finally, do you have another printer the test in the same network?

I'm using Xprinter XP-N160I to run the test. I gonna try to test on some Bluetooth printers as well.

You are correct about the styling byte code. Every time you call the print method, it will add some commands to styling and text encoding.
I will check if it's possible to optimize this part.

If you want to understand the byte code, here is the byte code generated by sampleSpeedInSingleText (from 1 to 10, from your last message):

Bytes	Command	Description	Comment
27 64	ESC @	reset
27 97 48	ESC a 0	align left	START text()
27 36 0 0	ESC $ 0 0	set absolute position
28 46	FS .	kanji mode off	(for printers supporting kanji)
49 10 50 10 51 10 52 10 53 10 54 10 55 10 56 10 57 10 49 48 10		"1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n"
27 64	ESC @	reset	END text()
27 100 5	ESC d	feed (5)
10 10 10 10 10		empty lines (5)	START cut()
29 86 48	GS V 0	full cut	END cut()

[andrey-ushakov]

This could explain the performance issue. It looks like it's Epson-related. I will try to fix that in the next version.

[andrey-ushakov]

The latest version of the library should fix the performance issue.

Could you please test it once again using your Epson TM-M30?

Thanks!

[andrey-ushakov]

Awesome! Thank you for your detailed reply!

If you have time, feel free to add your printer here.