Opened 4 years ago

Closed 4 years ago

#166 closed bug (fixed)

Bubble Help clear routine

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

Description

As required, separate Bug.
Bubble drawing routine draws unnecessary background fill when clearing the bubble.

This slow motion capture shows it all:

https://muidev.de/attachment/ticket/116/MUI-Bubbles-help.avi

How was the bubble cleared in 3.8 and early 3.9 ?
There was no ripping effect (background filling polygon) as seen in slow motion capture. It's hard to see on CRT, and almost impossible to spot on LCD screens due to their slower refresh nature. I had to do a 100Hz capture to get a vivid view of what is happening. (it is as if the option with clear/without clear is applied to the bubble)
But it does irritate the eye because it worked nicely before and does not at the moment. And the other persons problems might be solved too, since as I understood the older code works for him, and the new one has glitches.

Change History (8)

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

Component: undefinedmuimaster.library
Priority: undecidednormal
Resolution: invalid
Status: newclosed

Reread my last comment of ticket #116. Hiding the bubble is a simple CloseWindow() plus a refresh of the window beneath the bubble's window. That might imply a background colored area to be visible for a short time. This is how MUI's refreshing is working since ages. Exactly the same happens whenever another window in front of a MUI window is closed. At least the formerly covered area must be redrawn.

comment:2 Changed 4 years ago by Mikhail Malyshev

Why refresh the window ?
If the bubble is open, the app usually freezes before it hides due to mouse movement.
If the window has something refreshing under the bubble, it will get refreshed anyway when the bubble is removed.
eg. busy mcc, the bubble opens on top of moving gfx that obviously get cough in fake transparency mask.

Until 2005 MUI did not refresh the window under the bubble I guess.
So what was the reason to do it? Irritate the eyes by a useless refresh and one frame flicker?

comment:3 Changed 4 years ago by Mikhail Malyshev

Still open, any comments to last message?

Also found a nice case where the problem is seen in full glory - SCSIBench tool.
On older hardware with 100% usage of IDE port the system becomes very slow and unresponsive which is good for our case.
Move the mouse over a setting to display the bubble help, then move mouse out of button. Bubble help gets cleared, then!!! a new window opens and draws a full size background fill, then draws some lines, then clears itself.
What's the point of this stupid operation?!

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

You very obviously have absolutely no idea how the layer and window system of AmigaOS works.

A refresh of the window might be necessary if formerly hidden parts of the window become visible again and the window is a SIMPLEREFRESH window. The now visible again part must be redrawn, otherwise you will end up with a background filled area instead of the GUI imagery you are expecting. And that is exactly what you are seeing if you slow down the system extremly: a background colored area at first and then the GUI draws itself again from bottom to top, which might become visible as several single draw operations in the area until the former GUI imagery is completely restored.

This topic is not to be discussed any further, because this is how AmigaOS works. Accept it.

comment:5 Changed 4 years ago by Mikhail Malyshev

Let me put it the other way. Previously this window were in smartrefresh mode, now as you say they are in simplerefresh mode. That explains it why it draws like that, and it is correct. But why can't we have them as smartrefresh then ? Why not make an option for these then?

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

Resolution: invalid
Status: closedreopened

Ok, I will implement this. But smart refresh comes with a price. Any complaints from your side about increased memory usage will be ignored silently.

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

Component: muimaster.libraryWindow.mui
Milestone: 4.0-2015R2
Owner: set to Thore Böckelmann
Status: reopenedassigned

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

Resolution: fixed
Status: assignedclosed

In 4589:

  • Window.c: the window refresh type can be configured (again) now. It defaults to simple refresh which will redraw any newly revealed portions of the window instead of restoring it from an off-screen bitmap. The latter is faster but requires more memory. This closes #166.
Note: See TracTickets for help on using tickets.