Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#137 closed bug (fixed)

Text in Download window not respecting border

Reported by: Hubert Maier Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2015R1
Component: List.mui Version: 4.0-2014R4
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

If a download is active (which has a certain length in it's filename) and the download window open, the name of the downloaded file is being drawn over the right border of the download window (See attached screenshots).

Also due to this the download window cannot be scrolled horizontlly anymore.

Steps to reproduce

  1. Go here: https://app.box.com/s/u48rb9dqrbowiq29u4z1

(I don't know how long this upload site will be available, i chose it because it's reproducable with it)

  1. Download HBT_OS4

Expected results

The download windows borders being respected and not overwritten
The horizontal scroller should be still working

Actual results

  1. The right window border is breached everytime i download that file
  2. The information displayed in the downloads window cannot be scrolled horizontally anymore (see second screenshot), it will stay with it's broken look

Regression

Not sure about that, i never experienced it with AmigaOS4.1.6, then again, i never downloaded that file from that website

Notes

AmigaOS4.1 FE
MUI 20.6294 (svn r4117) 31.10.2014

Attachments (3)

Downloads_000.png (21.3 KB) - added by Hubert Maier 5 years ago.
Breached right border
Downloads_001.png (17.6 KB) - added by Hubert Maier 5 years ago.
Horizontal scroller not working anymore
odyssey_network_nigthly_r4406.png (1.0 MB) - added by Samir Hawamdeh 5 years ago.

Download all attachments as: .zip

Change History (18)

Changed 5 years ago by Hubert Maier

Attachment: Downloads_000.png added

Breached right border

Changed 5 years ago by Hubert Maier

Attachment: Downloads_001.png added

Horizontal scroller not working anymore

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

Component: undefinedList.mui
Milestone: MUI 4.0-2015R1
Priority: undecidednormal
Version: 4.0-2014R54.0-2014R4

This is exactly the same issue as described in #91.

If you look very closely at your screenshot you will notice that the filename really ends within the window's area. Hence scrolling is not possible because there is nothing to scroll. The problem is just that the scrollbar is still visible although it should be hidden. But that seems to be a graphical remnant just like the overdrawn window border.

Unfortunately I was not able to reproduce this issue myself so far. It might be related to the screenmode + depth. I am using a 1280x1024x16 Workbench on my µA1 and most people who encountered this issue are using 32bit Workbench. But even if I switch to a different screenmode it never happened for me so far. This makes it very hard to search for the reason.

comment:2 Changed 5 years ago by Hubert Maier

Hi Thore,

Maybe you need to exactly hit the border pixel with the last letter of the filename?
This turns out to become very specific and hard to reproduce on another resolution, with another font, font size and probably also with another theme used, i believe.

Is there anything i can do right now?
Using a debug build with special flags turned on, for example?

As i said it's reproducable everytime for me.

I too use a 32Bit workbench with the insane resolution of 2560x1440 (just because my monitor and gfx card can do it) ;-)

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

Replying to Raziel:

Maybe you need to exactly hit the border pixel with the last letter of the filename?

Why should that be the cause? Your screenshot proves that at some point in time MUI had to display a far longer filename which definitely exceeded the window's width.

But I must admit that I completely missed your 2nd screenshot which clearly shows that the scrollbar is visibile and working, but doesn't cause a correct redraw of the list object.

It is also obvious that the filename must be very wide, because the knob is quite slim in comparison to the list's width.

As i said it's reproducable everytime for me.

I will try tonight at home. Perhaps things become easier this time.

comment:4 Changed 5 years ago by Hubert Maier

Yes, sorry, i should refrain from making assumptions on things i don't understand :-)

The filename was the (i think temporarily) assigned full link which was at the time of downloading https://dl.boxcloud.com/bc/4/5a846edd1bb9c22da9a5aa74496c2f3f/5Y34ZZ4aJiZjk4vi_

OK, if you got something for me to do then, i'll be watching this space

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

Status: newaccepted

