GUIMark 2: The rise of HTML5. Posted by Sean Christmann. Introduction. Two years ago I had an itch that needed scratching. RIA” was the future of the web and every major company seemed to have a solution to get us there. I developed the first version of GUIMark to not only get a good understanding of the respective technologies, but also to give my clients through Effective. UI and everyone else something to actively gauge the rendering performance of the different runtimes. After releasing it I got a good response from both the tech community as well as several platform engineers interested in resolving problems. There were however two serious flaws in the test that immediately stood out. First, the test was relying too heavily on text layout performance. I was barely engaging the the vector and bitmap side of the rendering engines. Secondly, the test was too artificial and developers have a tendency of resisting optimizing apis against unrecognizable test cases. Evolution. Fast forward to today and the web is a different beast. Attempt to shine a positive light on a plugin technology and you will be booed off the stage. Create something fun and silly in HTML5 and you’ll have hundreds of thousands of visitors pounding down the front door of your blog to speculate on the death of Flash. It’s undeniable that a new anchor technology is taking root in the web space, and needless to say I’ve got a new itch to scratch. GUIMark 2. Like the first GUIMark, this new benchmark is designed for one sole purpose, to burn a hole in your CPU. I still believe that by completely saturating the rendering pipeline, we can get a better idea of which technologies are best suited for running interactive content on the web. Developers tend to focus primarily on the speed of the programming language itself, when in reality, most of your cpu time is spent inside internal rendering APIs. I also firmly believe that any benchmark testing rendering performance should stick to sub 6. Almost all users on the web today are browsing with 6. Hz LCD monitors and there’s no reason to design a test that has to throw away frame data. While the new benchmark sticks to the original in theory, this version introduces some much needed changes. First, I’ve split GUIMark into 3 separate tests: Vector, Bitmap, and Text rendering, and I’ve attempted to make the test cases as real world as possible. Second, I’ve only implemented these tests in HTML5 and Flash. I’m not opposed to adding Silverlight and Java. FX to the benchmark, it’s just that I didn’t have the time to build them right now and something tells me a much smaller percentage of the internet crowd is interested in those results anyway. ![]() Feel free to flame me in the comments section for that one). Lastly, I’ve added mobile versions of some of the tests, we’ve all heard inflammatory statements from certain CEOs about mobile web performance, let’s see if the numbers back that up. Enough already, on to the results. Test environment. All of the tests below were performed on a 1. Macbook Pro with a 2. ![]() GHz Intel Core 2 Duo and an NVIDIA Ge. Force 9. 40. 0m. On the Mac side I’m running Snow Leopard with Flash player 1. On the PC side I have Windows 7 3. Aero turned on and again with Flash player 1. Latest trending topics being covered on ZDNet including Reviews, Tech Industry, Security, Hardware, Apple, and Windows. In September, Lyft has partnered with local restaurants in 12 major cities to offer you a free or discounted food for just showing your Lyft app. For Linux I ran a Linux Mint 8 Live CD with Firefox and Flash player 1. Unfortunately running off the Live CD meant no access to Nvidia drivers. Vector Charting Test. This benchmark is designed to stress the vector apis by simulating a streaming stock chart. The test makes heavy use of strokes with complex alpha fills. Originally I had added gradient fills into the mix to make sure that a good majority of vector APIs were being flexed, but there was no significant difference in the results so I pulled them out to make the visuals cleaner. While the source may appear to be heavy on the javascript side, the actual speed of code excluding canvas draw calls is less then 1 millisecond. HTML5. Flash 1. 0Windows 7. Internet Explorer 8. N/A3. 0. 7. Firefox 3. Chrome 4. 1. 2. 49. Opera 1. 0. 5. 32. Safari 4. 0. 5. Safari*2. Avg (1. 5. 6. 4) fps. Avg (2. 9. 1. 5) fps. Snow Leopard. Safari 4. Firefox 3. 6. 3. 32. Chrome 5. 0. 3. 42. Opera 1. 0. 1. 01. Avg (5. 5. 3) fps. Avg (2. 1. 2. 9) fps. Linux Mint. Firefox 3. Safari on Windows 7 will not animate the chart, it will only render one frame each time I press down on my mouse button. Results are all over the place for this test. On the HTML5 side Opera delivers the best performance on both platforms. Flash on the PC is consistently high, but on OS X, Chrome takes the top spot. Linux pulls off great numbers despite running off a Live CD. HTML5 on the Mac side requires closer inspection though. When I first made the test and showed it to my co- worker John Blanco, he started ripping apart the code to find any mistakes I might have made. What he discovered was that by changing the stroke size on my lines from 2 pixels to 1 pixel, performance in Safari, Firefox and Chrome shot up to rates closer to Flash, while Opera stayed at the exact same FPS. Flash on the Mac, as well as HTML5 and Flash on PC were largely unaffected by this change though, gaining maybe a single frame rate by changing to 1 pixel strokes. I’m not sure what to make of these findings. What kind of bug causes this and what side effects might be introduced by fixing it? Will a change allow both 1 and 2 pixel strokes to run at higher speeds, or will they both settle somewhere near Operas numbers. Bitmap Gaming Test. The bitmap test was designed to simulate a tower defense type game. The test stresses pushing around lots of bitmap assets that animate each frame. The entire rectangle view needs to be cleared each frame to account for all the changes happening in the scene. The test supports a minimal amount of z depth ordering but not so much as to cause user scripts to take more then 1 millisecond to execute. Both environments are using anti- aliasing to scale the bitmap images. HTML5. Flash 1. 0Windows 7. Internet Explorer 8. N/A1. 7. 3. 4Firefox 3. Chrome 4. 1. 2. 49. Opera 1. 0. 5. 31. Safari 4. 0. 5. Error*1. Avg (9. 8. 2) fps. Avg (1. 7. 1) fps. Snow Leopard. Safari 4. Firefox 3. 6. 3. 7. Chrome 5. 0. 3. 42. Opera 1. 0. 1. 05. Avg (8. 1. 3) fps. Avg (1. 5. 4. 4) fps. Linux Mint. Firefox 3. Safari on PC again only renders one frame per mousedown event, so the results are impossible to verify. These results are really surprising. Chrome on OS X manages to push Flash higher then even Windows based browsers. I was so surprised I ended up rebooting and running the test again just to make sure something wasn’t wrong. We’re starting to see a trend where HTML5 on average runs slower for Canvas based animations and I’ll explain why a bit further below. Linux takes a huge performance hit in this test but the percentage difference mirrors the other platforms exactly. With Nvidia drivers I’d imagine the real numbers would be closer to Mac performance. Text Column Test. This test is designed to push the text layout and rendering engine in HTML and Flash. The test utilizes custom fonts introduced with CSS3 as well as multibyte character string. This is my least favorite test in the group because it doesn’t simulate any real world test cases, however it should provide a good estimate of how quickly a page full of text can be calculated. I call it the “iceberg” test since 8. CPU happens outside the renderable view. It works because although text that overflows outside the textblock doesn’t get rendered, it does have to get calculated in order to know how many lines of text can be scrolled. HTML pages do this all the time when you load a site with text below the fold. HTML5. Flash 1. 0Windows 7. Internet Explorer 8. Firefox 3. 6. 3. 24. Chrome 4. 1. 2. 49. Opera 1. 0. 5. 32. Safari 4. 0. 5. 30*1. Avg (2. 4. 2. 4) fps. Avg (1. 4. 8) fps. Snow Leopard. Safari 4. Firefox 3. 6. 3. 23. Chrome 5. 0. 3. 42. Opera 1. 0. 1. 02. Avg (2. 4. 9. 1) fps. Avg (1. 8. 2. 5) fps. Linux Mint. Firefox 3. Safari continues to show problems on PC. Safari reports 3. I’ve included the results but they’re really wrong.*Internet Explorer renders the view, but is unable to display the custom fonts.*Chrome on both platforms is unable to render the Jedi custom font. I didn’t have time to investigate whether the super slow PC performance in Flash is my fault or Adobe’s, but I expect that will be uncovered soon enough. As for the general differences between HTML and Flash in the text test, this is exactly what I was expecting.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |