Opened 5 years ago

Closed 4 years ago

#187 closed enhancement (fixed)

Scrollbar scrolling

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

Description

Please see videos
MUI39 - smooth scrolling, slider attached to mouse pointer
MUI40 - jumping scroll, slider lags behind pointer

IMHO: The priority of the slider needs to be higher so that it always follows the mouse (either being more multitasking or by breaking the other rending process if sliders position has changed
and redrawing the slider at top priority, and only redraw the connected list or whatever with the left over cpu resources, or something like that) Currently slider waits for other processes to complete before getting updated and the more complex the scrolling area contents the worth the situation becomes)

If it's impossible to do with the new method, then please offer an option to use 39 or 40 drawing method.

PS: it would also be nice to add a second selected frame option for the gadget, without it it's impossible to get the original XENBAR style (selected frame all black, with no 3D effect)

Attachments (2)

MUI39.avi (2.3 MB) - added by Mikhail Malyshev 5 years ago.
MUI40.avi (2.4 MB) - added by Mikhail Malyshev 5 years ago.

Change History (7)

Changed 5 years ago by Mikhail Malyshev

Attachment: MUI39.avi added

Changed 5 years ago by Mikhail Malyshev

Attachment: MUI40.avi added

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

Component: Scrollbar.muiSlider.mui
Milestone: 4.0-2015R2
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

First of all, basically this ticket is a duplicate of #175 which has been closed already, because I did all that could be done.

You don't know the inner details of MUI. The class hierarchy of Prop.mui has changed between 3.9 and 4.0. In 3.9 Prop.mui was a subclass of Gadget.mui which must be used if BOOPSI gadgets are to be handled. In 4.0 Prop.mui is a subclass of Slider.mui. BOOPSI gadgets usually render themself in the context of input.device which runs at priority +20. MUI usually renders all its objects at the application task's priority. That's why it the slider seems to lag behind. There is no way to change this, no matter how often you ask for it. This only thing I can do for you is to implement a customizable selected background for the slider. If that is not enough for you then better go back to MUI3. It becomes more and more obvious that MUI3 better suits your whishes. And there is no need to dicuss this topic any further.

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

Resolution: fixed
Status: assignedclosed

In 4632:

  • Slider.c, Settingsgroup.c: implemented a customizable background image for a pressed slider knob. It defaults to the normal background image. This closes #187.

comment:3 Changed 5 years ago by Mikhail Malyshev

IF I understood correctly the slider task can not have a higher priority
and can not have priority over the slider attached area thus making precision scrolling a difficult task since gfx updates are done in turn and until one step is completed we can not return to the other (constant (or multitasking) slider update but interrupted drawing of connected area).

comment:4 Changed 5 years ago by Mikhail Malyshev

Resolution: fixed
Status: closedreopened

Can we run the slider in a separate thread with a higher priority (+1) then the connected task ? This will give it perfect near boobsi uninterrupted type scrolling that does not need to wait for the connected scroll area to update which if complex can really slow down and make it uncomfortable even on fast OS4 machines. (non responsive interfaces are © M$windows)

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

Resolution: fixed
Status: reopenedclosed

Replying to Michael:

Can we run the slider in a separate thread with a higher priority (+1) then the connected task ?

No, we can't.

Note: See TracTickets for help on using tickets.