First I'd like to send greets to Alfkil for his work on Qt. You're doing great job!
Second I'd like to ask, what is the problem in general with speed of Qt apps ported to AmigaOS 4 using Alfkil's native Qt port? Maybe it requires discussion to solve the problem with the speed of Qt apps? I posses some knowledge of native programming for Amiga and AmigaOS (been programming for it since years) and I'm offering my help to get Qt faster on AmigaOS 4.
It couldn't be that Qt on similiar (in terms of performance) platform (for example Windows) is running fast, but on AmigaOS 4 it is running slow. What is the reason?
First of all sorry for my lengthy absence from the Amiga scene and Qt endevours. I have been moving to another city and been quite busy with music (my real profession).
With regards to Qt speed, I have run some timing tests, and it seems, that the biggest bulk is inside the event driven machinery at the core of Qt. This is not something I want to mess around with a lot, since I believe, that the people who put it there put it there for good reason.
There are some issues with rendering (OpenGL or native compositing), it seems that the Qt authors put in some nifty speedup things using OpenGL framebuffer objects (amongst other things), which is not supported by our minigl.
With regards to Qt speed on other platforms with similarly performing hw, I have no data, since I got rid of all my shitty lowperforming PC equipment years ago. :)
alfkil wrote: First of all sorry for my lengthy absence from the Amiga scene and Qt endevours. I have been moving to another city and been quite busy with music (my real profession).
Welcome back!
Quote:
With regards to Qt speed on other platforms with similarly performing hw, I have no data, since I got rid of all my shitty lowperforming PC equipment years ago. :)
I actually think the speed of Qt under OS4 is OK when native fonts and graphics are enabled. JuffEd is quite usable now, I'd probably happily use it as my code editor if the copy/paste between Qt and other applications worked (hint, hint)
I'm still waiting for QtWebKit too, have a couple of things queued up to port that need it. One of them is likely to need system tray (ie. application docky) and notifications support though.
How does QT compare with native compositing vs MiniGL going via Wa*z*p3D using compositing? I am planning to try this myself (eventually - when I find the time!).
With regards to Qt speed, I have run some timing tests, and it seems, that the biggest bulk is inside the event driven machinery at the core of Qt. This is not something I want to mess around with a lot, since I believe, that the people who put it there put it there for good reason.
I think that if the Event Handling of Qt is the reason of slow speed we must think about doing proper transformation of Qt events -> into -> IDCMP Events of Intuition Windows. The ReplyMsg() for example must be called immediately after receiving message with GetMsg(). Such transformation which doesn't produce system overhead on AmigaOS is quite easy to do. And we don't need to change anything in the Qt core. What do you guys think about it?
What I meant to say is, that the bulk of the performance in Qt lies in the *signal* handling system. There is nothing wrong with how Qt administers IDCMP events, the code as it is now is very snappy at copying the needed data from the IDCMP and handling it. Signals on the other hand is a special Qt thing, where classes can make other classes perform a certain action under certain circumstances using a signal (with the 'emit' command) or connect certain actions using slots (like 'connect(mybutton, SIGNAL(clicked()), myrequesterobj, SLOT(dosomefunkyshit))'). This requires a quite complicated set of preprocessor commands and meta classes and a special Qt preprocessor command (called 'moc' for 'meta-object-creator', I think). This creates a fair amount of overhead, which is just needed to make Qt function.
EDIT: By the way, I have built and used libQtWebKit, but the problem is, that there is some malfunction with javascript, which I have tried to identify without luck.
EDIT: I will try and do some integration of cliboard data with the native clipboard. The problem is of course, that the Qt cliboard handler is able to handle a vast amount of different kinds of data, and I am not sure how to translate it into IFF (which is what the Amiga clipboard needs, am I correct??).
alfkil wrote: EDIT: By the way, I have built and used libQtWebKit, but the problem is, that there is some malfunction with javascript, which I have tried to identify without luck.
I thought afxgroup had fixed that? Must have been something else.
Quote:
EDIT: I will try and do some integration of cliboard data with the native clipboard. The problem is of course, that the Qt cliboard handler is able to handle a vast amount of different kinds of data, and I am not sure how to translate it into IFF (which is what the Amiga clipboard needs, am I correct??).
Yes, it needs to be IFF, so you'll need to translate into IFF where you can (text and graphics should be easy). I'd suggest creating a new chunk/FORM for Qt clipboard data that can't be expressed in IFF, which you can append to all IFF data you put on the clipboard. That way Qt can check for that chunk/FORM and use that data if it is present, thereby not losing any information. Everything else will use the translated/simplified version.
The problem is of course, that the Qt cliboard handler is able to handle a vast amount of different kinds of data, and I am not sure how to translate it
How about you just translate plain text, and ignore anything else? Text is by far the most common case.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
