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.

@Amigo1

Hehe, you've got a grip at the right end of the stick... now take a look at this:

http://video.google.com/videoplay?docid=7065205277695921912#



No, of course you don't have to sit and watch 2 hours of psychological internet p***ography! 8-D But really, in the end, it all comes down to us all being trapped in the greed based profit system, and theoretically we should be able to use technology to free ourselves from menial labour, making room for everyone to contribute COST FREE to the spiritual heritage of humanity .

@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!

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...

@yoodoo2

Quote:

Hehe, I'm actually trying to research a bit into the subject at the moment. Since all userfriendly online resources on ppc assembly seems to point to Mac OS, it is definitely something that is missed. I might try and write a small tutorial kind of thing on the subject, and if it makes the deadline, you are of course free to use it .

How about a short section on ppc register and stack use in aos4? This would enable c-programmers to optimize small sections with asm .

@broadblues

Quote:

Hmm... Yeah, that's strange. I'm not in the same place as my Sam right now, so I will have to check when I get back in a week or so.

EDIT: I forgot to mention, that I changed from linking dynamically to linking static - this was because Edgar provided me with an updated static freetype library, so I no longer needed to use the OS .so version. I don't remember the exact phrasing of the error messages, when I link static only. I'm quite sure, that they mention REL24 relocation truncated, but I'm not sure that they mention .plt at all. I will have to check...

Quote:

Well, nothing special, really... it's "just" the libQtWebKit module It seems to consist of appr. 1500 object files...

@broadblues

Quote:

But at the moment, I'm not using any shared objects at all, so _therefore_ it's not an issue.

180 MB is the real size of the library with no debug information. It contains nearly 1500 object files . The executable itself ends up being 80 MB in size.

Quote:

I know the issue is a bit tricky, but so far I have had no issues with using AmiCygnix in combination with shared objects, probably due to the fact (as you point out yourself) that the Amicygnix libraries never calls code in the shared objects. But yeah... Maybe I'll ask Edgar to do a .so version of the libraries, hope he has time .

@tonyw

Hmm... I'm not sure, I think I'm only using newlib libraries. Anyway, all the Amicygnix libraries are static, the rest are not.

But since I just managed to compile and link the whole thing with only static objects, and since the critical factor turns out the be the -mlongcall flag, mixing shared and static objects shouldn't be the issue.

I'm not sure wether -mlongcall versus no -mlongcall is going to be an issue, though...?

@nbache

Yes, making it smaller would be a good solution. Problem is, I know so relatively little about the code I'm working with, so I wouldn't know where to start...

In the meantime, I managed to compile and link the code by means of adding -fPIC and -mlongcall to the compiler and recompiling all the Qt libs (the recompile took just about 20 hours...). Of course I can't know for sure, but I think the critical point here is the -mlongcall flag, that supposedly turns all the relative jumps and branches into absolute 32 bit ones. I'm building with only static objects now (no -use-dynld), so the shared objects V1 vs. V2 is not the issue. Also, I tried linking static only with my old objects (those without -fPIC and -mlongcall), and it still didn't work...

Problem with -mlongcall is, that the code gets slightly slower. Next thing I'm going to do is, that I'm going to link the Qt libs as all shared objects and see if I can get it working that way. As you said, Niels, I might have to split up the WebKit library in smaller parts to get it working.

Still my conclusion is, that if this is a general issue with large executables compiled with gcc on aos4, then there should be some information on how to solve it in the SDK docs, because other people are bound to get into the same problems as me in the future. Also, -mlongcall would not be a general solution unless ALL of the libraries used to link the code are compiled with this flag. As for my example, I'm just lucky, that recompiling Qt "solved" the problem.

@emeck

Nope, it's not Netsurf . I have netsurf installed, and I think it works well, even through Amicygnix.

@broadblues

Hehe, you are spot on .

