Text rendering speed (Qt vs. native)

	Bottom Previous Topic Next Topic
Register To Post

(1) 2 3 »

elfpipe

Posted on: 2012/2/4 12:42 #1

Just can't stay away

So I have done two small test apps to test the speed of text rendering in Qt versus graphics.library. It is just a loop that renders "Hello world!" 4000 times and a QTime to record the time elapsed.

Result (in miliseconds):

graphics.library: 551
Qt (freetype/opengl): 41188

Can I depend on this result? Can it really be true, that rendering a string with graphics.library takes only 1/4 milisecond??

Here is my code for the native test:


#include <proto/exec.h>

#include <proto/graphics.h>

#include <proto/intuition.h>



#include <QApplication>

#include <QTime>



#include <qdebug.h>



#include <unistd.h>



int main(int argc, char **argv)

{

    QApplication app(argc, argv);



    struct Window *win;



    win = IIntuition->OpenWindowTags(NULL,

                        WA_Left,        0,

                        WA_Top,            20,

                        WA_Width,        100,

                        WA_Height,        20,

                        //WA_Borderless,    TRUE,

                        WA_Activate,    TRUE,

                        WA_IDCMP,        IDCMP_MOUSEMOVE |

                                        IDCMP_RAWKEY,

                        WA_GimmeZeroZero, TRUE,

                        WA_ReportMouse,    TRUE,

                        TAG_DONE,        NULL

                        );

    if (win==NULL)

    {

        printf("Failed to open window!\n");

        return -1;

    }

    QTime timer;

    timer.start();



    for(int i=0; i<4000; i++)

    {

        IGraphics->Move(win->RPort, 0, 10);

        IGraphics->Text(win->RPort, "Hello World!", 12);

    }

    

    qDebug() << "miliseconds to finish: " << timer.elapsed();

    sleep(5);

    IIntuition->CloseWindow(win);



    return app.exec();

}

...and here is the Qt code:


#include <QApplication>

#include <QTime>

#include <QTimer>

#include <QLabel>

#include <QPainter>

#include <QPixmap>



#include <qdebug.h>





int main(int argc, char **argv)

{

    QApplication app(argc, argv);



    QLabel label;

    label.resize(100,20);

    QPixmap pm(100,20);

    pm.fill(Qt::white);

    label.setPixmap(pm);

    label.show();

    

    QTime timer;

    timer.start();



    QPainter p;

    for(int i=0; i<4000; i++)

    {

        p.begin(&pm);

        p.drawText(QRect(0, 0, 100, 20), Qt::AlignLeft, "Hello world!");

        p.end();

        label.setPixmap(pm);

    }

    

    qDebug() << "miliseconds to finish: " << timer.elapsed();

    return app.exec();

}

Wanderer

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/4 13:10 #2

Just popping in

The result from graphics looks realistic. QT seems very slow.
Do both render their text "blocky", mean with a solid background color? That affects the speed a lot, if the text is rendered transparently.
Also, the font of course has an impact.

Thematic

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/4 15:06 #3

Quite a regular

A couple of hundred thousand cycles for the native code seems plausible enough. Consider "A500": 30 ms?

elfpipe

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/4 15:27 #4

Just can't stay away

...so I just remembered, that when painting to a QPixmap, the raster engine (CPU rendering) is used, which in part explains the lousy performance of the Qt example. So I changed the code to paint into a QWidget instead, but it still performs quite slow:

Qt (QWidget/opengl): 25605 miliseconds


#include <QApplication>

#include <QTime>

#include <QTimer>

#include <QPainter>



#include <qdebug.h>



class MyWidget : public QWidget

{

    Q_OBJECT

public:

    MyWidget(QWidget *parent = 0)

        : QWidget(parent)

    {

        resize(100, 20);

        i = 0;

    }

protected:

    void paintEvent(QPaintEvent *)

    {

        QPainter p(this);

        p.drawText(QRect(0, 0, 100, 20), Qt::AlignLeft, "Hello world!");

        p.end();

    }

public slots:

    void timerFired()

    {

        i++;

        if(i == 4000)

            close();

        else

            update();

    }

private:

    int i;

};



int main(int argc, char **argv)

{

    QApplication app(argc, argv);

    MyWidget widget;



    QTime time;

    QTimer timer;

    QObject::connect(&timer, SIGNAL(timeout()), &widget, SLOT(timerFired()));

    timer.start(1);

    time.start();



    widget.show();

    int ret = app.exec();

    qDebug() << "miliseconds to finish: " << time.elapsed();

    return ret;

}



#include "qtfont.moc"

I'm having a hard time determining, if this is due to bad coding of the Qt opengl module, missing features or just crappy minigl implementation. Any suggestions??

kas1e

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/4 16:13 #5

Home away from home

@alfkil
Quote:

Any suggestions??

Maybe will make a sense to create a plain opengl example which will do some text rendering by the same logic (to exclude QT). I.e. 2 example: one with default opengl functions for text rendering, and another with freetype. So you can see from where slowdowns come.

