low resource web browser

are there any web browsers out there with full support for javascript, and can render html normally? I wouldn't need anything like flash or java applets, but full support for fancy javascript would be nice for getting through fancy web sites and such. If one doesn't exist, I think I might try to make one, and shoot for 5 - 15MB of ram usage.

>>14

++

>>20

Mark compact is neat. Didn't realize it's haskell's gc algo, that's a good sign

>>41
Mark compact is neat.
Not very space nor CPU efficient.

nice dubs bro >>44

>>40
Because when you think that way, no amount of memory and CPU speed is ever going to be enough? Because people want to be able to open 1000 tabs at once?

Why is Google acting retarded now?

Searching for "tiny html parser" returns on the first page
- http://www.stylusstudio.com/xmldev/200208/post01280.html, only the title matches but otherwise irrelevant. Google highlighted the file extension just because it had "html" in it. Also Java shit.
- http://tidy.sourceforge.net/, "tiny" doesn't even appear anywhere on the fucking page.
- http://www.w3.org/Library/Examples/tiny.c, not an HTML parser
- http://code.google.com/p/ivnhtmlparser/, (note lack of space between HTML and parser, I didn't write "tiny htmlparser" in the search query) now we're getting somewhere but it's another Java shit.
- http://search.cpan.org/perldoc?HTML::TreeBuilder, the word "tiny" is there but otherwise it's irrelevant
- http://www.grinninglizard.com/tinyxml/, what the fuck does this have to do with HTML (not XHTML)?
- http://cpanratings.perl.org/d/HTML-Parser, the word "tiny" does not appear on this page
- http://www.perlmonks.org/?node_id=26723, again no mention of "tiny", also looks like some idiot trying to parse HTML with regexp

>>39

the gui is very easy.

http is just a protocol. a compact and efficient implementation is possible. Caching could just be a hashmap from "domain-name/path/to/file" to the spawned structure that was created from the fetched data. Elements not recently used could be saved to a file, or destroyed, to save space.

html is easy to parse. You can always ignore tags that you don't understand (although hopefully enough of the main ones are supported).

CSS isn't that difficult to parse. It looks like the entire language is outlined below:

http://www.w3.org/TR/CSS/

Once the html renderer can support the styles in CSS, it wouldn't be difficult to tie all that together.

Forms are just textual boxes. All of these things may take programming effort, but there is no reason for it to consume lots of memory.

The amount of memory used will be proportional to the size of the web page, there is no getting around that. So if the running javascript tries to allocate an array of length 6000000, then I'm kind of screwed. Although memory resources used by scripts should be capped anyway to prevent malicious pages from crashing your browser.

>>40

Not all devices have a Gig of ram. Even if it's cheap, it might not fit.

>>46
Here's a hint: there are less than 256 CSS properties, HTML elements, and HTML attributes. The in-memory representation of the DOM might even be smaller than the document, with the right implementation choices.

But spend too much effort on "compressing" the DOM and it might be impractically slow.

>>46
So if the running javascript tries to allocate an array of length 6000000, then I'm kind of screwed.
First, limit JS memory usage to some sane limit, such as 5 MB per page or less. Second, use an infinite compression algorithm to sacrifice CPU time for memory.

>>47

Yeah, something like this could do:

struct dom_node {
  enum dom_type type;
  struct dom_node* parent;
  struct dom_node* child_array;
  int number_of_children;
  void* type_specific_data;
};

Although inserting elements in certain positions would involve reallocating an array, and could get slow if there are lots of sibling nodes. Alternatively:

struct dom_node {
  enum dom_type;
  struct dom_node* parent;
  struct dom_node* first_child;
  struct dom_node* last_child;
  struct dom_node* left_sibling;
  struct dom_node* right_sibling;
  // Type specific data located at the end of this struct.
};

but then random access to children is slower...

>>48

Of course! Frozenvoid, we need your help!

>>49
Of course! Frozenvoid, we need your help!
Oh god what have you done.

>>39
I'll use Windows' platform to compare against with Chrome since that's the most "consistent" system (i.e. relatively standard set of libraries available.)

GUI: Chrome's... chrome is rendered using their own custom UI library (just to be platform-independent). It wouldn't surprise me if several hundred KB of data were taken up just by the gradients everywhere. Making it native Win32 would shave a lot of unnecessary abstraction off.

HTTP client: Windows already has one: WinInet.

html5 compliant parsing algorithm: I have written a tokenizer in less than 12KB of binary. The entire parser won't be that much bigger, probably <64KB.

CSS parser: CSS is simpler than HTML in structure and thus easier to parse. Another thing <64KB.