It's "just" the webkit engine in a Qt wrapper, and as you say, it's not really very fancy at all. Nevertheless, if I manage to get this one running, there is a much more elaborate demo-browser in the Qt package, that has tabbed browsing, download manager etc. And of course it's going to be rather slowish running in Amicygnix, but hey, there is going to be no native Qt before I have the X11 version up and running at full feature level .

For those of you, who should be interested in Qt, I can tell you, that all the command line tools, QtCore and QtGui are up and running, and all the simple widget examples work pretty much flawlessly, except for a few minor problems.

...and yes, I know this screenshot is actually rather pathetic, but still I have spent quite a lot of time and energy just getting to this point, so I thought I would at least show it to the public...

@328gts

Yeah, Timberwolf.... mmmmmmmm! 8-D

(Notice the super cool "[Not responding]" tag at the top..... Doh!)

... What is this ??!...

http://dl.dropbox.com/u/5482530/fancybrowser.jpg

..... it sure ain't Timberwolf... so what is it.....?

@phx

Thanks for the info. It seems, that the issue have been fixed with later versions of gcc (4.4 or smth), but that doesn't help me a lot. Some people seem to think, that it can be avoided by compiling libraries as shared objects (that's pretty much what I'm trying to do at the moment) and possibly by compiling everything with -mlongcall. I have tried compiling the executable code with -mlongcall, and it _does_ seem to have an impact on the problem, but it doesn't remove it, it just "shifts" the problem to a new area. I'm guessing, that if I'm going to make it work, I'll need to compile EVERYTHING - including newlib - with -mlongcall, and that's a bit of a problem, since I don't even have access to the newlib sources...

Are the newlib sources available somewhere, or is it proprietary stuff? I've tried to contact J?rg, but he's probably too busy to answer. Also, I'm interested in knowing, if the adtools project on sourceforge is still active? It seems, that the last release was 20 months ago...?

This is a big shame, since my project was going so well until now...

@Coder

Hehe, I actually started writing a book on "modern Amiga programming" (intended to include a section on Hollywood and other stuff) but eventually gave up, because I realized, I knew too little about the subject.

I would definitely buy one!

@ssolie

Thanks for the update on shared objects, I didn't read the docs since the SDK update.

Hmm... It seems, that -fPIC shouldn't be able to explain the error, although I _am_ in fact using some shared objects. But I'm also linking with at least 3 other static libraries, that haven't been compiled with -fPIC, and they don't display any such problems... (The code in the static libs cannot possibly ever be called from within the shared objects, so -fPIC is not a problem.)

I'll try and get a hold of J?rg, although my previous attempts at reaching him have all been in vain. I'm guessing he is dead busy...

EDIT: The -fPIC theory is definitely dead, because the people mentioning it refer to it as a "-fPIC versus -fpic issue". Amiga doesn't have -fpic at all. All other suggested solutions I have seen so far have - as far as I can see - been referring to system specific issues... Drats!

I'm trying to link an executable against library that is about 180MB large. I get these errors:

main.cpp(.text+0x2c): relocation truncated to fit: R_PPC_PLTREL24 against symbol 'std::string::size() const' defined in .plt section in /SDK/newlib/lib/crtbegin.o


I can't find much help on google, but one thing that people mention is, that it is a size problem, and that it could be related to -fPIC. I'm not so tough on code generation issues, but I do know, that -fPIC is something used for generating shared objects. My 180MB size library is a static library and is compiled without -fPIC or -fpic. My only go at the moment is to add -fPIC to the makefile and recompile the entire library... It's just, it takes more than 12 hours to compile, so I wanted to hear, if somebody had a better guess before wasting more time on it .

EDIT: I just noticed, that all the error msgs refer to crtbegin.o. Could it be a problem with crtbegin.o?

@alfkil

Steven Solie stepped in and saved the queue-handler !

Thanks Steven

@nbache:
Gotta keep up with evolution

@thomas

No difference.