Trolltech has released Qt 4.1. The first feature release since Qt 4.0 includes new features which will make it into KDE 4 such as integrated support for rendering scalable vector graphics (SVG) drawings and animations, a PDF backend to the Qt printing system and a lightweight unit testing framework. Qt Designer has been updated, OpenGL support has been improved and SOCKS5 support has been added. Their 4.1.0 changes file has the full details. Get your copy from the X11 download page or from qt-copy in KDE's SVN.

Qt has Arthur, it works today and there is simply no reason to use Cairo. Despite much hype Cairo and Glitz will take some time before they are usable. As needs arise Arthur might use Cairo as a backend at some point, but that really depends on whether there's any point at all.

Amanith rendering layer is the best in term of features and speed (and it's 100% crossplatform).
The incoming version will be the first library that will support in hw all 24 Porter-Duff compositing modes, 15 of them will be available also on hw that hasn't got pixel shaders.

> In a kde mailinglist I read a comment from a kde dev saying that Qt4.0
> is painting *much* slower than Qt3... :-(

This is wrong. Most operations are faster in Qt 4, some - like anti-aliased drawing - are even infinitely faster. Just run a Qt 4 program and compare its performance with a counterpart using Qt 3, and judge for yourself.

> And what about the backingstore technology...?

It's in 4.1.

> Does that mean konqueror's tabwidget (and kde apps in general) will not
> flicker anymore when opening a new tab?

No, this has nothing to do with backingstore. Switching tabs is flicker free since Qt 4.0, thanks to an improved recursive setUpdatesEnabled() that implicitely sets the system background to None (so that your X-Server doesn't fill the newly created widgets prior to Qt being able to draw something).

Hopefully 4.2 will abandon native widgets (read: X Windows) completely, then even resizing and moving widgets around will be completely solid.

> This is wrong. Most operations are faster in Qt 4, some - like anti-aliased
> drawing - are even infinitely faster. Just run a Qt 4 program and compare its
> performance with a counterpart using Qt 3, and judge for yourself.

you are talking about something completely different than the person you are replying to.

you're talking about things like scrolling text being alphablended with a translucent overlay that is performing transformations on the text.

they were talking about painting things to screen, and in particular widgets.

very different things. the former is always expensive and slow. the trick is to move it to graphics hardware that has nothing better to do than throw cycles at such things and is optimized for those processes, and then it's nice and fast.

you can blame the state of X.org for the current annoyances. we're only now starting to get proper drivers for a few cards, powerful (and stable) X extensions and the client-side software that uses them to make the more complex tricks like antialiasing and compositing feel fast.

> they were talking about painting things to screen, and in particular
> widgets.

I don't think so.
The last time I tried Qt 4 was something like Qt 4.0 beta.
Yesterday I compiled Qt 4.1.
Demo apps start really fast :-) And painting has become much faster than in the pre-4 days :-)

But still, it's significantly slower than Qt 3.

Example: start Qt 4 designer in "Docked Window" user interface mode. Create a new "mainwindow". Resize this mainwindow inside designer. Awfully slow. It seems to block X refreshing for all other apps while it is being resized. Xosview "freezes" while resizing this mainwindow inside designer.
Now resize the designer mainwindow. On both my boxes, AMD XP 2000+ and Intel P3/450 there is a visible delay. If I release the mouse button, then for a short moment the window background color is visible, and after maybe 0.1 .. 0.5 s the designer window is repainted.
This is *really* slow and it flickers.
And I really consider my box fast enough to repaint a window with a lot of widgets fast enough (XP 2000+, 512 MB, Geforce).

Alex

P.S. the arthur "effect" demos run slow and take 100% CPU. This is not what I'm talking about above. (while I still that it should be possible to do these things much faster)

This is not painting speed, this is the cost of indirect painting (painting to an offscreen buffer and then blitting the result on the screen). Some X-Servers are awfully slow doing this. Just blitting a pixmap on the screen without any painting whatsoever will give you a frame rate that windows users or game programmers only laugh at. X currently sucks in that respect.

Your CPU speed doesn't mean much here, it's your graphics card, and how it is supported by the X-Server. Or rather how it's not supported. Maybe Qt should come with a little test program that blits two pixmaps on the screen, in fastest possible speed using render composite. That would show you the maximum theoretical framerate that a toolkit can achieve on your setup if its drawing speed was infinite. The result would likely be shocking to you.

Comparing Qt4's designer with Qt3 is also missleading wrt "painting" speed, because Qt4 makes quite a bit of use of alpha effects (like the tinting effect when container widgets are highlighted), and child widgets are composed. Plus there was really suboptimal code in designer that painted the little dots. In Qt 4.0.0 most of the time was spent drawing those dots, don't remember to what degree that was fixed in the final 4.1.0 packages.

Please don't spread rumours about "painting being slow" when you basically mean "resizing a form in designer exposes some background". That background is painted by the X-Server when an X Window is reszied, before the very same X-Server finally blits the ready-made contents on it. Qt's painting is fast, the problem is to get the painted pixels on the actual screen. And that's out of the control of the GUI toolkit.

The same applies to the demos.

One big step forward that we can do is ditching the concept of native widgets (read: one X Window per QWidget) altogether. This would allow us to do one blit only when a window is resized, as opposed to many blits. This would also fix the problem of exposing some background when resizing child widgets.

FYI: Qt3 painted directly on the screen, like one had to do in the eighties and early ninetees. The costs of doing that are: no child widget composition (required for modern and cool styles), and flicker. Nobody wants that anymore in 2005. Until the X-Servers finally catch up with modern hardware, we will have to live with slower resizing of windows. Good news: users never do that anyway, at most they hit the maximize button.

I recompiled Qt 4.1 with -no-xrender, and now it behaves noticeable better.
X isn't "blocked" anymore, I can resize the mainwindow in designer as I'm used to.

> Please don't spread rumours about "painting being slow" when you basically
> mean "resizing a form in designer exposes some background". That background
> is painted by the X-Server when an X Window is reszied, before the very same
> X-Server finally blits the ready-made contents on it. Qt's painting is fast,
> the problem is to get the painted pixels on the actual screen.

Well, I'm not sure I agree completely here.
I mean, X is one of the main targets of Qt, maybe *the* main target. So when designing a toolkit for X, the characteristics of X should be taken into account.
As a user I don't care why something feels slow, it doesn't matter whether Qt draws blazingly fast and X is too slow or whether Qt is slow and X is fast enough. In the end I only notice that there is something slow.

> And that's out of the control of the GUI toolkit.

Well, not completely. The toolkit can't control the speed of X, but it can use X in different ways. It can use X in a way so that the end result is slow, and it can use X in a way optimized for X, so that the (eventual) performance problems of X are not that much visible.

I compiled Qt 4.1 yesterday, and all I can say is that flicker is greatly reduced in this release. For comparing, I fired up the qt-assistant from
Qt 3.3.5 and from Qt 4.1. Then I created some tabs, each holding documentation of different classes. Now, by switching from tab to tab you can see no more
flicker with the 4.1 version, whereas with the 3.3 you can.

For X11 where all printing is directly to postscript, this function will always return a one item list containing only the postscript resolution, i.e., 72 (72 dpi ... ).

int QFontMetrics::width ( QChar ch ) const

Returns the logical width of character ch in pixels.

I have to wonder, is it possible that the Trolls just don't get it? If you compute the font metrics at 72 DPI and then print it at 600 DPI, no wonder it looks BAD.

On Windows, the printer resolution list will contain numbers like 300, 600 that it gets from the printer driver. In that context, the resolution of PostScript is INFINITY.

[Another small problem is that not all printers have square resolution.]

OTOH, if we are just using the DPI as logical units it would work with 72 DPI except for the type of "QFontMetrics::width". "int" will not work, it needs to be "float" for X11. But, that won't work cross platform -- or will it? How does Redmond work?

The place to start appears to be with: "enum QPrinter::PrinterMode". This is where we should have the three modes:

ScreenResolution
PrinterResolution
PostScript

But, this has already been hacked so what appears to be needed is that: "HighResolution" should always refer to the resolution of the printer (we need this for Windows compatability and to make PDFs), and PostScript should be added as "3". The problem is that using this will break every function which returns the size of any font metric in pixels.

I don't have any good answers -- I can only note that they appear to have used the DOS/Windows paradigm of knowing the printer resolution and painted themselves into a corner. An interim solution would be for X11 to also use the Windows paradigm of using the printer resolution for WYSIWYG layout. But, this would require changes in KPrint so that it would use a PPD file for all printing. This would not be an ideal solution since the printing would still be a little off, but it would be a great improvement -- at 1200 DPI, you probably wouldn't be able to tell the difference.

They do get it. If you take a closer look at Qt 4 you'll discover that

a) there is also a QFontMetricsF class that gives you (as a developer) floating point precision for simple self-made text layouting.

