Opened 6 months ago

Closed 7 days ago

#379 closed bug (fixed)

System unstable after experimental feature

Reported by: Samir Hawamdeh Owned by:
Priority: normal Milestone: 5.0-2018R4
Component: Imagespace.mui Version: 5.0-nightly build
Severity: minor Keywords:
Cc: Hubert Maier 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 5 months ago.
nightly debug build of muimaster.library

Download all attachments as: .zip

Change History (30)

comment:1 Changed 6 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 6 months ago by Thore Böckelmann

Status: newpending

comment:3 Changed 6 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 6 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 5 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 5 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 5 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 5 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 5 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 5 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 5 months ago by Thore Böckelmann

nightly debug build of muimaster.library

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

Any success with the debug build? A log perhaps?

comment:12 Changed 4 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 4 months ago by Thore Böckelmann

Milestone: future release5.0-2018R3

comment:14 Changed 4 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 4 months ago by Samir Hawamdeh

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

comment:16 Changed 4 months 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 months 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 months 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 2 months 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).

comment:21 Changed 3 weeks ago by Hubert Maier

I can NOT confirm this behaviour.

Though i'm using this for testing:
https://muidev.de/download/MUI%205.0%20-%20Release/MUI-5.0-20180913r6251-os4_with_root_scrollgroup.lha

Yam, Odyssey and MUIMPlayer running (while playing a movie) and everything is fine (apart form the video replay hogging the cpu)

comment:22 Changed 3 weeks ago by Hubert Maier

I now tested
6244
6248
6251
6261
6278
6296
6306
from comments 14 and 17 and none display OP's problems.

As i don't know OP's system i can only guess that the video reply from MUIMPlayer hogs his cpu (as it does with mine) and thus slows down the system.
I have quite a few framedrops in the video replay while typing this parallel in Odyssey and having YAM open.

But it works and doesn't become unstable (the responsiveness goes down at most, but that is to be expected).
Once the video replay is done the responsiveness of my system comes back to normal, so i would like to take a wild guess and assume OP's system is just not fast enough to perform all those tasks at once.

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

Milestone: 5.0-2018R35.0-2018R4

comment:24 Changed 12 days ago by Thore Böckelmann

Please test fixed hash and/or the next upcoming nightly build.

comment:25 Changed 11 days ago by Thore Böckelmann

Cc: Hubert Maier added
Status: newpending

Now that #387 is finally fixed, can everybody please check whether this ticket still needs further work to be done or not?

comment:26 Changed 11 days ago by Samir Hawamdeh

Status: pendingnew

Sure, I will do an intensive test tomorrrow starting from the next nightly

comment:27 Changed 10 days ago by Hubert Maier

I'm sorry, but i guess Samir is better suited for this stress test, as for me, not even with that gfx mem bug around, it never became unstable.

comment:28 Changed 7 days ago by Samir Hawamdeh

@Thore

I'm glad to say that this bug seems finally fixed, i put the system in various stessing situations and i have no more slowdowns nor crashes, great !

You can close the ticket for now :-)

comment:29 Changed 7 days ago by Thore Böckelmann

Component: undefinedImagespace.mui
Priority: undecidednormal
Resolution: fixed
Status: newclosed

Great news!

I will delete all the test builds. Most of them have expired already anyway.

Note: See TracTickets for help on using tickets.