Layout engine: Here is where OOP concepts make sense: each DOM node is associated with a CSS box object that has positions and other properties. Each one has a virtual draw() method. All the layout engine has to do is assign the positions to the boxes appropriately (the tricky part is doing it dynamically as nodes and CSS properties are changed by either the page loading or JS). The window message loop then triggers the appropriate draw()'s on the boxes visible in the current viewport on WM_PAINT and they'll paint themselves on the window. Other events like mouse clicks etc. (e.g. change the cursor to a middle finger when it goes into the box for the 'a' element, and back to an arrow when it leaves) could also be handled by other virtual methods on the boxes. My (very loose) estimate: <256KB.

JS interpreter: This should be the largest. There's this:
http://code.google.com/p/tiny-js/
which is a little over 128KB (the majority of it is C++ bloat.)
Also this, didn't try to compile it (too many files):
http://code.google.com/p/quad-wheel/
My (again very loose) estimate: ~512KB.

That amounts to a browser with <1MB of binary.

Although inserting elements in certain positions would involve reallocating an array, and could get slow if there are lots of sibling nodes.
Reads will be more often than writes, so I'd go with a dynamic array. If you use exponential reallocation then inserts and deletes occur in amortized constant time. A gap buffer or even a rope ( http://en.wikipedia.org/wiki/Rope_(computer_science) ) might be worth thinking about too.

Use a hash table for the fastest lookups.

>>51
It wouldn't surprise me if several hundred KB of data were taken up just by the gradients everywhere.
So, one color for the gradient start and one for the gradient end, which comes out at about 8 byte in ARGB? Yeah, hundreds of KB alright.

>>53
That would be the preferred way of making a gradient, but check this out:
http://src.chromium.org/viewvc/chrome/trunk/src/ui/resources/frame_app_panel_default.png?revision=90948&view=markup
http://src.chromium.org/viewvc/chrome/trunk/src/ui/resources/frame_default.png?revision=90948&view=markup

(and everything else in that directory).

They also felt the need to make their own close, minimize, and maximize buttons.

low resource doubles

Is OP still working on his browser?

THUMBS UP IF YOU CAME HERE FROM WAROSU!
http://fuuka.warosu.org/jp/thread/S8598688#p8598688_41

>>56
Heya. nope. I've been working on two other projects though. I'll get to it eventually, once I finish the things at the top of the queue, or give up.

>>58
Do you mean at the top of the stack? Because this project is really old.

>low resource web browser
>javascript

the "java" is in its name for a reason, ``faggot''

>>59
I haven't started yet. Don't worry, I will someday. It's a priority queue based upon coolness.

>>60
it can be done.

If it ain't Links, it's crap.

>>63
indeed.

>>62
As for my master!

>>62
if you want a shit slow interpreted javascript, maybe

>>66
nyah, it can be done without interpretation too.

WebKit
...
...
aka Chromium

>>68
thanks, will check out.

>>67
you mean like... walk the ast? that sounds like an ecma solution to me!

>>70
nyah, you know, byte code and friends.

>>68
WK (Chrom* Safari UZBL ...), FF (Seamonkey BurningDog LoliFox IceCat ...), Opera, IE, they're all about the same these days. Several MB.

Making one with similar capabilities in several hundred KB would be impressive.

uTorrent-like.
.
uWebBrowser?
.

elinks has some JavaScript support.
You could look into adding JS support to Dillo, hv3 or NetSurf.

>>72

yeah, it would definitely fill a niche for low end devices too.

>>73

cool yeah. It probably wouldn't be too hard to integrate an existing minimal open source browser with good open source javascript implementation/library. It would just be matter of finding the best candidate, if one is suitable.

I'll bump this thread when I actually start something.

Why do people seem to be oblivious to the fact that a browser is NOT just something that uses an existing browser on the system!?!?

http://www.kakeeware.com/i_kb.php
http://www.browzar.com/
http://www.winasm.net/forum/index.php?showtopic=366

You can use existing resources on the system: C libraries, graphics APIs (GDI, DirectX, SDL, etc.), network APIs (Winsock, *nix sockets), and other miscellaneous stuff, but NOT something that will parse and render HTML/CSS, if you're claiming to have written a web browser.

Maybe this should be a /prog/ject. Fund it! Or set up a github. Whatever works.

If a sacrifice was made to use V8 or some other pre-existing javascript engine, it wouldn't be too hard to write almost the entire browser in JS. Not that it would be necessary or efficient, but it might be neat.

>>75
Why does that apply to HTML but not HTTP? Or the GUI but not CSS? Do I need to write my own image libraries too?

Anyway, the Web client is unimplementable. Give up and go home.

I just want some dubz, nigguh

Why is JS such a fucking piece of nigger shit?