Results 1 to 2 of 2

Thread: QTextEdit resizing slow additional information

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1

    Lightbulb 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.
    Last edited by harveyab; 21st June 2017 at 10:28.

Similar Threads

  1. Replies: 11
    Last Post: 20th June 2013, 12:56
  2. Slow performances with QPlainTextEdit
    By nekkro-kvlt in forum Qt Programming
    Replies: 5
    Last Post: 18th February 2012, 14:59
  3. Replies: 1
    Last Post: 18th July 2011, 16:24
  4. Automatic image resizing too slow
    By mhbeyle in forum Qt Programming
    Replies: 1
    Last Post: 14th December 2009, 08:55
  5. Additional QtMsgHandler information
    By bruccutler in forum Newbie
    Replies: 2
    Last Post: 23rd April 2007, 17:38

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.