norepro on Windows at HEAD (6894b0c) or the reporter's SHA (bb56daf)

In case it's something to do with the GL config, mine is thus:

My settings:

Works for me on Windows as well at 04b332d HD Graphics 630 OpenGL 4.5 the rest as @developex-dmytro-i

addition:
try to minimize width of Property browser window (just behind Occlusion lines buttons), close Solvespace, run it again. The buttons are spread slightly widely, so that last button is shifted. When you try to resize browser's window, buttons rearranges normally and works good.

Before close:

After reopen:

After change height:

Weirdly, I can't reproduce that distortion either

Ok, it will be my pain ))

I am using Gnome 3.34.4 and when I first open Solvespace the property window is slightly more narrow than the buttons but you can click them fine.

I am using Gnome 3.34.4 and when I first open Solvespace the property window is slightly more narrow than the buttons but you can click them fine.

You can click all the button surface or the right side is unclickable? For example green button "Show triangle..."

When resize the window height - buttons jump slightly left?

The buttons are all working correctly even after resizing the window. I posted that because it looked similar to your "After Reopen" picture.

@developex-dmytro-i does your problem still happen on a recent build?
Please try the "Edge" from here https://github.com/solvespace/solvespace/releases

I think that I could reproduce this a few days back on Windows and then it disappeared?!?! Needs testing with all options cleared from the registry/json - just a guess...

I can consistently reproduce this on Windows by deleting the registry settings of SolveSpace (Computer\HKEY_USERS\S-xxxx\SOFTWARE\SolveSpace registry key).

After this (as mentioned above) the contents of the property browser window are scaled incorrectly - they are very slightly enlarged. This is the reason the icons and the "click" areas do not line up. As soon as the window is resized the scaling fixes itself.

In the screen shots below:

• The top one is the window after deleting the registry settings - the scaling is incorrect.
• The bottom one is after slightly resizing the window.

I added the vertical red lines to emphasize the problem.

The slight anti-aliasing of the top one is not an artifact of the screen shot - it is caused by the scaling and is visible on screen.

By the way the wrong scaling is only in the X (horizontal direction). Vertically the size is unchanged:

I did try to debug this a bit but did not immediately find the problem and ran out of time, I'll come back to it.

@ruevs You might try calling TextWindow::Resize() sometime after startup since resizing fixes the issue. If that works you can maybe track down something being not initialized correctly.

Edit: Now I'm thinking extWindow::DrawOrHitTestIcons() is drawing before the scrollbar is there, and hit testing afterward? That might change the result of window->GetContentSize()

Edit 2: I'm pretty sure it's not a problem in drawing the toolbar. It seems to be stretching the entire text window including the letters. Watch the "a" or even the whole word "active" when resizing fixes the issue.

I'm seeing this text stretching on Windows 11 Enterprise. When I start Solvespace the text is stretched and a bit blurry. If I resize it (vertically by dragging the bottom) the text snaps back to normal size. If I click on some of the text window menus (line styles / view / configuration) The text will be sized correctly or not depending if a scrollbar appears or disappears.

1. Start solvespace - text is blurry.
2. resize text window vertically to smallest height - text snaps back to normal
3. click "line styles" - text on that page is blurry
4. resize text window vertically so it does not need a scroll bar - text gets clear
5. click "home" - text is clear
6. click "line styles" - text is still clear
7. resize text window to minimum height - so we have a scroll bar
8. click home - text is blurry (because the previous page used a scroll bar and home does not)

At times during vertical resizing I can see a brief glitch when the scroll bar appears or disappears and the text is briefly the wrong horizontal size.

It's as if changing visibility of the scrollbar changes the width of the window but we don't change the size of our offscreen bitmap unless we get an actual window resize event. Changing scrollbar visibility by resizing the window works fine since we are getting resize events. Changing scrollbar visibility by changing text screens blurs the text because we don't get the resize event.

Do we explicitly change scrollbar visibility, or does that happen automatically as a side effect of changing its parameters? Maybe we should do a resize after changing scrollbar metrics then?

I have to leave this to someone compiling on windows, but I think I've narrowed it down quite a bit ;-)

@ruevs Does this help?

I'm certain it does, but I'm swamped with other stuff... will try to look during the weekend.