On Friday, I decided that I was completely fucking sick of the loadtimes and lack of responsiveness on the Windows build. I spent literally the entire day doing absolutely nothing but performance profiling and optimizations… the results are what you see in the repositories. The loadtimes are 100% eliminated, BUT there are still a few small issues with regards to moving the selection around the scene on certain platforms. My changes required some SERIOUS internal rewriting, and we are still performing testing and resolving a few small issues. We are aware of them. \ud83d\ude00<\/p>\n
[b]Tested Platforms[\/b]:<\/p>\n
1) Falco’s work i7 (Windows) – works flawlessly<\/p>\n
2) All of our Macbook pros – works flawlessly<\/p>\n
3) Jarrod’s PC (Windows) – works flawlessly<\/p>\n
4) Tyler’s laptop (Windows) – serious redraw issues with tile selection<\/p>\n
5) Our server (Kubuntu) – serious redraw issues with tile selection<\/p>\n
* – even the two with redraw issues had absolutely no loadtimes and a drastic improvement in performance.<\/p>\n
[size=20]So what the fuck did you do?[\/size]<\/p>\n
Wheeeeeeell… gather round, gentlemen. After a bit of profiling, it turned out that the unforgivable load times on Windows were due to two contributing issues…<\/p>\n
[b]1) Tile Cutting Algorithm[\/b]<\/p>\n
I had a pretty farfetched theory with this one, and it turns out that I was right. <\/p>\n
[u]Fig 1. Reested Code[\/u]<\/p>\n
QImageReader reader; reader.setFileName(loc); QRect clipRect(0,0,spriteWidth,spriteHeight); int id = 0; if(!reader.canRead()) { \tDebug::Logf(Debug::CRITICAL, \"Could not read image file %s!\", loc.toStdString().c_str()); \treturn false; } for(; clipRect.y() < (int)sheetHeight; clipRect.translate (0,spriteHeight)) { \tfor(clipRect.moveTo(0,clipRect.y()); clipRect.x() < (int)sheetWidth; clipRect.translate(spriteWidth,0)) { \t\treader.setFileName(loc); \t\treader.setClipRect(clipRect); \t\tQImage image = reader.read(); \t\tif(image.isNull()) { \t\t\tQString error = reader.errorString(); \t\t\tDebug::Log(Debug::CRITICAL, \"TileManager::DivideTileSheet(): There was an error reading the image! Error message: \" + error); \t\t\treturn false; \t\t} \t\tVisualTile *tile=new VisualTile; \t\ttile->image=QPixmap::fromImage(image); \t\ttile->id=id++; \t\tcontainer.push_back(tile); \t} } return true; <\/pre>\nIt turns out that our original, QImageReader implementation of the algorithm works as such:<\/p>\n
1) fetch image from hard drive<\/p>\n
2) seek to location<\/p>\n
3) read in small portion of image<\/p>\n
4) close image<\/p>\n
(REPEAT FOR SHEET)<\/p>\n
The shit performance was due to the opening and closing of the sheet from the drive for each tile loaded…<\/p>\n
[u]Fig 2. Pristine Code[\/u]<\/p>\n
QImage image(loc); QRect clipRect(0,0,spriteWidth,spriteHeight); int id = 0; if(image.isNull()) { \tDebug::Logf(Debug::CRITICAL, \"Could not read image file %s!\", loc.toStdString().c_str()); \treturn false; } for(; clipRect.y() < (int)sheetHeight; clipRect.translate (0,spriteHeight)) { \tfor(clipRect.moveTo(0,clipRect.y()); clipRect.x() < (int)sheetWidth; clipRect.translate(spriteWidth,0)) { \t\tVisualTile *tile=new VisualTile; \t\ttile->image = QPixmap::fromImage(image.copy(clipRect)); \t\ttile->id=id++; \t\tif(tile->image.isNull()) { \t\t\tDebug::Log(Debug::CRITICAL, \"TileManager::DivideTileSheet(): There was an error reading the image!\"); \t\t\tdelete tile; \t\t\treturn false; \t\t} \t\tcontainer.push_back(tile); \t} } return true; <\/pre>\nMy new algorithm reads the entire picture into RAM, then copies subsections of the image. There is only one read from the hard drive.<\/p>\n
The effect on loadtimes was fucking insane. [i]We went from 5.2+ seconds to about 50ms.[\/i] Yes, bitches. That’s 100x faster.<\/p>\n
[b]2) QGraphicsScene Population[\/b]<\/p>\n
This has been a known issue for awhile… I just haven’t been able to devise a workable solution. The problem is that for every tile, we used a QGraphicsItem to render its image… That’s exactly how the QGraphicsParadigm is meant to be used. No big deal, right? Well, we have a 200×200 map at 4 layers… 200x200x4 = 160,000 QGraphicsItems. Amazingly enough, this seemed fine on Linux and OSX… but for some reason, QT’s Windows implementation just couldn’t handle the sheer number. That was out of our control.<\/p>\n
I finally had an epiphany on Friday… Rather than having an entire set of QGraphicsItems to represent each layer, I could use a single grid of QGraphicsItems whose paint() functions were overloaded to [i]render all four layers[\/i]. Boom! Windows can populate a scene with 60k items easily. All of the scene population happens the instant you load the Toolkit. It will never need to do that again.<\/p>\n
[b]IN ADDITION TO THE ABOVE REEST[\/b]<\/p>\n
I have discovered a way to hardware accelerate QT’s QGraphicsView by using OpenGL. On various platforms, this results in a huuuuuuuuuge performance increase. On some (with shitty OpenGL drivers), this is actually slower. Jarrod is going to be implementing a Toolbar UI at the top of the Toolkit with handy icons for common actions (flip\/rotate tiles, reload sheets, invoke engine, etc). A “toggle hardware acceleration” button will certainly be up there as well. You guys will love it.<\/p>\n
So there yo have it. Between the two optimizations, there are no longer any loadtimes in the Toolkit. My top priority is to resolve the redraw issues. Once this is done, I will feel very comfortable encouraging everybody to start using the “optimized-as-shit” build. \ud83d\ude00<\/p>\n","protected":false},"excerpt":{"rendered":"
Originally posted by Gyrovorbis (Falco Girgis) in our Private Development forum on 1.9.12.<\/strong><\/p>\n[quote=”pritam”]Edit: I re-cloned the toolkit repo and with exception to lack of viewport repaint on xp, the absence of the freeze feature is glorious![\/quote]WHEEEEEEEEEEEEEEEEELL!!!!<\/p>\n
You weren’t supposed to know about that new feature yet. \ud83d\ude09<\/p>\n
Well, since people are pulling down Jarrod and my “extremely optimized beta-as-shit edition,” I had better start talking about it. \ud83d\ude06 <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-179","post","type-post","status-publish","format-standard","hentry","category-underlying-technology"],"_links":{"self":[{"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/posts\/179","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/comments?post=179"}],"version-history":[{"count":0,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/posts\/179\/revisions"}],"wp:attachment":[{"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/media?parent=179"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/categories?post=179"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/elysianshadows.com\/updates\/wp-json\/wp\/v2\/tags?post=179"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}