Bizarrely, I can't reproduce this behavior at all. But I found an unrelated bug that I fixed in bda3b80. Can you recheck?

weird. Still can reproduce. Wonder if it's related to the mysterious difference between our seemingly-identical GTK that is causing the tooltip thing. I've attached a minimal file I tested with - load, then try switching active groups between g002 and g003 and hitting w. Should re-orient the view. (All this has is one rectangle in workplane g002, and a second workplane g003 perpindicular to it. This loads orientated to g002 but with g003 active, so switching active to g002 and hitting w shouldn't do anything, but leaving it g003 and hitting w should rotate it away.)

Works in 2.3 as packaged in debian buster. Fails in master commit 25b6eba.

2.3:

master: a bit harder to show things not happening, but rest assured I'm pounding w while the property browser is in focus, it's just not doing anything.

minimal.zip

I don't see any real warnings per-se in the console while running, only when I go to exist - then I get a whole pile of:

(solvespace:6318): glibmm-WARNING **: 14:05:36.711: Failed to wrap object of type 'GtkWindow'. Hint: this error is commonly caused by failing to call a library init() function.

(solvespace:6318): glibmm-CRITICAL **: 14:05:36.711: Glib::ObjectBase* Glib::wrap_create_new_wrapper(GObject*): assertion 'wrap_func_table != nullptr' failed

No idea if that's related.

Yeah, you'll have to use a debugger yourself. I have absolutely no idea what could cause this.

I don't see any real warnings per-se in the console while running, only when I go to exist - then I get a whole pile of:

Not related to this problem. It's some kind of gtkmm initialization issue I was never able to narrow down. It doesn't seem to affect anything.

It's some kind of gtkmm initialization issue I was never able to narrow down. It doesn't seem to affect anything.

(I think it's fixed now.)

OK, so a little bit more info, which maybe is well known to you: I never get into the keyboard event handler in either window. However, not sure this matters, since the shortcuts are registered as menu accelerators. Searching the internet is not very helpful, hopefully I'll run across a simpler GTK-using app with similar behavior soon that I can look into. (Inkscape's toolbox dialogs correctly propagate the kb accelerators, but that's a massive and complex app to dig into.)

Aha, I remember now! This code should be responsible for that:

yeah, that's where I'm digging around right now :) pointer looks OK, etc.

Turns out xprop reports the inkscape toolboxes are "NORMAL" not "UTILITY", interestingly. I assume they must be doing some on-top stuff manually maybe? They're also connecting some low-level signals, which I'm not sure if it matters. https://gitlab.com/inkscape/inkscape/blob/master/src/ui/widget/dock-item.cpp#L411 They also don't have _NET_WM_STATE_SKIP_PAGER set unlike the solvespace one.

Oh actually I'm getting into GtkGLWidget::on_key_press_event in the text window, but not the graphics window, for a key that's a shortcut (are they all shortcuts by now?)

OK, weird. This was fine on my laptop until I pulled and rebuilt recently. I'll see if I can bisect it. (I tend not to do much CAD on my laptop for probably obvious reasons - between the intel graphics and the trackpad it's not terribly good at it.)

I actually primarily do CAD on my laptop--the performance seems to be bottlenecked by logic inside SolveSpace rather than Intel graphics, but it's Kaby Lake, I'm not sure which generation you have.

Yeah, mine too. (we have nearly the same laptop IIRC, mine's a XPS13 9370) Having some issues with it so it only boots into Windows right now, and it's super slow - as in, there's noticable lag in drawing a rectangle. (I think it's slower on Windows than Linux, since this wasn't the first time I designed something on my laptop.) I guess I just assumed it was intel graphics but that's not very scientific an assumption since my other comparison point (and normal modeling machine) is a Ryzen 2700x with Radeon RX580.

I think it's slower on Windows than Linux

Unless you installed vendor drivers (i.e. not through Windows Update), it's going through ANGLE and DirectX. If you have OpenGL 3 or later natively it'll switch to using that and it should be faster.

I guess I just assumed it was intel graphics

That seems very unlikely, on Linux it takes the Intel GPU in KBL about 1 millisecond to render a frame with some simple 2d geometry.

there's noticable lag in drawing a rectangle

There is actually an issue with rectangles specifically that I never conclusively nailed down, but I think it's related to Constraint::ModifyToSatisfy. The way it shows is that if your machine is already slow (it's old, or maybe uses a software rasterizer) then drawing a new rectangle becomes super laggy. Lines should be less bad. Dragging an existing rectangle should be much faster.

This issue shows up very visibly on virtualized macOS and with WebGL, but I've seen it elsewhere too.

@rpavlik Do you still hit this issue?

Yes, though I haven't had any time to figure out when it came in.

@rpavlik @phkahler @ppd you should probably try to figure this one out before 3.0

It works fine on Windows and I imagine it is rather annoying on Linux/GTK

yeah, I should see if it still happens on Bullseye. It's intermittent, in that you need a specific configuration (that I haven't understood) to make it happen.

Can't repro anymore.