I can now confirm that this issue is happening for me as well as soon as I switch my Workbench to 32bit. With 16bit depth there is no problem.

What is really puzzling is the fact that the list contents are still updated during the download, but no matter how far one scrolls to the right the contents get displayed as if no scrolling was done at all. However, the title buttons are always correctly scrolled.

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

Owner: set to Thore Böckelmann
Status: acceptedassigned

Ok, I finally found the reason why the corruption is happening. The URL consists of so many characters that the virtual group containing the list contents must become wider than 8191 pixels. For 32bit screenmodes this is impossible. Hence allocating a temporary bitmap fails and List.mui falls back to draw directly to the screen. This explains why the entries are still updated during the download, but scrolling is impossible, because the horizontal shift is no longer taken into account.

The limit of 8191 pixels for 32bit screenmodes stems from the fact that bitmaps carry a value named "BytesPerRow" which is an unsigned 16bit value. This alone limits the maximim width of a 32bit deep bitmap to 16383 pixels. What makes it worse is the fact that certain functions in graphics.library treat coordinates as signed 16bit values. Hence the maximum allowed width is ((65536/4)/2)-1=8191 pixels.

Now, from my point of view we have two options:

  1. restrict the virtual group to keep its width below the magic frontier of 8191 pixels on 32bit screenmodes. 16bit screenmodes can go beyond that, because of the math explained above.
  2. enhance graphics.library of AmigaOS4 in such a way that at least offscreen bitmaps might become wider than 8191 pixels.

I consider the first to happen earlier ;)

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

In 4405:

  • mastergfx.c: restricted the width of render bitmaps to 4095 pixels in case of truecolor screens. This refs #137.

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

Please check again with the next nightly build.

Please note that too long lines might end unexpectedly although their column is currently wider. This happens due to the restriction of the temporary bitmap width to display entry the while the column still has the unrestricted width. I will see what can be done about that later.

comment:9 Changed 5 years ago by Samir Hawamdeh

@Thore

Ok, I finally found the reason why the corruption is happening

So that means we have now solved bugs #30 and #91 aswell ?

enhance graphics.library of AmigaOS4 in such a way that at least offscreen bitmaps might
become wider than 8191 pixels.

Did you have already reported this bug to Hyperion ?
If not i can report this one on their forum :-)

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

So that means we have now solved bugs #30 and #91 aswell ?

I hope so.

enhance graphics.library of AmigaOS4 in such a way that at least offscreen bitmaps might
become wider than 8191 pixels.tr

Did you have already reported this bug to Hyperion ?
If not i can report this one on their forum :-)

This is no bug but a limitation from ancient times which can not be easily be changed without possibly breaking lots of software which peeks at stuff it should not have any interest in. Apart from that as an OS4 developer I have access to Bugzilla myself.

Changed 5 years ago by Samir Hawamdeh

comment:11 Changed 5 years ago by Samir Hawamdeh

@Thore

This is no bug but a limitation from ancient times which can not be easily be changed without
possibly breaking lots of software which peeks at stuff it should not have any interest in.

Yep tou right obviously isn't a bug, i used a wrong term to refer it

Apart from that as an OS4 developer I have access to Bugzilla myself.

Ok :-)

Today i did a few test using the MUI4 nightly r4406, but sadly i was able to reproduce the issue again, atleast on the Odyssey's network window, see grab above

Version 0, edited 5 years ago by Samir Hawamdeh (next)

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

In 4410:

  • mastergfx.c, List.c: removed the too wide bitmap check again and revert the list render code to its (almost) original state. Now everything relies on automatic clipping by the graphics system while using negative coordinates in case the list is scrolled to the right. This makes it possible to use a small temporary buffer again which speeds up rendering very long lines a lot. This refs #137.

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

This issue should be fixed with the next nightly build. At least for me everything is working correctly now. Please reopen the ticket otherwise.

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

Resolution: fixed
Status: assignedclosed

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

Milestone: MUI 4.0-2015R14.0-2015R1

Milestone renamed

Note: See TracTickets for help on using tickets.