b) /all/ the internal text layouting in Qt is using floating point precision.
Actually internally 26.6 fixed point is used, just like Freetype, but that's good enough and in the API of QFontMetricsF, QTextLayout and in the higher level Scribe classes you (as a developer) see qreal.

c) when laying out text you can disable the screen hinting and use linear scaled design font metrics for a nice preview on the screen that matches
(line/page break wise) exactly what you also get on a high resolution printer.

The last point actually still needs tuning for nicer screen output, but it does not fall into your "Trolls don't get it" category.

By WYSIWYG, I mean true WYSIWYG. Not Windows style which is just font metrics hinted at the printer resolution.

Yes, there is also a QFontMetricsF class (should have read more but ... ), but using that in place of the "int" typed class will require large changes in code. After thinking about this, it would appear that you could use the "float" type for all layout in KDE and this would solve part of the problem. It still has cross platform issues since X11 code could be used on Windows but Windows code might not work on X11 if it used the "int" class.

Freetype expresses the size of the glyphs in 64ths of a pixel -- that is 26,6 fixed point binary. But, that is for _hinted_ font metrics.

However, I have not been able to find where in Qt that you would choose unhinted font metrics. If you choose "QPrinter::HighResolution" you have not selected unhinted; it appears that on X11 that you have selected 600 DPI with hinting at that resolution -- at least it appears to me that "QPrinter::PrinterMode" would be what you would use to choose unhinted, and there is no PostScript option.

