Chrome is even worse - the minimise/maximise/close buttons are actually
bitmap images! (
http://src.chromium.org/viewvc/chrome/trunk/src/ui/resources/ )
They've also been reinventing the scrollbars too; it looks like WebKit uses the native drawing routine for scrollbars, but Chrome wants to reimplemnt that itself:
http://my-chrome.ru/2014/01/about-scrollbars/ (from right to left: natively drawn scrollbar, Chrome-drawn half-broken scrollbar, Chrome-drawn slightly-less-broken scrollbar.)
>>17,18They're complex because the monkeys who write them are doing it wrong. I've been (slowly) working on a CSS box renderer and the code is actually quite simple and straightforward once the algorithms have been figured out.
The big rendering engines are written by large teams with deadlines so there's necessarily the whole OOP bloat (all the ways to make software easier to write for large loose teams but creates ridiculously inefficient enterprisey designs: "separation of concerns", "information hiding", etc.) and less time spent thinking about the simplest way to do something, which also adds to the complexity.
On the other hand I'm working alone and not trying to make any deadlines, so I can spend as much time as I like thinking about how to design this thing and have it as monolithic as it needs to be. For example, the document is tree-structured so it seems to suggest a lot of algorithms are going to be recursive; I also thought at first this would be how the line layout (including wordwrap) should be done, but then realised just how much state would need to be passed around and that doing it recursively seemed far too complex.
If I was someone working as part of a team on a project with a deadline, I might've just accepted the complexity at this point, maybe even tried to hide it behind a design pattern (which just makes things worse overall!) or made several classes, and wrote the code. This is how most of the existing rendering engines (and the bulk of software) was written.
Instead I thought about it more and realised that recursion is
not the best way to do it - the boxes do form a tree structure, but recursion isn't needed to traverse them and calculate linebreaks since that requires a more linear view of the data. I ended up with an extremely elegant and simple algorithm based on a few loops and pointer following. It can't be written without using
goto either, so a more traditional programmer probably would've never figured it out. The implementation of the core traversal and linebreaking decision is only a few dozen machine instructions.
Rendering a document is overall a complex task, but if you can consider all that complexity in large pieces, and condense them into a simple algorithm, then the code does not need to be complex. In contrast with the traditional notion of breaking problems into simpler pieces and then combining them together to create a more complex whole, I'm taking complex pieces of the problem and combining them together to create a simple whole. It's somewhat like procedural generation in the demoscene.
Let's make this thread the continuation of
http://dis.4chan.org/read/prog/1321853871/