Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#175 closed enhancement (fixed)

SysSpeed listview slowdowns

Reported by: Mikhail Malyshev Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2015R2
Component: Slider.mui Version: 4.0-2015R1
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

Problem

In previous versions of MUI the scrolling of the test result in SysSpeed was nice and smooth.
With current MUI4 this scrolling is now pulsating.
(It allows to scroll smoothly about 70% of the screen content, then locks up a bit and then scrolls again)

Enhancement recommendation

Anything can be done to improve it? Or some setting changed to improve it?

Change History (9)

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

Which scrolling are you referring to? The normal scrolling of the lists? Or some kind of scrolling as part of one of the tests? As virtually always your description is not very verbose and makes it hard to reproduce the issue. Especially for AmigaOS3 it is very important to state the system you are using. Is it WinUAE or a classic HW system?

All redraw operations of List.mui are double buffered to reduce any possible flickering due to time consuming background rendering to a minimum.

Scrolling is done is two parts. The part of the list that remains visible is scrolled using graphics/ScrollRaster() and all newly visible lines are rendered as usual. One of the two actions takes more time than the other, most probably the rendering of the newly visible lines. This cannot be avoided.

comment:2 Changed 4 years ago by Mikhail Malyshev

RealHW and UAE(AmiKit setup) is the same here.
The scrolling I refer to is the results/comparison table (main view)

It looks like the new list code is more like Nlist now with extra bells, since we can now resize the columns and hide them. (hiding all data does not help on speed, rendering just background patter)

window about 1000x800, If you drag the list by scroll bar, it does not follow the mouse smoothly but jumps from place to place (I guess we are rendering something at that time) so the new class has much more overhead compared to what we had before. It's like comparing CED scrolling (older MUI) and Wordworth (MUI4).
One is nice, responsive and smooth, the other is clumsy and jerky.

I think I know the result, we need gigahertz and it will still be slow.
Or maybe we can have an option per application how far the newer list view goes?

comment:3 Changed 4 years ago by Thore Böckelmann

Component: Listview.muiList.mui
Milestone: 4.0-2015R2
Priority: undecidednormal
Resolution: invalid
Status: newclosed

Then stick with MUI 3.8 if you prefer the old implementation.

comment:4 Changed 4 years ago by Mikhail Malyshev

Resolution: invalid
Status: closedreopened

Found the problem!!!

The problem is not the listview, it's the new internal slider gadget (in MUI4).

Since MUI39(final) uses the new listview and the old external slider gadgets (XEN Bar ets.) and that combination works smoothly.

What I have notices is the the new slider is constantly refreshed when it is moved (when held by mouse) thus causing interrupts that effect the smoothness of other task.
Listview is most noticeable since it's big, but at close examination it effects everything, even the simple main MUI prefs settings listview.

Can we do something about this please?

comment:5 Changed 4 years ago by Thore Böckelmann

Short answer: no

Long answer: no, because BOOPSI sliders suck and only MUI's own sliders can be displayed correctly in all possible situations (i.e. partly in virtual groups). Place a slider using the old BOOPSI images in a virtual group and make it just partly visible. You will then see why the BOOPSI images are not acceptable any more. Furthermore they are limited to the imagery the developer wants to offer. The new sliders can make use of any graphical effect that MUI offers.

Of course the new sliders are only redrawn when the mouse is moved at least one pixel. Why do you think that it is the slider that causes the slowdown for you? The slider's area is small compared to the list object. Hence it is redrawn lots faster than the list.

comment:6 Changed 4 years ago by Mikhail Malyshev

Reason 1 - the same code (eg. ListView in MUI40 and 39 is the same)

the only difference is the slider, with 39 it is silky smooth,
with 40 it is jerky (when you drag select it) but also smooth
if you just click the empty area to screen scroll
(just 1 refresh of the gadget)

Reason 2 - again if we slow motion everything to max (UAE can help here nicely)

we can see that a quick move of the slider no longer follows the mouse
as it used to be and compare it to MUI39

Reason 3 - another simple test is to scroll a small empty list that uses little resources

yet the constant redraw/recalculation of the slider consumes a lot of cpu time
maybe it's connected to the way the gadgets exchange events hendling?

Reason 4 - all other classes are effected, and the only common item is the slider.

eg. TextEditor scrolling becomes jumpy.

I guess the problem with BOOPSI that you refer to is inability to select the gadget if it is partially hidden.
This is obviously not good, the current implementation allows to use it by just 1 pixel. (Virtual Demo)

So if it is the gadget, and not something else (internal MUI house keeping not obvious to outside observer)
it needs to be tweaked somehow to give it similar response to the older BOOPSI method ('non blocking')
Since it's obviously not just a simple redraw involved, both methods require similar small cpu resources
to update the little graphics of the slider.

comment:7 Changed 4 years ago by Thore Böckelmann

Component: List.muiSlider.mui
Owner: set to Thore Böckelmann
Status: reopenedassigned

comment:8 Changed 4 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

In 4630:

  • Slider.c: fixed a double redraw of the slider during mouse movements by using the MUIA_Prop_Quiet attribute to prevent Prop.mui from doing any further update action. This possible action must only happen if the update is not caused by mouse movements. This closes #175.

comment:10 Changed 4 years ago by Thore Böckelmann

In 4800:

  • Prop.c, Slider.c: fixed the redrawing of the knob at wrong positions when mixing scroll actions by moving the knob directly and clicking above/below it. The former did not correctly set the MUIA_Numeric_Value attribute and hence the knob was drawn at the wrong position in case a click above/below the knob happened after a direct movement. This refs #175 and closes #223.
Note: See TracTickets for help on using tickets.