> On 12 Oct 2017, at 21:30, Jean-Marc Lasgouttes <lasgout...@lyx.org> wrote: > > Le 08/10/2017 à 18:57, pdv a écrit : >> The new code contains twice a viewport()->update() without specification of >> a rectangle. Since > Qt normally erases the widget's area before the >> paintEvent() call >> I guess that the whole viewport is erased. Subsequently only part of it is >> redrawn except for the case FullScreenUpdate and in that case there is no >> problem. > > Actually, we use > viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > to ask Qt not to overwrite it. It seems to work on Linux.
I compared the old and the new code and noticed that in the old code update(x, y, w, h) was always used with coordinates. This explanation seemed to make some sense since often a single line remains indeed visible (see tests below). And when I force a FullScreenUpdate in BufferView::draw then the problem goes away. But I see your point; When I remove the line setting WA_OpaquePaintEvent the problem remains but (most of) the view turns white instead of black; When I set WA_NoSystemBackground instead the problem remains the same. When I insert viewport()->update(0,0,500,500) then everything outside this square remains untouched but the problem persists within that square. It seems that update(area) restricts updating to the selected area, but apparently (at least on macos) one is then obliged to redraw that area completely. The Qt-docs read as follows: "Qt::WA_OpaquePaintEvent Indicates that the widget paints all its pixels when it receives a paint event. Thus, it is not required for operations like updating, resizing, scrolling and focus changes to erase the widget before generating paint events. …." I understand this as: since the widget will repaint all its pixels, there is no need (for Qt) to erase the widget. Another fragment, dealing with an example, reads: "The right widget has the Qt::WA_OpaquePaintEvent widget attribute set. This indicates that the widget will paint over its entire area with opaque colors. The widget's area will initially be uninitialized, represented in the diagram with a red diagonal grid pattern that shines through the overpainted area. The Qt::WA_OpaquePaintArea attribute is useful for widgets that need to paint their own specialized contents quickly and do not need a default filled background." Apparently “uninitialized” means “black". I have no idea why this turns out correctly under linux. > > Please feel free to look at the code and docs (QWidget and > QAbstractScrollArea) and tell us what I may have missed. I just saw that we > should override viewportEvent() instead of event(), but I am not sure that it > would make a difference. > > Can you compile master? Do you see the issue? Yes and yes; Here are some observations (I used the Help/Introduction for testing): - Clicking anywhere in the window (or when scrolling) restores the view. - Inserting a CR anywhere restores the view. - Selecting anything by double clicking turns the screen black, except for some insets (like LYX, a footnote, Table of Contents) which remain visible. - Hovering with the mouse over a footnote or Table of Contents restores the view. - When moving the cursor up/down with the up/down keys usually only one line is visible (in addition to the elements mentioned higher) but it’s the line above/below the one containing the cursor. - This is also true when starting from a normal view. Moving the cursor up/down leaves the line visible where the cursor was positioned. However when a word is marked by the spellchecker then one must move the cursor an additional line before the view goes black (one can thus move the cursor within 3 lines without going black). - When moving the cursor horizontally with the arrow keys; the screen goes black except for the current line (and the insets). - Moving the cursor horizontally in a word marked by the spellchecker causes no problem. The view goes black only when entering an adjacent word. - Sometimes the view is completely blacked, also the special insets. E.g. when bringing the window to the foreground. Replacing GuiWorkArea::event() by viewportEvent() does not make a difference. If you have a suggestion for a specific test, let me know. > > JMarc
smime.p7s
Description: S/MIME cryptographic signature
