Broad windows get slower on SAM-flex in HD...??

Would somebody please test this small but strange issue. It needs a SAM with a Radeon 9250/128MB running in 1920x1080 mode (or higher?) in ARGB32 mode.

1) Open a Shell window (works with other types of windows also, but let's keep it simple)

2) Resize it to cover the _entire_ screen width, that is all the way from left side of the screen to right side of the screen. Make the height of the window as small as possible.

3) Drag the window around. If you have the same setup as me, you should notice, that it is very jerky.

4) Resize the window, so it is just about 100 pixels less wide.

5) Drag the window around again. You should notice, that it now drags completely smooth.

How is this possible?

6) Resize the window to cover the _entire_ screen height, and make it wide enough, that it has _at least_ the same volume as the previous window when it covered the entire width of the screen.

7) Drag it around and notice, that there is no problem dragging around that much window, when it is distributed in height instead of width.

Is this a bug, or is it just something nifty with the Radeon card?

NB: Changing to a lower resolution and/or changing to 16-bit removes the issue. Also, the problem doesn't seem to be there on an AmigaOne with Radeon 9250/256MB. Strange...

@alfkil

It's almost certainly happening because you are using up all the available graphics memory with the big window and the system is having to swap graphics content in and out of RAM.

If you try it with a more complicated window (something with a background picture, for example), you will probably find that the same problem happens with a smaller window than the plain console window you are using now.

If I'm right, there is no cure other than to reduce your requirements (smaller screen, reduced resolution, etc).

@tonyw

Quote:
Well, but note what alfkil says in 2. above: "Make the height of the window as small as possible.". So we're not talking about a very big window.

Quote:
Well, it seems to be "cured" by changing the window's height/width relation without making it smaller altogether, AFAIU.

Best regards,

Niels

@tonyw + nbache

As niels says, it's not the size of the window that triggers it, it's the width _independantly_ of the height. A window of the same volume, but with more height, doesn't display the same behavior.

Furthermore, the effect is the same no matter what type of window I use (I just chose Shell for the example for simplicity). If I do the same with a workbench folder, the dragging is _altogether_ slower and more jerky, but there is the very same drop in performance when I reach the _exact_ same width as with the Shell window. So no, it is not only the amount of video ram used, it is something else as well.

Also there is a small "feature", that should work in any resolution with Autoscoll turned on and has the same size as the screen: If you move a windows titlebar way up so it goes out the top of the screen, you will notice, that you cannot resize the window all the way to the bottom!

@alfkil
@nbache

I can confirm that here. And a (shell) window larger than the visible screen amplifies this effect even more, whilst resizing the window in double or tripple of screen hight and a width of ~600 pixel does not. It behaves (almost) like a window with a usual size.

Screen resolution is 1920x1080 on SamFlex


edit: I noticed another small glitch, resizing the window vertically to approx 165-185% of the screen size all in a sudden the upper window border becomes just a rectangular shaped solid. Window title and gadgets disapper as do the round corners if set to be. By slowly increasing size everything appears again after an approx 15 pixel gap. Downsizing the window again produces the same effect at the same position/window hight.

@alfkil

I would guess that you are reaching the hardware limit of the graphics, so that the compositing is falling back to software mode. NOt 100% sure on that though.

OK. Here's my theory.

In OS4.1.1, window drop shadows don't work in 16bit screenmodes, but they do in 32bit.

When the window is wide, the shadow is longer. When the window is vertical, the shadow is the same.

Makes sense to me!

@alfkil

Same prob with SamEp667Mhz, 1680x1050@32bit with the on board gfx and while having 25MB free at the gfx ram. The problem is when resizing horizontally and not vertically when the option resigning with contents is ON regardless the contents of the drawer.

Just a note:

Has someone reported this problem (or maybe "problem")? I don't know
who to report to .


EDIT:

@MickJT:

But that doesn't make sense, since the shadow is both to the right and beneath the window, so a vertically extended window will also have a large shadow. My personal theory is, that it somehow has to do with the size of blocks or chunks that video memory can be allocated in, but then again, I don't know a thing about modern graphics chips design.

@alfkil

Quote:
Wow it's too much for my monitor which is already huge for my taste. I reach 1680x1050 here and your test case runs smooth...

@all
If you are all using a Sam440 Mini-ITX (not Flex), then I guess broadblues is right, and you are hitting some limitation of the built-in graphics chip. The Mini-ITX's gfx chip was *never* intended for such huge resolutions, and you start to notice limitations/difficulties above maybe 1280x1024.

@ChrisH

Please read the previous posts again, I'm using flex here with Radeon 9250/128MB. Also, the problem is not the amount of video ram, because a comparatively high window doesn't display the same 'huckups' as a wide one.

@Elwood: If you try and run an autoscrolling screen in resolution 1280x1080 but with actual width set to 1920, you are able to reconstruct the same behavior in a smaller resolution.


Hmm, I guess people think that this is a pretty lame problem to bring up. Now consider this: I use Shell windows _all_ the time, and when opening a new shell with 'cli', you get a window, which covers the entire width of the wb screen. While I kind of like this "widescreen consol'ism", I hate the fact, that dragging the shell feels itchy, and I always end up resizing the shell to a little less than the entire width of the screen, just to get rid of this hick'ing. Is this lame? I don't know, you tell me

EDIT: Yeah I know, it's lame...

@alfkil Quote:
I wasn't only referring to that, for example DVI digital output does not work very well above 1280x1024 on the Sam440 Mini-ITX.

BTW, sorry about not re-reading the entire thread to check which h/w people with the probem were using.

@alfkil

have you tryed to "remove" (set to 0, if possible) the drop shadow? i think MickJT have a point here

@Framiga

Yup, or rather now I'm running 16-bit with no shadows, no problems as they say. Bit of a shame, though.

EDIT: Is there a tag to disable shadows in 24-bit?

@alfkil Quote:
There should be! Maybe there is an easier way, but this should at least work:
Prefs/GUI, Effects, then set "X shift", "Y shift" & "Smoothness" to 0.