July 1, 2009
Being a khtml developer and reading all those posts on the planet I just feel confused.
Basically, there are like 3 sentences to sum up. I like to work on khtml because it’s interesting and I get to work with super-smart people like Maksim or Germain and others. I don’t want to work on QtWebkit (or any other fork of webkit) as a free developer (without being paid) because it would mean I have to constantly keep up with work done by apple and other companies. Is it as much interesting? for me it’s not. And the third – it’s really possible to integrate both engines in konq and let people choose, with KPart technologies it’s only about making additional button (hopefully).
From my pov I would wish for one thing – contribution. Either it would be developing webkit kpart, konq, khtml, reporting bugs, broken sites, helping triaging (yay to bugsquad!), making testcases. And you can see – you don’t have to be a C++ developer to do that, you don’t have to be developer at all. Though I can’t make people do anything, let’s agree on that (it’s only my wish🙂 ).
So, it’s just my 2 cents about the topic after all…
November 27, 2008
It’s been a while since my last blog post and a lot has happened. So let me summarize some nice things. After my GSOC with SVG for khtml I felt like I need to do something more real-life, so I chose CSS to play with.
It’s appeared that recently web pages became slower and bigger, with heavy style sheets, so it was time for us to change something.
here is the bunch of optimizations was made for khtml before kde 4.2 release:
1. use AtomicString for CSS values, this way we reduce memory usage (with shared strings between different selectors) and improve item comparison
2. pre-parse class attribute selectors and store it as AtomicStrings (faster class look up)
3. better selectors collecting (linear algorithm instead of O(M*N) complexity)
4. finally, smart selectors choosing for potential match based on element’s class attribute, id attribute, local name id, so we don’t have to go over all selectors for every single element
Anyway, what’s in that? probably, not everyone is interested in code itself, so here is the impact:
– improvement on synthetic benchmark based on css taken from facebook from ~1s originally to 20ms with current trunk
– up-to 4x less memory usage for selectors with AtomicString on some heavy sites, like youtube
– much smoother site loading (youtube, facebook, etc)
– even acid3 got faster
August 25, 2008
GSoC is over for quite a while now, but that was a great time and it really helps if you want to join any open source community like KDE.
So, several days ago I was having discussion about multi-pattern search algorithm with SadEagle that could be used with adblock filtering. And I like the topic of high-performant algorithm. The same day I was reading several articles on that, the next day I was hacking on modified Rabin-Karp’s algorithm. Then I tried several more approaches, like Aho-Corasick.
A bit of testing, debugging, profiling and voila: several days after you could see the commit with numbers in it “7.6x improvement”. And us usual for practice approach (especially, with relatively short strings) algorithm shouldn’t be too complex but I enjoyed my little research anyway.
Big thanks for SadEagle, cause he did great job with it too. As well as performance improvement you could see ad block is now more compatible with adblock plus. and it supports whitelisting too.
July 22, 2008
It’s been a while since my last blog post. That’s mostly because I was working on svg text rendering. There were several problems that I had to solve before text appeared for me. Thanks to my mentor, SadEagle, who helped me with them.
My initial gsoc proposal said that at the end I would spend some time on testing. That’s why I was working on the text. It allows to render several tests from svg1.0 suite. And here is one of them:
June 25, 2008
After my previous post about my khtml gsoc progress I’ve been asked about cool tiger picture in svg format. Of course, I was curious and immediately downloaded it, but I found out that unfortunately tiger can’t be properly rendered in khtml due to missing features. That were proper color handling and grouping element with inherited style properties.
I’ve done some refactoring to use more shared code with original webkit’s svg library, and it lets me to easily implement these so wanted features. Also, I added gradient’s support and initial clipping.
Enough of words – screenshots tell for themselves:
June 20, 2008
I’m Russian student working at Google Summer of Code (GSoC) on KHTML. For those who doesn’t know or doesn’t care about kdes’ gsoc students: my project is to implement SVG support for khtml. As you may know in kde3 it was ksvg project and it interacts together with khtml. But with porting to qt4 a lot changed and the important thing: ksvg wasn’t ported. So, say no for normal svg support in khtml4.0.x. However ksvg is being actively developed in webkit and my main goal is to port it to khtml.
I’ve started to work on my project very early. The first reason svg is huge and the second one I had to do some underlying work before I could start with svg.
I’m working in my own khtml branch: branches/work/khtml-blaze.
So far, I’ve implemented support for basic shapes: rect, circle, ellipse, polygon, polyline, path. Supported attributes (not much): fill, stroke, stroke-width, fill-opacity, stroke-opacity. It seems small, especially if you take Qt library and paint such elements, but it’s not that easy, it touches all parts of khtml: DOM, CSS and Rendering. I had to add more than 50 files in cmake configuration file to make it work.
Already I have a nice thing: having rect and fill attributes make konq to pass one more test in “Web Compatibility Test for Mobile Browsers” http://dev.w3.org/2008/mobile-test/doc.html. yay!
And at the end, obligatory screenshot:
I have to say I’m very glad to be accepted as GSoC student for KDE. I thank all kde devs for doing great job. My mentor, SadEagle – you are the best. And khtml team.