GNOME Bugzilla – Bug 677351
Ugly window grow when dragging size box.
Last modified: 2019-03-20 11:54:39 UTC
The scrollbars get redrawn several times without redrawing newly exposed content areas, leaving a trail of multiple images of the scrollbars (see attached screenshot) in the content area until the mouse button is released and the content area is finally updated. With today's computer hardware speeds, there's no real excuse for ugly graphics processing and incomplete screen updates. Dia is a good application, and just needs a little bit more care for the user interface (better screen updating, cleaner looking anti-aliased object icons in the lower list) to make it top class. The grainy looking object borders harken back to the 1980's with the early MacDraw. Let's move on to the 21st century, folks.
Created attachment 215502 [details] Screen shot of poor screen updating while resizing window in Dia.
Polemic aside [1] I've done some experimentation on the major platforms Dia is running on. Part of the issue is caused by an active design decision of GTK+, namely to give higher priority on resize than redraw [2]. But a similar effect can be seen on all major platforms (OS X, Linux, Windows), even without involvement of Dia or GTK+. (Sorry couldn't test with MacDraw, is it available for OS X?) Dia's canvas rendering is currently done with G_PRIORITY_DEFAULT, see app/display.c(ddisplay_flush), which is lower than resize and redraw priority of GTK. But tuning this parameter can not overcome GTK+ or hardware constraints. Though the issue at hand slightly improves by using GDK_PRIORITY_REDRAW also for canvas redrawing. For reference I'm attaching two patches used during experimentation on win32. Both are not ready for prime time, i.e. their optimizations only change the appearance slightly but can not make the complained about effect go away and even introduce other flicker. [1] At least all the systems from the last millennium I have (or had) access to did not redraw during window resize. Even nowadays the feature can be switched off on the system level (e.g. win8rp: Advanced System Settings/Performance/Show window contents while dragging) [2] http://developer.gnome.org/gtk/2.24/gtk-General.html#GTK-PRIORITY-REDRAW:CAPS
Created attachment 217063 [details] [review] Explicit background clearing during WM_PAINT handling (against gtk-2-24)
Created attachment 217065 [details] [review] Experimental changes to Dia(master) for redraw while dragging
(In reply to comment #0) > The scrollbars get redrawn several times Nope. The background is not drawn at all without idle during resize. > Let's move on to the 21st century, folks. Patches accepted.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dia/issues/309.