Opened 5 months ago

Last modified 10 days ago

#379 new bug

System unstable after experimental feature

Reported by: Samir Hawamdeh Owned by:
Priority: undecided Milestone: 5.0-2018R3
Component: undefined Version: 5.0-nightly build
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

The introduction of the experimental feature for supporting large GUIs (http://muidev.de/changeset/6251) make my system quite unstable, since its implementation i cannot open more than one MUI application at the same time … for example if i try to open a video with MUI MPlayer (while Odyssey or any other MUI app is opened) the system will turn so slow that i will be forced to close atleast one of that application if i want to use the system normally … sometimes it gonna freeze the whole system aswell …

I think, maybe you should revert back that change or found any other method to implement what you liked to implement :-)

Attachments (1)

MUI-5.0-20180702r6303-os4-debug.lha (1.2 MB) - added by Thore Böckelmann 3 months ago.
nightly debug build of muimaster.library

Download all attachments as: .zip

Change History (21)

comment:1 Changed 4 months ago by Thore Böckelmann

Well, the experimental feature will become active if and only if the window does not fit on the screen. Otherwise there is absolutely no difference to how things were handled before.

The old approach was to modify the GUI settings in such a way that the final GUI would become as small, narrow and tight as possible to make the too large window (hopefully) fit on the screen. Most of the time this was not as successful as stunzi might have expected. Additionally the modified settings applied to all other windows of the application, even if these did not exceed the screen dimensions when using the normal GUI settings.

Have you installed all classes/libraries from the nightly build archive or did you use the Installer script? The latter might skip classes during the update which have not been bumped.

comment:2 Changed 4 months ago by Thore Böckelmann

Status: newpending

comment:3 Changed 4 months ago by Samir Hawamdeh

Status: pendingnew

Yes i've installed all libs manually, but i tried both approch (installer too) in order to be sure, and after various checking all things seems installed correctly ..

Still the problem in those recent nightly builds, all appears quite unstable as descripted above
No problem with MUI 5.0 2018-R1, problem seems started since the first nightly of R2

comment:4 Changed 4 months ago by Thore Böckelmann

I just tried the most recent nightly build on FS-UAE + AmigaOS4 myself. I started 3 demos, MUI prefs and Odyssey. Ok, Odyssey complains about not enough memory, but apart from that everything runs as fast as usual. There is no noticable slowdown, at least not in my emulated system.

As I said, that new feature to insert a scrollable group as top level object to surround a too large window root object in order to avoid shrinking the GUI settings to a bare minimum only comes into if and only if MUI had to adapt the settings before. That means this only happens if the window was too big before. Otherwise nothing else is done. There is no kind of new thing that happens even if the window does fit on the screen. As such there is nothing that could go wrong by default.

comment:5 Changed 4 months ago by Samir Hawamdeh

I really don't know, still a huge slowdown here … for example now that i have a few tabs opened with Odyssey if i open SysMon i can't even move its window on screen ! .. the system become so slow that all seems "freezed" until i release the mouse button to stop the window moving …

At this point i will revert back to the old MUI5 release version and will retry to be sure if that problem was really introduced in recent nightly :-(

comment:6 Changed 3 months ago by Samir Hawamdeh

Tested the latest official release (2018-R1) and it works perfectly, evidently still somethings broken in recent nightly that prevent me to use them at all .. the system are so unstable and it slowdown heavy as soon as i open more than 1 MUI application at the same time :-(

comment:7 Changed 3 months ago by Samir Hawamdeh

Any news on this subject, any idea what might be the cause of the instability ?
All problem are gone but only now that I reverted back to the latest 2018-R1, but the system was almost unusable (with any recent nightly) —> crash, slowness and freeze

if problem will not be solved i will be forced to stay with that version :-/

comment:8 Changed 3 months ago by Thore Böckelmann

No news, sorry. I am simply not able to reproduce this issue. For me everythings runs as fast and stable as it ever did.

I can only repeat myself. The only change between 2018R1 and the first nightly build after that release is the addition of the optional scrollgroup. But that happens if and only if the window is too large to fit on the screen. If it does fit then there is absolutely no difference to former versions.

comment:9 Changed 3 months ago by Thore Böckelmann

In 6303:

  • Window.c: added some debug output regarding the last-resort-scrollgroup. This refs #379.

comment:10 Changed 3 months ago by Thore Böckelmann

Please try the attached debug version of muimaster.library and create a WINDOW debug log with it. It will reveal whether the scrollgroup is added or not.

Changed 3 months ago by Thore Böckelmann

nightly debug build of muimaster.library

comment:11 Changed 3 months ago by Thore Böckelmann

Any success with the debug build? A log perhaps?

comment:12 Changed 2 months ago by Samir Hawamdeh

No log for now, but for some reason this debug build seems working better, i mean now MUI applications turn usable again and doesn't slowdown my system as heavy as before …

Still some sporadic problem aniway, as usual i had OWB and another MUI application opened (YAM) and at some point the system start slowing down so mutch that i was not able to move any workbench window on screen …

But with this debug build now issue seems become sporadic while before i always have this problem

comment:13 Changed 2 months ago by Thore Böckelmann

Milestone: future release5.0-2018R3

comment:14 Changed 2 months ago by Thore Böckelmann

I have created some nightly build versions of previous commits dated around the release of 2018R1. Please check these as well:
commit 6244
commit 6244 debug version
commit 6248
commit 6248 debug version
commit 6251
commit 6251 debug version

comment:15 Changed 2 months ago by Samir Hawamdeh

Tested for some time r6250 and seems working as it should … apparently problem started since r6251

comment:16 Changed 8 weeks ago by Thore Böckelmann

r6250/6251 mean the versions I sent you privately? What about the three versions r6244, r6248 and r6251 I uploaded as special nightly builds? Did you test these as well?

comment:18 Changed 3 weeks ago by Samir Hawamdeh

Tested the latest r6306 you attached above, the system looks stable with that build but the system will also turn slow as soon as i try open something (not instantanely reproducible but it happens always if you use it)

For example if i have Odyssey opened in front and and the same time i try to open a simple workbench folder then i can't move its window normally … all system will slowdown making impossible to move any window on screen … i discover that to solve it and make everything usable again i need to atleast iconify OWB (or the other MUI app involved) and voilà the system turn usable again !

Just an additional info, for some reason it seems i can move the AmigaAMP window without any problem, but others not

Compared old r6250 doesn't seems suffer to that specific problem, but it isn't stable too, i had many freeze dyring usage (with both Odyssey and MUI MPlayer)

comment:19 Changed 3 weeks ago by Thore Böckelmann

Can you narrow down the guity commit of regarding the instability a bit more? There are 12 special builds created from specific commits available on the download page. It would be good to know which commit exactly introduces the instability. Unforturnately I am still not able to reproduce it myself, hence I must ask you to do the dirty work.

comment:20 Changed 10 days ago by Thore Böckelmann

Please try these two test builds:
with
without

They represent the current state of affairs, but the "without" version will never add the root scrollgroup in case window contents do not fit on the screen. This was the only code change between r6249 (2018R1) and r6251 (first nightly build after 2018R1).

Note: See TracTickets for help on using tickets.