Join us to improve dopus5!
AmigaOS4 on youtube

broadblues

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/4 16:35 #6

Home away from home

I think rendering text with minigl (or any GL for that matter) is a much slower process. It genarally invldes creating textures then mapping them onto rectangles, whereas graphics.libray just draws the text

My port Blender usues graphics.library to render it's text, orignally as a work arround to a minigl bug, but once the bug was fixed I kept it in as it's faster than the old freetype based texture mapping code. And it looks better too, though I think it improves with later versions of freetype on other systems.

Blender For OS4.x : Blues : Walker Broad

afxgroup

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/4 17:40 #7

Amigans Defender

As i told you on skype there is a QT implementation that doesn't redraw the entire image every time but only the damaged zones. And actually our implementation use the first method.
It is possible that the second implementation will speed up a lot the whole draw process

i'm really tired...

nbache

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/4 23:42 #8

Just can't stay away

Are you using a bitmap font or a TT font? Could Qt maybe be assuming a vector font in all cases, while graphics.library can take advantage of the native bitmap font? If so, using a TT font in both cases might even the odds a bit.

And what about smoothing/anti-aliasing?

Finally, maybe it would be interesting to see if the difference changes by making the string variable, e.g. by rendering a random string in each iteration, or just a counter or something. Just in case some caching/reuse is happening somewhere.

Just some thoughts without really knowing much about either implementation.

Best regards,

Niels

elfpipe

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/5 13:51 #9

Just can't stay away

@broadblues

I think you are on to something here, it seems that Qt's way of rendering text use these steps:

1) cache the glyphs used by the text
2) create a alpha texture out of the cached glyph images for the specific string
3) render to screen using the texture and the active pen color/texture etc

This process seems to be quite slow.

In any case, could you repost the link to the Blender code, so I can see if it is possible at all to do smth similar in Qt??

@kas1e

I might try and follow your suggestion in the meantime just of lack of better things to do

@afxgroup

You are talking about QBackingStore, right? I still am not entirely sure how this works, I mean, obviously it uses some way of recording "damaged" areas of a widget (dirtyRegion()) and only drawing those, but I remember there being some problems with QScintilla, that I failed to solve and that had something to do with the QBackingStore implementation.

@nbache

I tried to use a truetype font for the native test, and the result appr. doubled:

Native (truetype font size 20): 1017 miliseconds

But still it is 1 to 25, which is a lot of difference! I don't know if the native test uses anti-aliasing...?

Chris

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/5 14:22 #10

Amigans Defender

Quote:

alfkil wrote:
@afxgroup

You are talking about QBackingStore, right? I still am not entirely sure how this works, I mean, obviously it uses some way of recording "damaged" areas of a widget (dirtyRegion()) and only drawing those, but I remember there being some problems with QScintilla, that I failed to solve and that had something to do with the QBackingStore implementation.

QScintilla was redrawing the same text all the way down the page if one of the buffering options was enabled.

Quote:

@nbache

I tried to use a truetype font for the native test, and the result appr. doubled:

Native (truetype font size 20): 1017 miliseconds

But still it is 1 to 25, which is a lot of difference! I don't know if the native test uses anti-aliasing...?

The native should use anti-aliasing by default, unless you've switched it off (which you can do on a font-by-font basis, or globally I think). It should be obvious from the result whether it is anti-aliased or not

broadblues

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/5 17:29 #11

Home away from home

@alfkil

The blender code is at os4depot.net

http://os4depot.net/share/graphics/raytrace/blender-src.tar.bz2

Look for blender-src/intern/bmfont/intern/BMF_BitmapFont.cpp

some of the structures I refere to are define in the

blender-src/intern/Ghost/ directories

I doubt it you'll be able to make a one to one copy as this is blender custom lib but it will show| you how I adapted it.

The original code is still in the archive
IIRC

Blender For OS4.x : Blues : Walker Broad

elfpipe

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/6 10:15 #12

Just can't stay away

@broadblues

Thanks I will take a look at it!

Progress report: I found out, that there is a problem with QPixmaps and the lack of context sharing: When a texture asociated with a QPixmap is not bound to the current context, Qt translates it into a QImage and uses the Raster (CPU) engine to transform the the image before rendering. Both of these steps are quite slow.

I have done a quick test turning on my own version of context "sharing", and especially the (non-native) menus are very much quicker in this state. Unfortunately this also means, that the graphics are "garbled", because all the different windows are rendered into the same Bitmap. But nevertheless it shows, that the speed problems with Qt can be solved once we (*sigh*) have a proper MESA implementation.

elfpipe

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/6 13:44 #13

Just can't stay away

A few more results:

I dug out the preliminary native rendering engine that I did in the beginning before switching to GL rendering. A few very interesting results emerge:

Qt-native(freetype): 105420 miliseconds (!)
Qt-raw(graphics.lib): 16430 - | -

