The Revenge of the Qt Demo Browser

Screenshot 1

;)

Well, it is by far the slowest web browsing experience I have ever had, but hey, it actually works...

EDIT: And by the way, the screenshot was done with another cool Qt app called "screengrab" (see the icon to the right in the dock).

Looks nice. What kinda browser is this?
And how usefull is qt really? Does it run decent speed?
Does it support hw acceleration?

...on what hardware, X1000?

@antique

It is a webkit browser. And well, here on my sam-flex 667 it is soooo sloooow, that I can easily go and make a cup of cofee before the page has loaded... So not very useful in it's current state. But hey, it has got a download manager and private browsing, so it is very feature complete ;).

QT apps run in aceptable speed on arm devices at 600 mhz (the same power as pentium 2 500 mhz). Why so slow on sam 667 mhz that is in the same range of power if not more?

because they are not hw accelereated

@alfkil

Very very interesting, you know we all looking forward to test it

@alfkil
Nice

"QT apps run in aceptable speed on arm devices at 600 mhz (the same power as pentium 2 500 mhz)."

They say Rasdberry pi @ 700Mhz has the CPU performance of 300MHz Pentium 2, so are you sure about "your" 600Mhz performance?

" Why so slow on sam 667 mhz that is in the same range of power if not more?
"

As said, HW acceleration. And some ARM chips have a working L2 (SAM440ep 667Mhz does not). (btw. pi uses L2 only for GPU)

(also my 600Mhz cell phone has ok web speed, surely because GPU helps and the code is heavily optimized by mainstream SW developers)

@thread

Well, given that Qt either uses miniGL or compositing for rendering, I would say that it actually is hw accellerated. I have a theory, that the slowness is due to some QImage/QPixmap conversion problems. Basically, what I have done so far is to always translate a QImage to 32-bit ARGB, which will take some time for large images. Still, Qt is just a hawk for resources, both CPU and memory wise, so it is never possible to achieve lightning speed.

As Alfkil said, the MiniGL or composition is used to render graphics, thus the rendering is actually hardware accelerated.

In my opinion Qt speed can be in conjunction with the abstraction layers used by it and disproportions between Qt and AmigaOS philosophy. The authors of Qt hadn't AmigaOS in mind when writing Qt, so the comparision to other devices and systems may be inappropriate.

What I mean is that Qt uses own classes for Timer, Keyboard events, Mouse events etc., while AmigaOS uses timer.device, input.device (window.class) etc. Proper transformation of Qt into AmigaOS philosophy may solve the problem. It might be useful to look what parts of Qt are requiring the most CPU or GPU load and improve the algorithms. I'd like to notice that the biggest problem with regular porting to AmigaOS (I'm not saying here about Qt) is to not look into the code of the program. Frequently this leads to speed problems.

It MAY require changing (adapting to AmigaOS components) some of the interiors of the Qt in order to get the good speed. I understand that we may need to avoid such solution (to not cause other problems).

I'd really like to dig into this problem (Qt speed), cause programming is my passion, and I've had speed problems for a long time with my programs for classic Amiga aswell. I solved many of these problems. :) I know C++ from some books and from the subject in University, but I'm not much experienced (not much practice).

I really appreciate Alfkil's work, because Qt seems to be large library and adapting it to Amiga is a great work.

@RNS_Amiga_Club

Hey, if you want to contribute, be my guest, I can add you to the repository on sourceforge, if you have an account there. :)

BUT please be aware, that everything with the Qt implementation is very delicate, it is very easy to screw things up. For one thing, DON'T MESS WITH THE EVENT HANDLING SYSTEM, it is pretty clear, that the Qt authors have spent a great deal of time fine tuning this part, and also I don't think there is anything to be gained in trying to change it, except for maybe breaking the entire library. If you want, you can look in "src/corelib/kernel/qeventdispatcher_amiga.cpp", but as I have said earlier, I just using a bare bones signal event system, and I don't think it can be optimized much (or at all).

When all that is said, any help would be highly appreciated, Qt is a mean big chunk of beast of a motherf*er, and handling it just one person can actually be quite stressfull.

EDIT: And by the way: Unless you have an X1000 (and even then), you should STRONGLY consider setting up a cross compiling environment for building Qt projects (I am assuming you have some kind of PC/mac stashed up somewhere). The speed of c++ compiling on AmigaOS 4.1 is horrendous...
If you want to set up a cross compiling environment for Qt, please contact me over chat or email, since it is a bit of a complicated process.

@Alfkil

All right, I've got account there but first I just look into the Qt code to see if I can be of any help. I'm rather good at analyzing the code, but I'll see if Qt isn't too big problem for me ;)

I've got a few projects at the moment (Amiga classic ones), but I'll try to find a time for Qt.

Regards
Robert

@Alfkil
Quote:
OK, but as I said I'll look into the code first to find the reasons (potential places) of speed issues on AmigaOS. Only if I understand the code and find these places I will begin to fix speed problems.

As of compiling C++ projects on AmigaOS4.1 it's not that big problem for me (even though I've got loaned Sam440ep). But if I need to use cross-compiling I'll contact you of course.

I guess that AmigaOS developers are helping you with the project in some way?

There is another problem on our QT implementation. As far i remember the "Broken zone" redraw is not implemented and so the bitmap is always redraw entirely.. so imagine how slow is.. i've tried to take a look in the past but QT is a big animal..

Nice!! Keep it up alfkiller!

@afxgroup

False. If you are refering to the "backing store" functionality, it is turned on and works.

Ah ok.. in the past i remember that the entire page was redraw.. so good to hear.. at this point a good profiler would help..

afxgroup wrote:

Quote:

I'd agree but I've also found the technique listed at What can I use to profile C++ code in Linux? works really well often enough, I was sceptical till I tried it and it really works as quick solution.

Another teaser... Here it is db101 debugging the Qt Demo Browser. 400mb of stabs info at your fingertips!

Screenshot 2