Re: [dev] Suckless web rendering engine
I believe their latest code has float support, but it isn't released yet. Their CSS support is starting to mature. I use it under tabbed, like surf. I have been following it for years, and they have their own kind of suckless approach, but oriented toward enabling developing countries to access The Web with few resources. Ben Original Message From: Calvin Morrison Sent: Monday, February 16, 2015 6:10 AM To: dev mail list Reply To: dev mail list Subject: Re: [dev] Suckless web rendering engine i've tested out dillo yesterday, and a bit today. it is very fast, but lacks javascript. Overall useful for simpler pages (lwn for example), but fails badly on things with floating elements instead of tables. On 16 February 2015 at 02:40, Dmitrij D. Czarkoff wrote: > Marc Weber said: >> also have a look at: http://de.wikipedia.org/wiki/Servo_(Software) > > Servo appears to suck a lot. They appear to focus on improving > performance by spawning endless threads (complexity), and they require > specific custom version of compiler (quirkiness). > > -- > Dmitrij D. Czarkoff >
Re: [dev] Suckless web rendering engine
Calvin Morrison said: > lacks javascript. See their "Plans" page.¹ > but fails badly on things with floating elements instead of tables. According to their Changelog,² floating elements are already supported in tip. There was a time when I used dillo much, and it was exceptionally good. These were the times when CSS was only starting to surface, and GTK+1 was still used a lot. It's a pitty they don't keep up with web "standards". ¹ http://www.dillo.org/Plans.html ² http://hg.dillo.org/dillo/raw-file/tip/ChangeLog -- Dmitrij D. Czarkoff
Re: [dev] Suckless web rendering engine
i've tested out dillo yesterday, and a bit today. it is very fast, but lacks javascript. Overall useful for simpler pages (lwn for example), but fails badly on things with floating elements instead of tables. On 16 February 2015 at 02:40, Dmitrij D. Czarkoff wrote: > Marc Weber said: >> also have a look at: http://de.wikipedia.org/wiki/Servo_(Software) > > Servo appears to suck a lot. They appear to focus on improving > performance by spawning endless threads (complexity), and they require > specific custom version of compiler (quirkiness). > > -- > Dmitrij D. Czarkoff >
Re: [dev] Suckless web rendering engine
sed and awk are the best web browsers. On 2/16/15, Dmitrij D. Czarkoff wrote: > Marc Weber said: >> also have a look at: http://de.wikipedia.org/wiki/Servo_(Software) > > Servo appears to suck a lot. They appear to focus on improving > performance by spawning endless threads (complexity), and they require > specific custom version of compiler (quirkiness). > > -- > Dmitrij D. Czarkoff > >
Re: [dev] Suckless web rendering engine
Marc Weber said: > also have a look at: http://de.wikipedia.org/wiki/Servo_(Software) Servo appears to suck a lot. They appear to focus on improving performance by spawning endless threads (complexity), and they require specific custom version of compiler (quirkiness). -- Dmitrij D. Czarkoff
Re: [dev] Suckless web rendering engine
On Sun, Feb 15, 2015 at 04:10:15PM -0200, Marc Collin wrote: > Are there any plans for this? You may try to contribute to Blink and Servo. They may still suck, though. -- Teodoro Santoni
Re: [dev] Suckless web rendering engine
NetSurf's parser isn't suckless. Here are some issues with their tokeniser.c - Using switch statement and explicit case numbers to implement the tokeniser FSM instead of simple gotos and implicit position-based FSM. This means it has to go through that switch every time through the main loop, even if the next state is the same, instead of just jumping to the right place. - Making every damn state a function. The amount of work that has to be done in each state is tiny, but somehow they've managed to bloat them big enough to look like each one of those functions is nontrivial. There is a ton of duplicate code as a result - for example, compare hubbub_tokeniser_handle_attribute_value_dq(), hubbub_tokeniser_handle_attribute_value_sq(), and hubbub_tokeniser_handle_attribute_value_uq(). (The names are ridiculously long too.) Each one is over 40 lines and performs basically the same thing... can you spot the differences between them? Here's the corresponding part of my parser's tokeniser; it handles all 3 types of attribute values. attrv_unquoted_loop: cmp al, '>' jz finish_attr_done call [ebp+htmlp.func_iswhs] jnz attrv_loop finish_attr_done: ; omitted code here finishes an attribute and emits a tag or starts a new one (~10 lines) ... find_attrv: xor bl, bl ; presume unquoted ; omitted code here scans for start of an attribute value (<10 lines) ... cmp al, '"' jz attrv_quoted cmp al, "'" jnz attrv_unquoted attrv_quoted: mov bl, al ; save quote char inc edx ; skip quote char attrv_loop: call [ebp+htmlp.func_getchar] ; EOF - ignore attrv_unquoted: or bl, bl jz attrv_unquoted_loop cmp al, bl jnz attrv_loop jmp finish_attr_done I've shown quite a bit more than the actual unquoted/quoted attribute value states, just so you can follow the structure around it, and yet this code in x86 Asm is still shorter than one of Hubbub's functions, in C, that does a tiny fraction of the real work this does! The actual quoted/unquoted attribute value states are represented by these ten instructions: attrv_unquoted_loop: cmp al, '>' jz finish_attr_done call [ebp+htmlp.func_iswhs] jnz attrv_loop ... attrv_loop: call [ebp+htmlp.func_getchar] ; EOF - ignore attrv_unquoted: or bl, bl jz attrv_unquoted_loop cmp al, bl jnz attrv_loop jmp finish_attr_done I'm not claiming to be an expert on HTML parsing by any means, but this code is so short because what it does really is that simple - unquoted attributes are terminated by > or whitespace, and quoted ones are terminated by their quote character. There's nothing at all deep or complex about this, yet Hubbub's version makes it look like even "lightweight" code (which they claim to be) needs to do all that shit so it gets used as "evidence" by all the people claiming "browsers need to be complex!" - Character references don't need to be handled by the tokeniser, since the presence or absence of any '&'s doesn't affect tokenisation. - DOCTYPE tokens, same thing, already mentioned above. - EOF - this is another bloater. Hubbub checks for EOF in the code of every state(!), but if you read the spec you'll see that the number of operations upon EOF are limited to two: not doing anything or "emit the current token", so my EOF handling is done in getchar. The cases that don't do anything don't need any code, the ones that do are recorded in an array (there's only 16 entries) and the right place is jumped to when the EOF function is called. - Partial input handling: this is all handled in getchar - which returns "up two levels" to whatever called the parser when it runs out of input (try doing that in C!) The input is one big buffer which gets resized and moved as needed. I'm not sure what Hubbub does here, but it's probably more complex than this. - Output interface: Hubbub stuffs everything into a "token" structure and then calls one function, token_handler(), to push the results out. It has functions named emit_current_tag(), emit_current_comment(), emit_current_chars(), etc., but all those have to go through that one token_handler() function. On the other side, the tree construction has to then switch on that type, just to call the right function, when they could've made the tokeniser call those different functions in the first place. How stupid is that? It's bloody-panties-on-head retarded!! I take the sane route with my tokeniser interface: extrn @emit_doctype@4:near extrn @emit_text@4:near extrn @emit_comment@4:near extrn @emit_tag@4:near One function for each token type, as it should be. No need for a "token type" either, because the function being called implicitly determines what token was emitted, and it can directly read from the right fields of the parser/tokeniser structure to get its info. The pointer to the parser structure is in a register already. Simple and efficient. On Sun, Feb 15, 2015 at 5:30 PM, Marc Collin wrote: > NetSurf's parser isn't suckless. > > Here are some issues with their tokeniser.c > > - Using switch statement and explicit case numbers to implement
Re: [dev] Suckless web rendering engine
On 15 February 2015 at 19:02, Calvin Morrison wrote: > check out dillo > > On 15 February 2015 at 13:52, Ralph Eastwood wrote: >> On 15 February 2015 at 18:23, Marc Weber wrote: >>> http://www.netsurf-browser.org/ could be close. >>> also have a look at: http://de.wikipedia.org/wiki/Servo_(Software) >>> In any case it looks like to be a lot of effort. >>> >>> Marc Weber >>> >> >> I've glanced at netsurf in passing (source code/design) etc. It is by >> far more suckless than any other implementation I've come across. >> >> -- >> Tai Chi Minh Ralph Eastwood >> tcmreastw...@gmail.com >> > I stand corrected! I had forgotten about dillo. -- Tai Chi Minh Ralph Eastwood tcmreastw...@gmail.com
Re: [dev] Suckless web rendering engine
check out dillo On 15 February 2015 at 13:52, Ralph Eastwood wrote: > On 15 February 2015 at 18:23, Marc Weber wrote: >> http://www.netsurf-browser.org/ could be close. >> also have a look at: http://de.wikipedia.org/wiki/Servo_(Software) >> In any case it looks like to be a lot of effort. >> >> Marc Weber >> > > I've glanced at netsurf in passing (source code/design) etc. It is by > far more suckless than any other implementation I've come across. > > -- > Tai Chi Minh Ralph Eastwood > tcmreastw...@gmail.com >
Re: [dev] Suckless web rendering engine
On 15 February 2015 at 18:23, Marc Weber wrote: > http://www.netsurf-browser.org/ could be close. > also have a look at: http://de.wikipedia.org/wiki/Servo_(Software) > In any case it looks like to be a lot of effort. > > Marc Weber > I've glanced at netsurf in passing (source code/design) etc. It is by far more suckless than any other implementation I've come across. -- Tai Chi Minh Ralph Eastwood tcmreastw...@gmail.com
Re: [dev] Suckless web rendering engine
http://www.netsurf-browser.org/ could be close. also have a look at: http://de.wikipedia.org/wiki/Servo_(Software) In any case it looks like to be a lot of effort. Marc Weber
Re: [dev] Suckless web rendering engine
On Sun, 15 Feb 2015 10:13:12 -0800 Eric Pruitt wrote: Hey Eric, > Is such a thing even possible? I can't imagine there being a web > rendering engine that this community would consider suckless that would > also be useful for day-to-day web browsing. yes, you are going the right direction. We actually discussed this a lot on IRC and came to the conclusion, that surf is the approach to provide a suckless interface to a sucky base. The web sucks. And there's no way you can write a suckless rendering engine. I bet you can even prove this mathematically. If a "Standards consortium" releases a new 1000-page-standard every year where only big companies in a combined effort can develop implementations of, then there's something wrong with the standards, not the rendering engines. Even though webkit sucks a lot in many ways, there's simply no other way to write a _usable_ interface to the web. There are other areas where you can make a change. It's not looking like the web is going to improve in the next couple of years. Cheers FRIGN -- FRIGN
Re: [dev] Suckless web rendering engine
Eric Pruitt wrote: > Is such a thing even possible? I can't imagine there being a web rendering > engine that this community would consider suckless that would also be useful > for day-to-day web browsing. Heyho, imho you can either have a suckless „rendering“ engine aka html2text or just some script that filters out the code and only outputs the content. Or you can have a suckless interface to the (inevitably sucking) web. This would be something using blink or gecko (webkit lacks too far behind and I noticed a few regressions lately) with a surf-like user interface. Funny thing I started coding such a thing recently, but it's not yet ready to be announced on this list… --Markus
Re: [dev] Suckless web rendering engine
Marc Collin wrote: > Are there any plans for this? Have you tried Google Chrome?
Re: [dev] Suckless web rendering engine
On Sun, Feb 15, 2015 at 04:10:15PM -0200, Marc Collin wrote: > Are there any plans for this? Is such a thing even possible? I can't imagine there being a web rendering engine that this community would consider suckless that would also be useful for day-to-day web browsing. Eric
[dev] Suckless web rendering engine
Are there any plans for this?