So freetype is in general very, very slow. But the interesting part is, that the Qt using graphics library scores so badly compared to the just-native rendering (about 16 times slower).

kas1e

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/6 14:10 #14

Home away from home

@alkfil
So, qt-raw now mean no opengl, and even now its slower in 16 times! Maybe some blocking / wrong timing / forgotted sendmsg / recvmsg ? I remember when i work on warp3d stuff (what mean heavy graphics rendering as well), i for the begining all the time have big slowdowns and 100% cpu loading ,what i can't understand , and only after i restrucure the loops (recv/send msg) , and i added to main loops something like that: WaitPort(window->UserPort); I fix all the speed problems.

Not sure that its related of course, just some stuff to think about. But 16 times slowdown when its only add one api layer over another one (even without opengl) seems like too much indeed.

Join us to improve dopus5!
AmigaOS4 on youtube

elfpipe

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/6 20:52 #15

Just can't stay away

@kas1e

You are definitely right, it is too much. And I have one thing to say: I wish we had a working profiler... :-/

Elwood

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/7 13:24 #16

Just can't stay away

Maybe not usable with libraries, but we have hieronymus

Philippe 'Elwood' FERRUCCI
Sam460ex 1.10 Ghz
http://elwoodb.free.fr

kas1e

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/7 14:09 #17

Home away from home

@Elwood
hieronymus is buggy. Its totally lockup the pegasos2 when you tryint to use it. I do not remember, but it works only on some kind of machines (or only on a1, or only on sams). I write to author about some time ago, but in latest SDK hieronymus is still lockup peg2.

@alfkil
About what i thnik lately, its about somekind of addon/plugin for Valgrind (linux), so we can somehow profiling amigaos4 bins on the linux. As our binary format already "elf" , it can be easy to add some necessary code to valgrind to have support.

Of course we can't use all the valgrind tools, and we even can't load (i think) amigaos4 binary to it to have ability to use all the valgrind parts, but for sure we can reuse some profiling parts. Have you interest to have a look at this ? At least we have cross-compilers, so all is here already ..

Edited by kas1e on 2012/2/8 8:49:55

Join us to improve dopus5!
AmigaOS4 on youtube

elfpipe

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/8 15:03 #18

Just can't stay away

@kas1e

Actually I don't know much about the subject, how does hironymous work? Does it interpret the code, or does it attach to a running process or...? What could the reason for it not working be?

kas1e

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/8 15:20 #19

Home away from home

@alfkil

Quote:

Actually I don't know much about the subject, how does hironymous work? Does it interpret the code, or does it attach to a running process or...?

I personally have no succes with it on my peg2, so can't give normal description , but i have back in past some chat on os4depot (in comments) with Corto (author): here. Necessary part are:

Quote:

You just have to run the profiler and wait for the given duration. Then it displays a list of programs and functions as well for programs compiled in debug mode / not stripped.
Maybe the result you get is not very interesting but if you develop an heavy application, you can find slow functions, that have the greater number of hits is the detailed report.
In fact, it is statistical profiling, we periodically look at which program is running and even which function. At the end, the more occurences you have in a function, the more time is spent in, statistically.

Maybe on SAM it will works fine, need to check of course. But if you will in real interst about, then i am sure Corto can provide you details with all the stuff :)

But if only we can somehow adapt valgrind to profile amigaos4 bins, that can be a lot better. If you do not know what valgrind is: check this out. Valgrind already have support for PPC32/Linux (so big endianed elfs already can be handled), so it can help a bit. I even not mean native amigaos4 version, but even linux one, which will have support for os4 bins (if that possible of course to do at all in real timeline). All the unix developers use valgrind when they want to do profiling and bug-hunting work.

SBA even works on it back in the past, and there is some quote from him:

Quote:

I have tried to port valgrind myself a while ago. As it seemed to be a very difficult task (lot of #ifdef linux inside the code), I decided to start an own valgrind implementation, which is based on libvex, which is the core of valgrind, and works out of the box on amiga OS. Libvex is the part that is responsible to convert the binary code to the IR code and vice versa. I made good progress (it is possible to detect bugs for a quite limited number of instructions) but I couldn't do more than that (so a lot of work is still ahead) due to some other priorities.

If anyone is interested in helping me out please contact me by email. I can easily prepare the code and upload it to adtools project on sourceforge then, where the development should ultimately should take place.

Join us to improve dopus5!
AmigaOS4 on youtube

elfpipe

Re: Text rendering speed (Qt vs. native)

Posted on: 2012/2/10 18:27 #20

Just can't stay away

Quote:

The native should use anti-aliasing by default, unless you've switched it off (which you can do on a font-by-font basis, or globally I think). It should be obvious from the result whether it is anti-aliased or not.

Correction: If it is a TTF, then it uses antialiasing by default. If it is a bitmap font, then not.

Register To Post	(1) 2 3 »
	Top Previous Topic Next Topic

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