tag:blogger.com,1999:blog-27901662.post4659808367644546929..comments2024-03-28T07:30:33.361+00:00Comments on Zack Rusin: 2D in KDEZackhttp://www.blogger.com/profile/16222054590923441165noreply@blogger.comBlogger28125tag:blogger.com,1999:blog-27901662.post-40951079347313122952010-11-06T23:26:27.123+00:002010-11-06T23:26:27.123+00:00Ubuntu announced switching to Wayland, with Qt 4.8...Ubuntu announced switching to Wayland, with Qt 4.8 the performance should go through the roof.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-89369483765860954352009-10-27T17:35:18.264+00:002009-10-27T17:35:18.264+00:00This might be slightly off topic but if you can h...This might be slightly off topic but if you can help it wud be gr8...For Particle Effects i can use QOpenGLWidget and I already have Qt Animation Framework for some animations on my QGraphicsView.Now, I want to have Particle effects in background (coming from QGL) and continue using anim framework on my graphicsView...i mean can i paint QGL stuff on QGraphicsScene 's background and retain foreground with QGraphicsItems ?aviralhttps://www.blogger.com/profile/14741671659159469170noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-72898391937301081682009-09-23T12:52:59.253+01:002009-09-23T12:52:59.253+01:00I have been doing some further tests of the polyli...I have been doing some further tests of the polyline drawing using the raster engine because my customers are complaining about line drawing performance.<br /><br />I created a harness in Qt and tested in all versions from 4.4.1 right up to the 4.6.0 tech preview and observed the same results.<br /><br />The conclusion is that there needs to be some serious profiling put on the antialiasing routines.<br /><br />My harnesss used GDI+ as an example. I plotted long polylines using the raster engine and GDI+<br /><br />Here is a typical benchmark.<br /><br />Take a 1000 point Polyine with GDI+ and Qt's DrawPolyLine routine with Antialiasing switched OFF.<br /><br />GDI+ - 94 Milliseconds<br />Qt - 78 Milliseconds<br /><br />All my tests clearly show that Qt is outperforming GDI+ in this area.<br /><br />Same points but with Antialiasing switched ON<br /><br />GDI - 172 milliseconds<br />Wait for it...<br />Qt - 10062 milliseconds<br /><br />Thats a whopping 10 seconds. All tests where conducted without having to clip lines (I wanted that out of the equation because apparently there is a bug regarding long polylines and clipping)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-42041766700778235592009-08-21T11:41:28.392+01:002009-08-21T11:41:28.392+01:00wow! wonderful blog.. Thanks for the sharing.. eas...wow! wonderful blog.. Thanks for the sharing.. <a href="http://www.itsolusenz.com" rel="nofollow">easy to download</a> it's a wonderful website...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-82796289448934687652009-08-18T12:46:39.030+01:002009-08-18T12:46:39.030+01:00"qtconfig is a qt3 application, so that's..."qtconfig is a qt3 application, so that's a little meaningless. Back in those days everyone did X rendering like that (even the deprecated qt4 port used the qt3support libs)."<br />Do you mean that qtconfig-qt4 is deprecated? If yes, what is it replaced with?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-74992086911473772592009-08-15T17:59:09.716+01:002009-08-15T17:59:09.716+01:00@Linuxhippy: As mentioned the state management is ...@Linuxhippy: As mentioned the state management is actually a lot simpler to do with OpenGL for accelerating 2D than with Xrender (because Xrender doesn't have state persistence and you need to essentially need to cache and hash on every call).<br /><br />GL will in fact magically improve the SVG rendering that slows Plasma down. The svgviewer example in Qt always allowed you to see the difference, it's huge :)<br /><br />qtconfig is a qt3 application, so that's a little meaningless. Back in those days everyone did X rendering like that (even the deprecated qt4 port used the qt3support libs). There was no Xrender composition and the Xrender text rendering was shimmied on top of it much later.Zackhttps://www.blogger.com/profile/16222054590923441165noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-12464810167364247292009-08-15T17:10:08.601+01:002009-08-15T17:10:08.601+01:00Yes I was talking about state management, which is...Yes I was talking about state management, which is usually way more complex for OpenGL compared to XRender.<br /><br />Sure you can buffer drawing commands, however I doubt it does help for typical 2d apps.<br /><br />I recently ran wireshark to see what resizing qtconfig produces, and beside mixing Render and X11-core-drawing all the time, the command-sequence looks like this: CreatePixmap, ChangeGC, PolySegments (outch!), ChangeGC, RenderRectangles, ChangeGC, ChangeGC, XPutImage, CompositeText and so on.<br />There isn't a lot you can buffer, however complex state management may lower performance.<br /><br />Please don't get me wrong, a GL backend is a great thing and it clearly has its advantages, especially for demanding apps, but for a typical UI with a few buttons I doubt it does any good.<br />However that case is never benchmarked :-/<br /><br />And all the SVG rendering that slows plasma down, won't become magically faster by using GL ;)Linuxhippyhttps://www.blogger.com/profile/04217622980907240583noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-41072777784886833462009-08-15T00:29:33.488+01:002009-08-15T00:29:33.488+01:00Qt4 applications when started with -graphicssystem...Qt4 applications when started with -graphicssystem opengl become horribly and unusably slow at window drawing - tested with Designer and Assistant.<br /><br />ATI x1650 (R500) card with open source radeon driver - KDE compositing enabled.<br /><br />I know it's not a good place to get support and neither am I seeking it, but just thought will make not in case people get all excited about "fast" opengl graphics on Linux :pAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-13327861863184439442009-08-14T19:14:41.584+01:002009-08-14T19:14:41.584+01:00@linuxhippy: I'm not quite sure what you mean ...@linuxhippy: I'm not quite sure what you mean by "deep pipeline" when referring to GL. When you're talking about the hardware then obviously Xrender acceleration wouldn't go through special magical paths in the hardware, it will use <b>exactly</b> the same things GL uses. So in that sense they're exactly the same.<br />If you're talking about state management that Mesa3D does before sending commands, then that model is obviously easier to implement for create/bind/destroy semantics, which would be preferable by the GPU's than what Xrender offers.<br /><br />Also small amount of data isn't a problem. Note that we know exactly when a scene finishes rendering (QPainter::end) and we can easily accumulate all data in buffers ready to upload if not already done so, bind and render on QPainter::end. Nothing says that the QPainter api is synchronous (in fact it's one of the main reasons why most of the benchmarks is wrong).Zackhttps://www.blogger.com/profile/16222054590923441165noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-42903440736486201352009-08-14T18:44:33.448+01:002009-08-14T18:44:33.448+01:00Another point, OpenGL has a quite deep pipeline - ...Another point, OpenGL has a quite deep pipeline - highly optimized to get feed with large data submitted in batches.<br /><br />2D in general is exactly the opposite - small one-by-one primitive calls, always changing rendering attributes (clip, color, ...) and so on.<br /><br />Yes, OpenGL shines in some benchmarks like QGears2 or some imaging stuff, but I haven't seen *real* benchmarks runnig the OpenGL backend, doing what toolkits usually do - many many small operations.<br />And because QT doesn't change the way the 2D api looks, for OpenGL nothing changes.<br /><br />I just know of Java2D that their (also very well performing) OpenGL backend doesn't perform that well for Swing interfaces - simply because all that small primitives are not worth to go through the long driver pipelines <b>heavily tuned for games</b>.<br />Have you tried to run ~20-30 OpenGL apps side-by-side? Horrible, and a huge resource waste.<br /><br />So yes, there are workloads where the OpenGL has clearly a large advantage.<br />On the other side, recommending it for every and all apps is stupid.<br /><br />Better adress all those ugly performance problems in KDE4/QT4 caused by bad design - like all that SVG re-rendering when e.g. a folderview is resized (that has a horrible profile), or the backbuffer allocation storm when a window is resized.<br />Yes, some parts of XRender are ugly, but its not the only reason QT4 feels that slow.Linuxhippyhttps://www.blogger.com/profile/04217622980907240583noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-70636664031536166142009-08-14T18:36:53.135+01:002009-08-14T18:36:53.135+01:00> When that decision was made none of the
>...> When that decision was made none of the <br />> drivers supported it. It simply hasn't <br />> been reevaluated.<br />I've filed an enhancement request, hopefully Nokia will reevaluate that soon.<br /><br />> It's just a question of whether it will <br />> be beneficial to majority of users who <br />> are running Qt/KDE, or whether raster <br />> engine is still faster at it. And <br />> that's of course left for benchmarking.<br /><br />It is for sure! Keep in mind that its not just the XRender vs. Raster, but Xrender vs (VRAM-download (very slow) + Raster + VRAM+upload + X11 transport overhead).<br />Most simple benchmarks do the same operation over and over, so a pixmap is migrated only once - but in the "real" world raster and xrender will mix quite often leading to horrible results.Linuxhippyhttps://www.blogger.com/profile/04217622980907240583noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-29355534271499440142009-08-14T17:29:16.723+01:002009-08-14T17:29:16.723+01:00I would like to echo the first poster's questi...I would like to echo the first poster's question: can we change the default (particularly to use raster on Linux)?Unknownhttps://www.blogger.com/profile/17053845016489256894noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-78541385513717115962009-08-14T16:49:49.975+01:002009-08-14T16:49:49.975+01:00@linuxhippy: When that decision was made none of t...@linuxhippy: When that decision was made none of the drivers supported it. It simply hasn't been reevaluated. It's just a question of whether it will be beneficial to majority of users who are running Qt/KDE, or whether raster engine is still faster at it. And that's of course left for benchmarking.<br /><br />@Albert: I wasn't attacking you, in fact if I recall correctly I haven't even mentioned you in the post. To your problem though: if you state that the problem is intersection detection you can be 100% sure that everyone will assume you mean tessellation because that's the crucial path where that algorithm always matters. I'm not very good at reading minds and if you mean flattening of polygons when you talk about intersections in primitives then all I can do is throw my hands in the air and laugh. Oh, and I certainly haven't complained, again if I recall correctly (and my memory should be pretty clear given that the answer is about a page up) I even told you how to fix your specific problem.Zackhttps://www.blogger.com/profile/16222054590923441165noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-47512911996578189032009-08-14T16:03:45.353+01:002009-08-14T16:03:45.353+01:00@blazt: It is not my algorithm, it's Qt one
Z...@blazt: It is not my algorithm, it's Qt one<br /><br />Zack: I have code where that "count" is 3600, and it's your blog and of course you decide what you want on it, but don't do an ad hominem 'attack' to me and then complain because i answer.Albert Astals Cidhttps://www.blogger.com/profile/12001470108926138921noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-79212626501918562142009-08-14T14:24:34.091+01:002009-08-14T14:24:34.091+01:00Hi Zack,
I am developing a C# application in Wind...Hi Zack,<br /><br />I am developing a C# application in Windows. The app was programmed to draw with GDI+, but since it had to draw more than 200.000 2D drawing primitives (lines, ellipses, bitmaps) it was very slow (it take several minutes to draw everything).<br /><br />Because of that I decided to rewite every 2D drawing primitive to OpenGL in 2D with a multilayer environment. It took me a week and the result is that now it draws everything in less than one second, so I agree with you and I recomend to write a QTOpenGLPainter (it could take 3 or four weeks) in order to accelerate drawing 2D primitives in QT.<br /><br />I also think that QT shoud select automatically the drawing method (CPU, 2D accelerated or OpenGL).<br /><br />GreetingsAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-68957730995220751332009-08-14T12:59:38.718+01:002009-08-14T12:59:38.718+01:00Some quick comments:
@Anonymous: Sounds more like ...Some quick comments:<br />@Anonymous: Sounds more like unaccelerated OpenGL to me.<br />@Rudd-O: This isn't the best place to get support. In general it sounds like your setup is busted. Either your distro via updates (e.g. installing Mesa3D libs over your proprietary NVIDIA/ATI drivers) or by you. You need to fix that first.<br />@Anonymous: Yes, that's true. Technically you can already do that with Qt Embedded and QWS.<br />@Albert Astals Cid: That "count" in that algorithm should be at most 3. However you got there is wrong. Also if it's X11 engine that does it's obviously a bug. (but this forum also isn't the best place to get people to fix it, e.g. the intersection algorithm used by the tessellation algorithm should be used there).<br />@Anonymous: A little hard to tell without any kind of profiling data. I'd bug Qt Software for a decent benchmarking utitily ;)<br />QGraphicsScene will inherit the default from its view.<br />@Enrico: The way I'd phrase is that "it'd be the easiest to make it fast" on account of the fact that you're so close to the real hardware. But in general the small wins you'd get from state management wouldn't be worth the lost flexibility of being able to run on more than just hardware that has Gallium drivers, so OpenGL is probably a better choice for applications and Qt right now.<br />@blazt: That's correct. As mentioned Qt already uses them. The path Albert hits shouldn't be executed with that big of a count but either way as Panagiotis Papadakos pointed out the code in there should have been updated with the algorithm from qtessellator.cpp.Zackhttps://www.blogger.com/profile/16222054590923441165noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-80283436104642287282009-08-14T12:51:49.259+01:002009-08-14T12:51:49.259+01:00Hi Zack,
> So even if the driver would acceler...Hi Zack,<br /><br />> So even if the driver would accelerate > for example gradient fills and source <br />> picture transformations it wouldn't <br />> help you because Qt simply doesn't use <br />> them and always falls back to the <br />> raster engine. It's a bit of a chicken <br />> and an egg problem - Qt doesn't use it <br />> because it's slow, it's slow because no <br />> one uses it.<br /><br />Basically this is a really stupid descision:<br />- Source picture transformation is now accelerated well by *all* major drivers.<br />- Gradients are still generated by pixman, but vram upload are optimized, so at least the composition step can be accelerated.<br /><br />Anyway, client-fallbacks are probably the worst thing you can do. I am really sad QT doesn't do any better here - and to be honest it also has a bad influence on KDE4.<br />I'd just started Fedora8 with KDE-3.5, and was impressed how snappy the whole system felt compared to Fedora-11+KDE-4.3.<br /><br />Why can't QT decide to fall back if render-version is less than xy, and use it otherwise.Linuxhippyhttps://www.blogger.com/profile/04217622980907240583noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-65521301118841883822009-08-14T12:19:43.495+01:002009-08-14T12:19:43.495+01:00http://qt.nokia.com/developer/task-tracker/index_h...http://qt.nokia.com/developer/task-tracker/index_html?method=entry&id=208626Panagiotis Papadakoshttps://www.blogger.com/profile/14840033162935430657noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-64005547623453802392009-08-14T12:17:39.937+01:002009-08-14T12:17:39.937+01:00This comment has been removed by the author.Panagiotis Papadakoshttps://www.blogger.com/profile/14840033162935430657noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-41863018976628909972009-08-14T11:38:56.192+01:002009-08-14T11:38:56.192+01:00Albert Astals Cid: Your algorithm is O(n^2) but it...Albert Astals Cid: Your algorithm is O(n^2) but it's a brute force algorithm.<br /><br />There are better algorithms for intersections based on sweep line algorithm: <br />http://en.wikipedia.org/wiki/Sweep_line_algorithm<br />Example for line intersection:<br />http://en.wikipedia.org/wiki/Bentley%E2%80%93Ottmann_algorithmBlaž Tomažičhttps://www.blogger.com/profile/11507195585430657746noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-67617637149176305792009-08-14T11:35:01.208+01:002009-08-14T11:35:01.208+01:00What about a QPainter state tracker over Gallium? ...What about a QPainter state tracker over Gallium? Will it be the best thing out there or is it possible to improve painting speed even more?Enrico Roshttps://www.blogger.com/profile/10474324679416549831noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-20482248716888777902009-08-14T10:21:40.734+01:002009-08-14T10:21:40.734+01:00Thanks for removing the crappy background.
And y...Thanks for removing the crappy background. <br /><br />And yeah, even for my simplest photo editing program, which rotates and scales Photos smoothly, I'm totally lost in speed on my Intel card when using OpenGL. Why is that?<br /><br />You didn't list a QGraphicsScene, what is being used by default when painting on this?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-73646506814879413922009-08-14T09:17:47.789+01:002009-08-14T09:17:47.789+01:00As the said "someone" please explain me ...As the said "someone" please explain me if this is not O(n^2)<br /><br />QList<QPolygonF> QPainterPath::toFillPolygons(const QTransform &matrix) const<br />...<br />for (int j=0; j<count; ++j) {<br /> if (subpaths.at(j).size() <= 2)<br /> continue;<br /> QRectF cbounds = bounds.at(j);<br /> for (int i=0; i<count; ++i) {<br /> if (rect_intersects(cbounds, bounds.at(i))) {<br /> isects[j] << i;<br /> }<br /> }<br />}<br /><br />Because valgrind tells me that rect_intersects is executed 27889 times for my line with 167 dashesAlbert Astals Cidhttps://www.blogger.com/profile/12001470108926138921noreply@blogger.comtag:blogger.com,1999:blog-27901662.post-5060712290764738262009-08-14T09:02:06.250+01:002009-08-14T09:02:06.250+01:00Zack, do I understand this correctly?: If someone ...Zack, do I understand this correctly?: If someone could provide an input library (keyboard, mouse) I could run QT/KDE without the whole X11 environment directly on MESA?<br /><br />matthiasAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-27901662.post-68548870550430493902009-08-14T04:16:15.857+01:002009-08-14T04:16:15.857+01:00No KDE application that I tested works correctly w...No KDE application that I tested works correctly with OpenGL graphicssystem. They all segfault on startup the minute they map a window. Kopete actually starts up, but when you click the icon to show the window, boom, dies.Rudd-Ohttps://www.blogger.com/profile/07681345274514958394noreply@blogger.com