Arduino DUE + RAMPS + FULL GRAPHIC LCD on Delta Stuttering

I have a little probelm with my beloved Anycubic kossel linera plus (Delta) printer.
It could print smoothly with it's original ATMEGA 2560 based trigorilla board with 2004 LCD.

But I upgraded it to Arduino Due + Modified Ramps with Full Graphic LCD.

Since then it is not perfect It is stuttering sometimes, mainly when I am navigating in the menu system.
I always printing from SD, that's why I wired the SD card to hardware SPI and wired the LCD with software SPI.
I know is a wellknown problem. But I would like to know which is the best config, for taavoding this issue.

I tried to change the SD SPi speed, I tried full speed, half speed and 1/8 speed. But Noting changed. So the probelm is not related to SD SPI configuration.

Delta segmentation is 200 / sec, but I wouldn't like to decrese this value, beacuse the print quality is better with this value. (In the old config with mega this was 150/sec).

I tried to use Smooth movemnet but it is not work (in old config, with old marvin it works), maybe this feature is not supported any more.
I tried to use the SLOWDOWN option, but nothing change. Maybe it is not compatible with delta segmentation.

I try to change the u8glib from x1 to x4 But I don't know which should be better and whart is the difference.
Finnaly, I increase the block buffer from 16 to 64 and the problem almost completly dissapared, but not completly.
So, how I should config the LCD to get the best result. I thought DUE has enough power to handle it.

I could not find any good descreption about LCD config. I am not intrested in smooth animation on LCD, I only want to print with fast speed without stuttering.

Thank you for any help.

200 segments per second is a lot. But you have some options. You can lower the max feed rates so the printer moves a little bit slower. Or you could go back to the 20x4 LCD display. That uses a lot less CPU cycles than the graphical display.

Or... you could bump up #define LCD_UPDATE_INTERVAL 100 in the ultralcd.h file. That will make the LCD panel more sluggish, but it will still work and burn up far less CPU cycles. I would suggest 250 if you are going to try that path.

Thank you I will try this.

My problem was I couldn't find this kind of description anywhere.
Do you know what the difference are among u8glib. 1x vs u8glib 4x vs u8glib rrd.
My LCD didn't work wirth u8glib rrd, but some person say it woluld be the fastest lcd driver.

The character based (non-graphic) LCD panels are the fastest. And they don't use u8glib.

Something like this will give you the best results: [www.ebay.com]

Yeah I have one of LCD.
But I would ike to get Full Grpahic LCD, beacuase is fancier.

I thought DUE will be fast enough for this.
I check the library code, the library is the problem. So it should be replaced.
But this library support a lot of platform, lcd, so almast everithing. So it is not an option to replace it.

On the work to move Marlin to 32-bits we are primarily using Re-ARM boards with Graphical LCD's. The Graphical LCD's need to be talked to very slowly.... The bits are pulsed in one at a time and each bit (and clock) needs to be fairly long for reliable transmission.