Tomahawk, KDE, and other stuff
Qt 4.5 RC1 packages for Intrepid, built with -graphicssystem raster
Update: These packages are for testing only! Things that rely on the default native backend WILL break. If you want a build of Qt 4.5 RC1 for Intrepid without -graphicssystem raster, try pollycoke’s PPA.
The title says it all. They’re available from my PPA. Enjoy!
RSS
email
Print
PDF
Add to favorites
Identi.ca
Twitter
Google Buzz
Facebook
del.icio.us
Google Bookmarks
Reddit
Technorati
Slashdot
Digg
I would not even both reporting bugs in kwin etc. if you are using these packages. Anything that uses X11 deeply will be broken unless you also release a set of patches for KDE to disable this paint system for those apps.
I wouldn’t bother filing any bugreports against any app with the switch on by default, unless you know the app doesn’t rely on any behaviour of the native engine that the raster engine breaks.
I don’t think there’s any gain in having a Qt that uses raster by default, unless you like crashing apps/desktop.
hi!
thx for that…but what does it imply?
are they replacing the current qt libs?
are they breaking KDE/qt?
what does –graphicssystem raster do?
Richard and Andreas:
These are, obviously, testing packages. They’re to be used by people who want to find where these bugs are, and report them before 4.5 goes final.
If you are enabling raster by default you MUST run KWin with “-graphicssystem native” otherwise compositing will not work at all.
Yes, I suspect the same may be true of ksnapshot as I use some X11 functions directly there too. I’m not sure if it will work smoothly, work partially or not work at all with the raster paint engine.
I’ve updated the text to make it clear that things will break and it’s only for testing.
So far I’ve not seen any (additional) problems worse than smaller graphics glitches, e.g. seeing the backround through a hole in the window. Never in foreground windows though, so it’s not too bad. And it happens very rarely.
KSnapshot works fine AFAICT. I don’t use kwin composite.
According to Qt Software the raster graphics backend is fully supported – which probably does not include “for writing compositing window managers”
In addition most screensavers are likely to perform terribly. I know this is the case at least for KDE Asciiquarium in KDE 4.2, but should apply to anything that animates using QPainter::drawPixmap().
So far, exept kwin compositing not working, I don’t see problems but everything seems…way faster!
What are you all using?
For me on KDE 4.2 intrepid QT 4.5 RC
- phonon stops working
- kdm crashes
Rest seems ok from first view
Ehh, you’re doing a disservice to everyone by providing packages built with raster as default. Essentially what you’re doing is exactly what we did in 1990ties – instead of fixing real graphics issues you’re hiding them, not giving anyone chance to fix them.
No one, especially developers, should ever, ever use raster engine as default. If you are, you are essentially killing our chances of having a working graphics stack.
The graphics stack on Linux has sucked for ~15 years, and you say that the fix is just around the corner. This time really… And all the different driver authors are going to join the effort?
You are proposing users to suffer intentionally so everybody sees how bad exactly it is and does something to fix the situation. This is quite backwards.
I’m not holding my breath, sorry.
That said, I’ll be eager to test something new whenever it becomes available in alpha or beta quality, for hardware that I own. That would be an i845 GPU and a Radeon HD 2400 GPU.
It’s quite sad how you and most likely others still don’t get it. The reason a lot of this stuff is broken is because people keep using workarounds instead of producing test cases that just show what’s not working. I know it’s a lot easier to say “it’s not working” and when questioned what point to a million line of code application. Everyone expects magic and is not willing to spend a second to help.
If you actually want to help than use Qt with graphicssystem opengl and start producing test cases as in
http://cgit.freedesktop.org/mesa/mesa/tree/progs/trivial
and we’ll be fixing them.
Oh, and if you think that the whole stack is broken beyond repair then just use Windows or OS X. There’s no point in having you suffer as you say. Either you care about this stuff in which case raster is the opposite of what you want, or you should be using other operating systems that better fit your needs.
The reason why things are broken (not really: just slow) is that nobody fixed them. You can blame nobody or anybody for that as long as most people are doing this in their free time.
I should also mention that the raster backend does have its problems so it’s unlikely to become the default on Qt 4.5 and KDE 4.3.
Regarding the whole stack being beyond repair, I remember you saying in a presentation at Akademy that Gallium3D could possibly replace the graphics part of X11 if something else handled things that are not painting.
And yes, IIRC you only said that because somebody asked a leading question, I know. It was not me
So, what is your vision how to make the Linux graphics stack really fast in, say, three years? For all I know the problem could be that all drivers suck at acceleration… You tell me.
No, I’m doing a service to anyone that wants to test out their Qt apps using raster and doesn’t want to pass in –graphicssystem raster every time. For some applications, it causes a great speed improvement, and it may be of help to people packaging apps with static Qt libs that may want to consider such an approach, if it provides a better experience to the end user.
These packages are not for everybody. I do not use them myself. But some may find it useful.
Yes, you are right. Clearly you know a lot better than everyone else, including the entire Qt Software division how Qt needs to be compiled. You obviously considered all the pros and cons of all the approaches and realized that the fact that it’s not default means that people who wrote it don’t know what they’re doing. It’s a truly visionary approach.
Sarcasm works better when you’re mocking what somebody actually said. Not only did I not say that raster should be the default (it shouldn’t for >99% of people’s use-cases), or that the people behind Qt don’t know what they were doing, I didn’t even imply it.
I really don’t get why everyone is taking so much time to criticize me for making these. No one is forcing anybody to use these packages. They state right up front what they are, and people can make educated decisions about whether or not they want to use them. The blog post says it is for testing only and will screw things up. The PPA makes it clear (after needless bitching from KWin people, who apparently think that the only use for Qt is KDE) that people should not file bug reports in the KDE bug tracker when using these packages.
People can use parted to wipe out their hard drives, but I don’t hear people complaining that parted gets packaged. The user has enough information to make their own decision. Let the buyer beware.
P.S. Since you seem to be aware of how the entire Qt Software division knows how Qt needs to be compiled, consider this: If the people at Qt software wanted to make sure that no one would ever compile Qt using raster or opengl as the default rendering engine, they shouldn’t have made it a configure option.
That’s great…we have a super fast engine almost ready to use and only kwin and a few other places needs to be fixed to work with it, but wait! Let’s keep using our old stack slow and broken as hell so somebody eventually will fix it in the next 10 years. AND If somebody doesn’t agree fuckoff. Go cry to windows or macosx.
Great way to win new users!
but hey, who needs users anyway?