True WYSIWYG requires "metrics in design font units", and without further information, I don't see how you can do that. And if you are just doing 600 DPI then the "float" class is not needed. Even if you were using 7200 DPI, integer arithmetic would be faster than float unless you had to use if for scaled font design units.

Perhaps there is a Qt tutorial somewhere that might explain this in more detail.

-- snip
>Yes, there is also a QFontMetricsF class (should have read more but ... ), but using that in place of the "int" typed class will require large changes in code. After thinking about this, it would appear that you could use the "float" type for all layout in KDE and this would solve part of the problem. It still has cross platform issues since X11 code could be used on Windows but Windows code might not work on X11 if it used the "int" class.
-- snip

There is no portability issue using floating point precision instead of integer precision for text layouting. Not if you also do the glyph positioning in the toolkit, so the same precision is used across all platforms, which is what Qt does.

-- snip
>Freetype expresses the size of the glyphs in 64ths of a pixel -- that is 26,6 fixed point binary. But, that is for _hinted_ font metrics.
-- snip

Right, it uses 16.16 for linear(Hori|Vert)Advance, which Qt reduces to 26.6. But that should be by far precise enough for decent glyph positioning on your 600 dpi printer.

-- snip
>However, I have not been able to find where in Qt that you would choose unhinted font metrics.
-- snip

People doing their own high-level text layouting (such as for example KWord might want to do when ported to Qt 4) should use QTextLayout. With QTextLayout it is possible to enable the use of design font metrics by setting the 'useDesignMetrics' property in the associated QTextOption object. Everyone else is free to use the high-level Scribe classes and enable the use of font design metrics there using QTextDocument's useDesignMetrics property.

-- snip
> Right, it uses 16.16 for linear(Hori|Vert)Advance, which Qt reduces to 26.6. But that should be by far precise enough for decent glyph positioning on your 600 dpi printer.
-- snip

Maybe that part should be clarified. I meant it should be good enough for doing text layout in low screen resolution (~96 DPI) but with subpixel positioning for decent output on a higher resolution device then. With a factor 64 of added precision you get an effective resolution of ~6000 DPI.

The portability issue does exist between *NIX and Windows. If a large OO Writer document is moved from Windows to *NIX and the compatibility mode in OO isn't used, the document will become noticeably shorter because hinting isn't used to compute the line lengths in *NIX. I think that the same thing might happen with Qt based wordprocessors, but only if the QFontMetricsF class functions returned non-integer values for unhinted glyphs.

> Right, it uses 16.16 for linear(Hori|Vert)Advance, which Qt reduces to 26.6.

Actually, IIUC, FreeType2 supplies these more precise figures but it doesn't actually use them to render the _hinted_ glyphs. They are supplied so that the application can more precisely compute the layout. This could be used to support a mode where the screen image was hinted but the printed metrics were correctly based on unhinted glyph dimension. WordPerfect can do something like this and it isn't really what I would call a feature. Real WYSIWYG is much better.

> But that should be by far precise enough for decent glyph positioning on your
> 600 dpi printer.

