Several months ago, a simple question was raised to us: How can one build a web browser? This was an interesting question not a trivial one to be answered in one sentence. So, at the University of Szeged we started to work on this issue to come up with a handy answer. This is how Sprocket was born. However, let us start from the beginning.
This is a follow-up blog post of our announcement of TyGL - the 2D-accelerated GPU rendering port of WebKit.
We have been received lots of feedback about TyGL and we would like to thank you for all questions, suggestions and comments. As we promised lets get into some technical details.
We are proud to announce the TyGL port (link: http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on embedded systems. The engine is purely GPU based. It has been developed on and tested against ARM-Mali GPU, but it is designed to work on any GPU conforming to OpenGL ES 2.0 or higher.
The GPU involvement on future graphics is inevitable considering the pixel growth rate of displays, but harnessing the GPU power requires a different approach than CPU-based optimizations.
It's been a while since I last (and actually first) posted about Fuzzinator. Now I think that I have enough new experiences worth sharing.
More than a year ago, when I started fuzzing, I was mostly focusing on mutation-based fuzzer technologies since they were easy to build and pretty effective. Having a nice error-prone test suite (e.g. LayoutTests) was the warrant for fresh new bugs. At least for a while.
What is ASM.JS?
Lately, I came up with the idea to do some development on Aarch64. However, I couldn't get my hands on real hardware easily so I started to look for alternatives (i.e., emulators). The ARMv8 Foundation Model seemed to be the trivial solution but I've heard that QEMU is somewhat faster so I gave it a try. My goal was to set up the VM as quick as possible: reuse whatever is already "out there" and rebuild only what's utterly necessary. In the end it turned out that it's quite easy to get such a VM working ... once you know what you need.
Fuzzers are widely used tools for testing software. They can generate random test cases and use them as input against the software under fuzzing/testing. Since the tests have randomly-built content, it is not necessary to check them for correctness, but they are suitable for catching rough bugs like use-after-frees, memory corruptions, assertion failures and further crashes. There are many approaches how to generate these tests, but all of them can be categorized into three main groups: whitebox, blackbox and graybox fuzzers.
Last year I got a Nokia N9 on Qt Developer Days, it's a great mobile phone, I really like it, but I haven't published any memory measurement results about it yet. In my last post I did WebKit memory profiling on it with Valgrind, but it was all about heap usage. I think a number of persons are interested in the overall memory usage such as peak memory usage, the sizes of the used libraries, etc. During QtWebKit's life-cycle we switch from one library to another, usually because of performance considerations. In the past we do not take too much attention to memory consumption-related topics while switching between libraries, although it would be very vital to keep eye on this area as well.
In this post I would like to share with you one of my latest memory consumption measurements about the heap usage of QtWebKit.
64 bit systems allow allocating more memory, but this extra space has a trade-of: the pointers are grown to 64 bit wide which increases the total memory consumption. Ever wondered about the price of 64 bit? Well, you can find comparisons here about some popular pages on the Qt port of WebKit. Furthermore, we offer some CSS subsystem related comparisons at the end of the post.