Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
130 user(s) are online (63 user(s) are browsing Forums)

Members: 2
Guests: 128

pvanni, blmara, more...

Headlines

 
  Register To Post  

QT Native question
Just popping in
Just popping in


See User information
Hello!

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?

Go to top
Re: QT Native question
Home away from home
Home away from home


See User information
No doubt, any help is surely apprecied, If you like to look at the code you can point your mouse here:

http://sourceforge.net/projects/qtamigaosnative/

Go to top
Re: QT Native question
Just popping in
Just popping in


See User information
Thanks for the link!

Go to top
Re: QT Native question
Just can't stay away
Just can't stay away


See User information
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. :)

Go to top
Re: QT Native question
Amigans Defender
Amigans Defender


See User information
Quote:

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.

Go to top
Re: QT Native question
Home away from home
Home away from home


See User information
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!).

Author of the PortablE programming language.
Go to top
Re: QT Native question
Just popping in
Just popping in


See User information
Quote:
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?

Go to top
Re: QT Native question
Just can't stay away
Just can't stay away


See User information
@RNS-Amiga-Club

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

Go to top
Re: QT Native question
Amigans Defender
Amigans Defender


See User information
Quote:

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.

Go to top
Re: QT Native question
Home away from home
Home away from home


See User information
@alfkil Quote:
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.

Author of the PortablE programming language.
Go to top
Re: QT Native question
Just popping in
Just popping in


See User information
Well, at list I would add support for plain images, which could be simply translated into IFF.

Go to top
Re: QT Native question
Home away from home
Home away from home


See User information
@virgola
I would rather see text support now, rather than the "IFF+text" in some months or never. More complex stuff can always be added later.

EDIT: Well, by "IFF" I mean pictures, i.e. "ILBM".


Edited by ChrisH on 2012/10/26 9:10:32
Author of the PortablE programming language.
Go to top
Re: QT Native question
Home away from home
Home away from home


See User information
@ChrisH

Quote:

I would rather see text support now, rather than the "IFF+text" in some months or never. More complex stuff can always be added later.


All data is IFF in the clipboard, including text. Building a FTXT shouldn't be that difficult though.


Go to top

  Register To Post

 




Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project