QTextEdit resizing slow additional information

I am using a QTextEdit in an MdiChild class. I am using background and foreground coloring. No other formatting (like bold or tables.)
When the MdiChild is maximized in the MainWindow, resizing of the app (by dragging a corner) is quite fast.
But when resizing only the child window (by dragging its corner) is MUCH SLOWER.

I have read several posts about similar problems and also bug reports dating back to 2010 about slow resizing of QTextEdit or QPlainTextEdit.
This was reported as a bug in earlier versions of Qt (Qt 3 and 4) these bug reports were closed without resolution when Qt 5 superseded them.

I am using Qt 5.5 and the slow bug is still here.

What is new in this report is that the slowness does not seem to be inherent in the QTextEdit (or QPlainTextEdit) because it is NOT SLOW when the whole App is resized.
It seems obvious that the QTextEdit should be doing the same thing whether the resize is because of dragging the corner of the App or the child window.

All this resizing is being done in the QT code (not my program.)

Please consider reopening the related bug reports as this should not require such major rewriting of the QTextEdit code since it is already quite capable of resizing fast when the App is resized.

Thank you

[EDIT] - More Information.
Upon further investigation, it looks like the reason that resizing by dragging the side (or corner) of the App causes contents to refresh faster may be that the underlying QTextEdit does not get all the resize iterations while dragging.
That is, while dragging the side of the App, out, the edge of the app is drawn 10 or 15 times before the inside contents is refreshed.
But when dragging the MdiChild window edge, the QTextEdit is probably being told to redraw all those 10 to 15 times, and is doing that behind the scenes before the last rendering is finally displayed.
I hope that make sense.
Perhaps the intermediate drag position iterations could be ignored while dragging until the one being re-rendered finishes and displays, then the current position starts the next rendering.
That way there are no "wasted" renderings that are never displayed.

A common way to work around this problem for any type of widget is to derive from the widget class and override the resizeEvent() method. In the new method, you start a timer with a short timeout (250 ms or so), and then exit without calling the base class resizeEvent. In the timer's timeout() slot, you set the new widget size. The logic is that as long as the user is resizing the widget, the timer will keep being restarted and no drawing will take place. As soon as the user stops (or pauses for longer than the timer period) the widget will redraw.

This will also work if the resize event gets called from something other than user interaction (for example, when the layout is setting sizes for its contents), but there will be a slight delay before the content gets painted. You can prevent this if you check to see if the widget is visible before starting the timer - the widget is not yet visible when the layout is doing its initial calculations before showing the widget.