Main place for discussions about U++ cross platform development framework.
I have recently came upon a problem where Windows11 with multiple monitors is using very big virtual screen area, unfortunately to conserve the space, we support logical coordinates only between -16000 ... 16000. (BTW the problem manifested as misplaced menus, so if you ever seen something like that, this should fix). One option to fix that would be to use more bits for coordinates, but after spending month to optimise sizeof(Ctrl) down to 104 bytes, I would hate to spoil that to 120... So for now, I decided to only support "mega" positions of windows, meaning in SetRect(x, y, cx, cy), x and y can now be integers (and there is somewhat convoluted code to store them into packed attributes if necessary, which means this will not affect normal widgets). Size of window is still clamped to 16000, but that should not be an issue. If you have a chance to test this, please do! This is the commit: https://github.com/ultimatepp/ultimatepp/commit/d29055412b9b a2f5d3a78d4ba3ae3ee7260b2df2 Also, this means there will be rc2 Mirek
Re: SetRect "MegaRect" support...
Great! I will update theide and do a test. Thanks Mirek!
Freezed in 10 minutes. I can still bring the "Help/About..." dialog to display the version number. But notice the right & bottom part of theide window is not drawn after resizing.
Lance wrote on Mon, 07 October 2024 02:36 Freezed in 10 minutes. I can still bring the "Help/About..." dialog to display the version number. But notice the right & bottom part of theide window is not drawn after resizing. Was this connected to adding / removing external display again? Can you put in some logs? At the start of CodeEditor::Paint: DLOG("================================="); DDUMP(GetScreenView()); DDUMP(GetScreenRect()); DDUMP(GetVirtualScreenArea()); DDUMP(GetVirtualWorkArea()); DDUMP(GetPrimaryWorkArea()); DDUMP(GetWorkArea()); Array<Rect> work_area; GetWorkArea(work_area); DDUMP(work_area); DLOG("--------");
mirek wrote on Mon, 07 October 2024 06:53 Was this connected to adding / removing external display again? Can you put in some logs? At the start of CodeEditor::Paint: DLOG("================================="); DDUMP(GetScreenView()); DDUMP(GetScreenRect()); DDUMP(GetVirtualScreenArea()); DDUMP(GetVirtualWorkArea()); DDUMP(GetPrimaryWorkArea()); DDUMP(GetWorkArea()); Array<Rect> work_area; GetWorkArea(work_area); DDUMP(work_area); DLOG("--------"); It's not connected to Add/Removing secondary monitor. Some bugs in Ubuntu (or maybe the kernel) results in Gnome to log out current user and restart a new session. I usually put the machine to suspension before removing secondary monitor. I will post log file when one is available. Thanks!
Quote: * /home/lance/upp/.cache/upp.out/uppsrc/CLANG.Debug.Debug_Full .Gui.Shared/ide 08.10.2024 11:01:52, user: lance 11:01:52:339 INFO LoadLibClang0(): libclang path: "/usr/lib/llvm-18/lib/libclang.so.1" 11:01:52:340 INFO GuiMainFn_(): Version: 17426 (64 bit) (CLANG) (C++20) (SIMD) (Gtk) Compiled: 10/08/2024 11:01:07 /home/lance/upp/.cache/upp.out/uppsrc/CLANG.Debug.Debug_Full .Gui.Shared/ide ReParse 3.547205 s ReParse 3.987207 s No useful information. Maybe wrong log point? What I did: run theide (A), open uppsr/ide, F5 to run the compiled theide (B) in debug mode. After certain action, B freeze. A is normal. I am able to access the logfile content through A's 'Debug/View log file' menu. Then after a few window switching (to write this post), I found A also get frozen. When frozen, menu continus to be responsive. it's just the area below menu won't redraw itself.
Lance wrote on Tue, 08 October 2024 17:10 Quote: * /home/lance/upp/.cache/upp.out/uppsrc/CLANG.Debug.Debug_Full .Gui.Shared/ide 08.10.2024 11:01:52, user: lance 11:01:52:339 INFO LoadLibClang0(): libclang path: "/usr/lib/llvm-18/lib/libclang.so.1" 11:01:52:340 INFO GuiMainFn_(): Version: 17426 (64 bit) (CLANG) (C++20) (SIMD) (Gtk) Compiled: 10/08/2024 11:01:07 /home/lance/upp/.cache/upp.out/uppsrc/CLANG.Debug.Debug_Full .Gui.Shared/ide ReParse 3.547205 s ReParse 3.987207 s No useful information. Maybe wrong log point? What I did: run theide (A), open uppsr/ide, F5 to run the compiled theide (B) in debug mode. After certain action, B freeze. A is normal. I am able to access the logfile content through A's 'Debug/View log file' menu. Then after a few window switching (to write this post), I found A also get frozen. When frozen, menu continus to be responsive. it's just the area below menu won't redraw itself. Hard to say, but I am confident you should be able get something useful logged... (If nothing helps, try something simple like DLOG("Hi!") at the start of GUI_APP_MAIN
if I F5 to run theide from within original ide, and open another project to compile, etc., theide crashes because of segmentation fault, with the following call stack.
extracted from Ctrl class declaration Ctrl *prev_sibling = nullptr; Ctrl *next_sibling = nullptr; Ctrl *children = nullptr; PackedData attrs; byte overpaint; bool unicode:1; bool fullrefresh:1; bool transparent:1; bool visible:1; bool enabled:1; bool wantfocus:1; bool initfocus:1; bool activepopup:1; bool editable:1; bool modify:1; bool ignoremouse:1; bool inframe:1; bool inloop:1; bool isopen:1; bool popup:1; bool popupgrab:1; byte backpaint:2;//2 bool akv:1; bool destroying:1; bool layout_id_literal:1; // info_ptr points to layout char * literal, no heap involved bool multi_frame:1; // there is more than single frame, they are stored in heap bool top:1; bool megarect:1; // support for large virtual screen area - SetRect > 16000 static Ptr<Ctrl> eventCtrl; Just noticed the megarect bit added.
Hi Mirek, After review subsequent logging, I believe after freeze, the CodeEditor::Paint is never called. All log entries were for when theide was maximized. After freeze, I actually unmaximized the window did a few move around and resizing. These were not logged. So Not calling CodeEditor::Paint after theide has been trapped into certain state was the reason for the demonstrated behavior.
Lance wrote on Sun, 13 October 2024 01:51 Hi Mirek, After review subsequent logging, I believe after freeze, the CodeEditor::Paint is never called. All log entries were for when theide was maximized. After freeze, I actually unmaximized the window did a few move around and resizing. These were not logged. So Not calling CodeEditor::Paint after theide has been trapped into certain state was the reason for the demonstrated behavior. OK, based on this information, I tried to prepare a branch with some more logs that will hopefully get us more info... It is in the branch "logs" https://github.com/ultimatepp/ultimatepp/tree/logs Please get it to the freezed state if possible, then press some keys that should invoke repaints (e.g. PageUp / PageDown) so that I can see the reaction to these keys. BTW, what happens if freezed and you press Ctrl+O? Can you close the window? (without forcing it) (If not then it is actual freeze, not painting problem) Does it freeze with assist off? (not using libclang..) Mirek
mirek wrote on Mon, 14 October 2024 05:35 OK, based on this information, I tried to prepare a branch with some more logs that will hopefully get us more info... It is in the branch "logs" https://github.com/ultimatepp/ultimatepp/tree/logs Please get it to the freezed state if possible, then press some keys that should invoke repaints (e.g. PageUp / PageDown) so that I can see the reaction to these keys. Will test. Quote: BTW, what happens if freezed and you press Ctrl+O? Can you close the window? (without forcing it) (If not then it is actual freeze, not painting problem) Does it freeze with assist off? (not using libclang..) Mirek It's a paint issue. The menu can be used and responsive. If a dialog need to be invoked, it behaves normally. Closing, minimixing, resizing etc all works fine except client area is not painted. I am afraid it's unlikely a problem of libclang. My application is demonstrating the same behavior.
Lance wrote on Mon, 14 October 2024 13:28 mirek wrote on Mon, 14 October 2024 05:35 OK, based on this information, I tried to prepare a branch with some more logs that will hopefully get us more info... It is in the branch "logs" https://github.com/ultimatepp/ultimatepp/tree/logs Please get it to the freezed state if possible, then press some keys that should invoke repaints (e.g. PageUp / PageDown) so that I can see the reaction to these keys. Will test. Quote: BTW, what happens if freezed and you press Ctrl+O? Can you close the window? (without forcing it) (If not then it is actual freeze, not painting problem) Does it freeze with assist off? (not using libclang..) Mirek It's a paint issue. The menu can be used and responsive. If a dialog need to be invoked, it behaves normally. Closing, minimixing, resizing etc all works fine except client area is not painted. I am afraid it's unlikely a problem of libclang. My application is demonstrating the same behavior. Thanks. Perfect, that narrows it down.
Lance wrote on Mon, 14 October 2024 17:37 ok. please see attached. Thanks it, hopefully getting close... More logs added, so please repeat after pulling "logs" branch... Also, I have potential fix included, but I really would like to get freezed log first to confirm my theory... After that, you can try to activate the fix, uncomment / #if 1 CtrlCore/CtrlPos.cpp:157 CtrlCore/CtrlDraw.cpp:52 Mirek
mirek wrote on Tue, 15 October 2024 03:02 Lance wrote on Mon, 14 October 2024 17:37 ok. please see attached. Thanks it, hopefully getting close... More logs added, so please repeat after pulling "logs" branch... Also, I have potential fix included, but I really would like to get freezed log first to confirm my theory... After that, you can try to activate the fix, uncomment / #if 1 CtrlCore/CtrlPos.cpp:157 CtrlCore/CtrlDraw.cpp:52 Mirek I have actived the tentative fix. I am about to start testing the fix.
Lance wrote on Tue, 15 October 2024 23:56 mirek wrote on Tue, 15 October 2024 03:02 Lance wrote on Mon, 14 October 2024 17:37 ok. please see attached. Thanks it, hopefully getting close... More logs added, so please repeat after pulling "logs" branch... Also, I have potential fix included, but I really would like to get freezed log first to confirm my theory... After that, you can try to activate the fix, uncomment / #if 1 CtrlCore/CtrlPos.cpp:157 CtrlCore/CtrlDraw.cpp:52 Mirek I have actived the tentative fix. I am about to start testing the fix. Oops, no, I would really like to see the new log before the fix! (Just to confirm I am fixing the right problem this time).
mirek wrote on Wed, 16 October 2024 03:48 Lance wrote on Tue, 15 October 2024 23:56 mirek wrote on Tue, 15 October 2024 03:02 Lance wrote on Mon, 14 October 2024 17:37 ok. please see attached. Thanks it, hopefully getting close... More logs added, so please repeat after pulling "logs" branch... Also, I have potential fix included, but I really would like to get freezed log first to confirm my theory... After that, you can try to activate the fix, uncomment / #if 1 CtrlCore/CtrlPos.cpp:157 CtrlCore/CtrlDraw.cpp:52 Mirek I have actived the tentative fix. I am about to start testing the fix. Oops, no, I would really like to see the new log before the fix! (Just to confirm I am fixing the right problem this time). That's exactly what I did. See the post prior to that for the attached zipped log file. Thanks.
Lance wrote on Tue, 15 October 2024 15:21 Caught one. Please see attached. Cool. It is consistent with the attempt at fixing it...
mirek wrote on Wed, 16 October 2024 09:26 Lance wrote on Tue, 15 October 2024 15:21 Caught one. Please see attached. Cool. It is consistent with the attempt at fixing it... Great! Please apply it in the main branch. I will test in both theide and my application continuously for 2 weeks to verify it.
No rush. I likely had another freeze but I am not 100% sure. Would it be possible for you to log a indicator version number etc in the log file? Just in case, please see attached for the log file.
Lance wrote on Thu, 17 October 2024 01:15 No rush. I likely had another freeze but I am not 100% sure. Would it be possible for you to log a indicator version number etc in the log file? Pushed to logs, I have also "fortified" the fix a bit... It is now active in the branch. Mirek
Caught another one. Please see attached.
Lance wrote on Thu, 17 October 2024 21:02 Caught another one. Please see attached. Uh oh... More logs added to "logs". Please keep testing.
Any context BTW? I mean any action performed before it got stuck? Maximise/minimise/moving window or something like that?
mirek wrote on Sat, 19 October 2024 03:48 Any context BTW? I mean any action performed before it got stuck? Maximise/minimise/moving window or something like that? That's the toughest part. No easy pattern can be spotted that leads to a freeze. Sometimes it goes like many hours and mutiple suspension & resume without a problem. Sometimes it happens quite often like a few times in half an hour's frame. Moving around, minimizing & maximizing definitely have no problems at all. If I must point something out, it possibly has a positive correlation with moving windows between minitors, switching to other window and leave theide in the background. But really, I am not sure.
mirek wrote on Sat, 19 October 2024 03:41 Lance wrote on Thu, 17 October 2024 21:02 Caught another one. Please see attached. Uh oh... More logs added to "logs". Please keep testing. Takes many hours, and eventually I have this.
My local copy of uppsrc got screwed up. I have recreated it, but that may mean the previous freeze reports might be faulty (and log file invalid). I have recompiled logs/ide, and started testing. Sorry for possibly unnecessary frustrations it might have caused.
I can pretty much be sure the bug is still around. theide hasn't failed yet, but my application compiled with the logs branch u++ libary failed just now.
Lance wrote on Mon, 21 October 2024 13:06 I can pretty much be sure the bug is still around. theide hasn't failed yet, but my application compiled with the logs branch u++ libary failed just now. And what about logs? Mirek
mirek wrote on Mon, 21 October 2024 07:17 And what about logs? Mirek Oh, I though the one generated while running theide is more desirable. Please see attached.
Lance wrote on Mon, 21 October 2024 18:00 mirek wrote on Mon, 21 October 2024 07:17 And what about logs? Mirek Oh, I though the one generated while running theide is more desirable. Please see attached. From the log it seems like it was "frozen" since the start. Is that correct?
No. It was fine. But after it froze, I left it unkilled for a while, afraid of another run will erase the log file. OK, here I got a log file from ide. It has been in good condition after many suspension-resume sessions. Just now I decided to give it some focus. I moved it from one monitor to another, dragged another window from another monitor to the one ide resided, and on top of ide, keeping mouse down and adjusting its position until I saw a color changing in ide underneath the window I was playing with, signalling possibly negotiating drag-n-drop(?). It successfuly brought down ide. It doesn't always. But it seems this set of actions is dangerous to ide. It breaks under other totally unrelated, unrecorded sequence of actions too. BTW, please feel free to delete used log files from uppweb to free up resouces. Or maybe I shall do that?
Lance wrote on Mon, 21 October 2024 23:59 No. It was fine. But after it froze, I left it unkilled for a while, afraid of another run will erase the log file. OK, here I got a log file from ide. It has been in good condition after many suspension-resume sessions. Just now I decided to give it some focus. I moved it from one monitor to another, dragged another window from another monitor to the one ide resided, and on top of ide, keeping mouse down and adjusting its position until I saw a color changing in ide underneath the window I was playing with, signalling possibly negotiating drag-n-drop(?). It successfuly brought down ide. It doesn't always. But it seems this set of actions is dangerous to ide. It breaks under other totally unrelated, unrecorded sequence of actions too. BTW, please feel free to delete used log files from uppweb to free up resouces. Or maybe I shall do that? By "brought down" do you mean crash or (the usual) repainting stopped? If the second one, it starts to look like yet another xwayland bug (assuming you run wayland - I think you do). Log clearly shows that I call gdk_window_invalidate_rect with proper parameters (it is the INVALIDATE word in the log), after which gtk is supposed to call me back and do the repaint (GtkDraw in the log). Log shows the repaint properly happens at the beginning, but then stops doing so near the end of log.... Anyway, I have added even more logging, so please one last time pull logs branch and keep testing...
mirek wrote on Tue, 22 October 2024 04:19 By "brought down" do you mean crash or (the usual) repainting stopped? repainting stopped. Quote: If the second one, it starts to look like yet another xwayland bug (assuming you run wayland - I think you do). Log clearly shows that I call gdk_window_invalidate_rect with proper parameters (it is the INVALIDATE word in the log), after which gtk is supposed to call me back and do the repaint (GtkDraw in the log). Log shows the repaint properly happens at the beginning, but then stops doing so near the end of log.... Glad to know the culprit is pinpointed. Guess there is not much we can do on u++ side. Quote: Anyway, I have added even more logging, so please one last time pull logs branch and keep testing... Test going on. PS[Wed, 23 October 2024 14:11]: whatever you have done last time has made u++ more resistant to freeze problem. I cannot tell it's completely fixed but so far both logs-ide and my app build with logs-branch u++ have been fine while master branch ones having failed multiple times. I will keep watching. [Fri, 25 October 2024 17:22] so far no problem.
I almost thought it's fixed, but here is another one.
Lance wrote on Sat, 26 October 2024 03:38 I almost thought it's fixed, but here is another one. Still the same. Let us blame xwayland... Meanwhile, all possible fixes are in master now. (Any chance to test without wayland?)
[quote title=mirek wrote on Sat, 26 October 2024 04:18]Lance wrote on Sat, 26 October 2024 03:38 Still the same. Let us blame xwayland... Meanwhile, all possible fixes are in master now. Great! OTOH, non-u++ application is unaffected, so wayland might not have a motivation to change their code. They possibly wouldn't even know about it. I mean, for now we will have to accept it but eventually we may need to work around it from our side. Quote: (Any chance to test without wayland?) Of course. I will research on the way to swith to xorg. BTW, do I still check with the logs branch?
On xorg now. Everything good so far but I had a fake freeze. Somehow a u++ application is holding to the mouse (SetCapture()) and not releasing it even with LeftUp. I went to the culprit application, brought up the context menu with right click and the problem vanished. So there is such occurance that captured mouse is not released with LeftUp, in xorg.
This freeze screen issue in dual monitor mode is not seen with xorg so far. I am switching back to wayland as it takes forever to come back from a suspension/lock screen with xorg, possibly due to settings not fine-tuned for xorg.