Perhaps although most office level lasers now start at 1200 DPI and inkjets are 1440 DPI. But, this isn't WYSIWYG, it is 600 DPI hinted fonts. As I said elsewhere, perhaps 7200 DPI hinted fonts would be sufficient in all cases, but I don't see 600 DPI as sufficient.

So, I take issue with the choice of 600 DPI as the ONLY value for "HighResolution" with X11. This is OK as a default but it should be settable.

> People doing their own high-level text layouting (such as for example KWord
> might want to do when ported to Qt 4) should use QTextLayout.

So, this is what I am taking issue with. You shouldn't have to do this (use completely different code) just to get true WYSIWYG. This should be possible using the "QFontMetricsF class" and setting the "PrinterMode" to "PostScript" (i.e. unhinted fonts).

-- snip
> > But that should be by far precise enough for decent glyph positioning on your
> > 600 dpi printer.

> Perhaps although most office level lasers now start at 1200 DPI and inkjets are 1440 DPI. But, this isn't WYSIWYG, it is 600 DPI hinted fonts. As I said elsewhere, perhaps 7200 DPI hinted fonts would be sufficient in all cases, but I don't see 600 DPI as sufficient.

-- snip

Actually QPrinter::HighResolution gives you 1200 DPI.

-- snip
> So, this is what I am taking issue with. You shouldn't have to do this (use completely different code) just to get true WYSIWYG. This should be possible using the "QFontMetricsF class" and setting the "PrinterMode" to "PostScript" (i.e. unhinted fonts).
-- snip

We are almost in agreement James :). We agree that it should be transparent to the programmer. However I argue that it is easier to default to screen dimensions when printing, because that's exactly what you also see when you debug/develop on the screen. For printing a higher resolution should of course be used, transparently to the programmer by simply scaling the QPainter. And for WYSIWYG the text should be layouted and positioned only /once/, in screen dimension but with a precision high enough to give nice output on a higher resolution printer.

Default to a 7200 DPI resolution for everything would be an insane waste of resources and it is harder to understand for developers because it significantly differs from what you see on the screen (ever debugged with xmag? :). Plus 99% of the time you do want your text hinted to low-resolution screen output, because 99% of the time text is displayed solely for screen output: Text in menus, text in web pages, text in tooltips, text in labels, etc. That is the common case and that is why text is hinted by default. Those few applications that need WYSIWYG can easily set the one or other property on an object :)

Anyway, I have to run now to catch my plane to my hometown for christmas vacation. Merry christmas everyone on the dot and in the KDE community :)

I note that as I have said before that you need to be able to choose between: "Screen", "DPI", and "FontMetrics" resolution depending on what you are doing.

Obviously "Screen" is best for viewing on the screen. To emulate Windows or to make a PDF, you would normally use "DPI" but for true WYSIWYG (e.g. something to be sent out to be printed) you need to be able to choose "FontMetrics".

It would be a great feature if you could choose these three modes and not have to change any code to do it. This would require using "float" for the layout and would (therefore) be a little slower -- but most machines have many times as much power as they need for wordprocessing.

I don't see how 7200 DPI for layout would be a problem. It shouldn't add overhead since it could all still be done with 32 bit integers and integer arithmetic.

And Merry Christmas to everyone. I got the Flu for Christmas, hope everyone else is doing better.

No, what it does mean is that so far in reading the documentation, I have not yet figured out how to do true WYSIWYG using font design units transformed into actual floating point dimensions (rather than DPI) for glyph dimensions.

However, if we could work in 7200 DPI resolution, it would be so close to correct that nobody would know the difference and that appears to require only small changes in Qt to do. 7200 DPI is a good value to simulate WYSIWYG because it is 5*1440 and 6*1200 so it would work for both common printer resolution moduli.

Just curious if there are any estimates as to how soon KDE4 will hit the "usable alpha" stage at this point.
Just wondering how soon I, as a compulsive KDE-svn recompiler, can switch to the new KDE4 branch and expect to be able to reasonably use the resulting KDE system productively with "not too many" problems. Recompiling updates to KDE 3.5 just doesn't have the same thrill it used to...

(Is it possible and feasible to have QT4.x and QT3.x coexisting on the same system at the same time?)

does there are plans to extende arthur to do 3d graphic too?
I have heard about the upcomming windows-api which will offer a all in one solution (2d/3d) through WPF. I think it would be a real improvement if the Qt api would also offer 2d/3d functionality in a integrative qt-way.

I know that there will be one big prize but what about people who come in like second or third, i feel it is unfair for them to waste their time without having some sort of prize. This would only have to be small in conisderation such as a certificate or whatever... that is signed