@whitequark, please, provide more information

@Evil-Spirit I have this instead of smooth dragging:

@whitequark, hm. I have no such problem on Windows.
Do you have this after Rect creation and dragging it again?

Only during initial creation of rect and line. All other entities are fine.

I have artifacts on initial dragging, but this is very old, it appears after we introduced "havePainted"

@whitequark
I have fixed same-looking issue on windows. Can you try it for linux?

@Evil-Spirit No, same thing.

I think maybe you aren't marking a group as dirty sometimes.

@whitequark, Is InvalidateGraphics() actrually redraws all the window on linux?

Here's the code:

void InvalidateGraphics(void) {
    GW->get_widget().queue_draw();
}

void PaintGraphics(void) {
    GW->get_widget().queue_draw();
    /* Process animation */
    Glib::MainContext::get_default()->iteration(false);
}

InvalidateGraphics schedules a redraw, PaintGraphics schedules a redraw and immediately runs the message handling loop (just like WndProc) until all messages are processed.

Can you reproduce this in a VM?

@whitequark, can you turn back
mouse.cpp:1391

        SS.MarkGroupDirty(c->group);
        SS.GenerateAll();

Probably PaintGraphics runs before GenerateAll

@Evil-Spirit That doesn't help. But I also found this only happens on GTK 2. So maybe this just means it's time to drop GTK 2 from SolveSpace 3, and fix any remaining bugs.

Solved by killing GTK2 and removing various horrible hacks also.

I have artifacts on initial dragging, but this is very old, it appears after we introduced "havePainted"

Let's fix that too, what sort of artifact is that?

When dragging new rect one of the line not matched in vertex. This is because redrawing before solving. This happens inside hit test function.

@Evil-Spirit There must be some other error, because with both of your fixes above, dragging of new rect still has the same issue on Linux.

@Evil-Spirit I've merged your Windows fix.

@whitequark, more fixes

@whitequark, problem with mouse-move hovering happens again(viewport is not redrawing while moving over, just when mouse move stopped)

This fix you added makes no sense.

@whitequark,
We have eliminated only PaintGraphics() call inside HitTestMakeSelection, so there is no place where PaintGraphics worked while mouse move events present in queue and takes a lot of time.

@whitequark,
This is only windows problem

Then I will revert that commit, because your fix makes no sense, and after it PaintGraphics/InvalidateGraphics don't do what they claim to.

@whitequark, Can you explain what does mean "don't do what they claim to"?
InvalidateGraphics before this just posts WM_PAINT message, PaintGraphics redraws immediately.
The things have worked before this way also works this way now (if WM_PAINT doesn't drew viewport it will be drawn using SS.later.paintGraphics, but never before GenerateAll as it can be done now)

And on GTK/Cocoa PaintGraphics redraws immediately. Any fix that makes the platforms diverge isn't the right fix, of course because then you and I will see different bugs.

@whitequark, OK, changed this

@Evil-Spirit That's much better! Let me see if this applies to Linux as well...

@Evil-Spirit Actually, I think your fix will create another problem. Try it on any case where hit testing is really slow.

@whitequark,
I have tested it for big-big-big-woodworking-asm.slvs (where HitTestMakeSelection is really slow) and there is no problem for me (with using Evil-Spirit@6cdb9a3)

I've figured out the problem. It has nothing to do with invalidation. Rather, it is because of ScheduleGenerateAll that never actually performs the generation if the queue is full of mouse move events (at least on Linux).

@whitequark, Good. So how to fix this?

@Evil-Spirit Not sure. Maybe we need to rewrite the message handling loop on Linux to make it look like it does on Windows.

Fixed in master.

@Evil-Spirit I have this instead of smooth dragging:

I'm getting this exact issue on Windows when building the current master branch (e84fd46). I've tried building in Linux (WSL) with MinGW, and building on Windows with Visual Studio and MinGW.
I remember building back when Helix was added, and was getting the same issue.

Would love to know if anyone else is encountering this issue, and potential fixes. I've looked into the original fixes from above, but the file architecture has changed a lot since then.

Although I don't know the impacts of doing so, I've been able to get it working properly by removing the Invalidate() from mouse.cpp.

case Pending::DRAGGING_NEW_POINT:
    UpdateDraggedPoint(pending.point, x, y);
    HitTestMakeSelection(mp);
    SS.MarkGroupDirtyByEntity(pending.point);
    orig.mouse = mp;
    //Invalidate();
    break;

Thanks for the investigation. The fix doesn't look right to me in general, but the fact that it helps for your specific case is still useful to know. Please open a new issue to track this problem; I was under the impression that it's fixed, but looks like it either never was and wasn't detected by my tests, or it got broken somewhere since 2017.