Opened 3 weeks ago

Closed 2 weeks ago

#360 closed bug (fixed)

PD-Menu draws shadow of subcommand windows wrong (blue, probably the active marking color)

Reported by: Hubert Maier Owned by: Thore Böckelmann
Priority: normal Milestone: 5.0-2017R4
Component: Popmenu.mui Version: 5.0-2017R3
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

Sorry, i try to explain it better.

If you use the MUI PD-menu the "active" command/line gets marked by a blue color (default).
If you happen to have a line which open subcommands (→) than the parent line will stay marked as active and the subcommand lines get their marking aswell. All is fine by now.

As long as the orientation of the subommand window stays on the right side of the parent command line.

There is a little graphical glitch though, if the orientation changes to the left (e.g. if the subcommand window would open beyond the end of the screen it will be drawn on the left instead).

Then the shadow of the subcommand window will be eaither erased or overdrawn by the line marking color.

Easiest to reproduce with the MUI main settings window.

Steps to reproduce

  1. Open MUI settings
  2. Browse to "Windows"
  3. Move the main MUI window really close to the right screen edge.
  4. Right-Click on window controls "Smart"
  5. The main PD-menu will open
  6. Scroll down to the "All" submenues

The first entry will have it's shadow correct (but the marking of the line (blue) will start a few pixels after the shadow stops, which looks wrong)

Move down one entry.

The second entry will show the glitch. Not only is there a black pixel drawn on the top right of the window, it's also covered in blue.

Move down antoher entry.

The third entry will show the same.

Now don't let go of the mouse button.
Move up one entry again and see.

The third entry will now show a complete blue residue over the whole height of the line and in size exactly the pixels the blue marking for the line starts in all lines.

Move up another entry and now the second line displays the problem.

Expected results

Same correct behaviour for all entries.

Actual results

See above

Regression

Not sure, i guess i have seen this before, but never bothered to write a report

Notes

AmigaOS4.1 FE Update 1
MUI 5 21.38 (svn6041)

Attachments (5)

wrong_shadow.png (37.5 KB) - added by Thore Böckelmann 3 weeks ago.
Screenshot of faulty drop shadow on AmigaOS3
wrong_marking.jpg (291.9 KB) - added by Thore Böckelmann 2 weeks ago.
marking_glitch.jpg (1.6 MB) - added by Hubert Maier 2 weeks ago.
Glitch in place, but only on the very first line.
marking_no_glitch.jpg (3.3 MB) - added by Hubert Maier 2 weeks ago.
Glitch gone
Popmenu_21.14.lha (19.1 KB) - added by Thore Böckelmann 2 weeks ago.
Popmenu.mui 21.14

Change History (21)

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

Component: undefinedPopmenu.mui
Milestone: future release5.0-2017R4
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

I think I can reproduce this issue, although for me the area seems to be transparent instead of being filled with a specific color.

Changed 3 weeks ago by Thore Böckelmann

Attachment: wrong_shadow.png added

Screenshot of faulty drop shadow on AmigaOS3

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

Can you confirm that we are talking about the same issue here?

comment:3 Changed 3 weeks ago by Hubert Maier

Hi Thore,

thanks for getting back so quick

I'm afraid the error that is shown in your picture is not the error i'm getting.

Actually the error you have i don't get at all.

I'll attach a screenshot from my phone, don't know how i should do it othwwise.
There you'll see what i mean. It's the wrong colors right beside the mouse pointer

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

It would be nice if you could give your attachments suitable names. The .jpg extension for an image files which in fact is a 24bit ILBM image is quite misleading and makes it very hard to view the image. ILBM viewers on any other systems than AmigaOS are next to impossible to find. PNG or really JPEG is a far better choice and imposes no restriction for AmigaOS.

So please use proper file name extensions next time.

But you are right, the issue you are experiencing looks quite different to what I experienced. It might have a similar cause, but I must investigate what might be causing it.

comment:5 Changed 2 weeks ago by Hubert Maier

Yes i'm sorry, i was in a hurry to post that glitch and missed that i was uploading an AIFF.

Looking forward to know what causes this

Changed 2 weeks ago by Thore Böckelmann

Attachment: wrong_marking.jpg added

comment:6 Changed 2 weeks ago by Thore Böckelmann

I just replaced your screenshot by a real JPEG one. Unfortunately I don't have a clue about the cause of the issue yet :(

comment:7 Changed 2 weeks ago by Thore Böckelmann

Does this effect happen with compositing disabled as well? Unfortunately I haven't a working AmigaOS4 machine around right now.

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

In 6088:

  • Popmenu.c: added a tiny delay between closing the submenu of the previous active entry and opening the submenu of the new active entry. At least on AmigaOS3 this fixes the intermittend glitches in the drop shadow effect. This refs #360.

comment:9 Changed 2 weeks ago by Thore Böckelmann

Please try the next nightly build. I hope the tiny delay I just added fixes this issue. It should give the compositing task to accomplish its work between closing one submenu and opening another one instead of working with outdated graphic data. At least this is how I understand the situation…

comment:10 in reply to:  7 Changed 2 weeks ago by Hubert Maier

Replying to Thore Böckelmann:

Does this effect happen with compositing disabled as well? Unfortunately I haven't a working AmigaOS4 machine around right now.

I just tried with Compositing off and the error is completely gone, looks perfect.

comment:11 in reply to:  9 Changed 2 weeks ago by Hubert Maier

Replying to Thore Böckelmann:

Please try the next nightly build. I hope the tiny delay I just added fixes this issue. It should give the compositing task to accomplish its work between closing one submenu and opening another one instead of working with outdated graphic data. At least this is how I understand the situation…

Well, if this is the correct nightly build - 21.90 (svn r6089) - then i can report that you "nearly" fixed it. :-)

The glitch with the marked line (blue) starting a few pixels *after* the shadow is only visible in the very first submenu line anymore and only when one first opens that line.
When one scrolls back up it's fixed, strange.
But the glitch will return once one goes back to the very first line…and here comes the real brainer :-)
It won't come back every time :-)

Hard to explain, i'll try with pics.

First picture is with glitch in place.
Second is with no glitch, after i scrolled down one line (second and third line with no glitch at all) and scrolled back up to the first line the the glitch will *always* be gone too.

But…

…if i scroll back up to "Presets:AmigaOS4" and back down to the first line again, the glitch will be back…but, not always.
Trying 10 times the glitch was there 3-5 times.

Really strange behaviour, but you are on the right track, don't give up :-)

Changed 2 weeks ago by Hubert Maier

Attachment: marking_glitch.jpg added

Glitch in place, but only on the very first line.

Changed 2 weeks ago by Hubert Maier

Attachment: marking_no_glitch.jpg added

Glitch gone

comment:12 Changed 2 weeks ago by Hubert Maier

Sorry, the first picture is a lttle dull, but you can see the glitch is in place

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

In 6090:

  • Popmenu.c: do the tiny delay before opening any submenu to avoid race conditions with AmigaOS4's compositing. This refs #360.

Changed 2 weeks ago by Thore Böckelmann

Attachment: Popmenu_21.14.lha added

Popmenu.mui 21.14

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

Please try Popmenu 21.14 and report back whether the initial glitch is fixed or not.

comment:15 Changed 2 weeks ago by Hubert Maier

That fixed it.

Kudos for the quick feedback and fix.

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

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.