Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTML parser appends extra html node to root #343

Closed
jdm opened this issue Apr 8, 2013 · 5 comments
Closed

HTML parser appends extra html node to root #343

jdm opened this issue Apr 8, 2013 · 5 comments

Comments

@jdm
Copy link
Member

@jdm jdm commented Apr 8, 2013

By default, the parser creates an HTMLElement node as the root of the document, and then appends all nodes encountered to that. It currently doesn't discriminate when it does so, so when it encounters an actual element in the source, it merrily appends a second one to the root. We should find some way to avoid this.

@jjjjw
Copy link
Contributor

@jjjjw jjjjw commented May 27, 2013

I have been looking into this and it seems to be a consequence of the fact that hubbub (the current html parser) does not provide a nice way to get at the root node after the parsing, nor do we want to implicitly assign the root on the fly in a callback as we parse. So this spurious root is created up front, and I actually don't see a good way to get around that. I certainly could be failing to grasp something.

I assume that an html parser in Rust is somewhere down the line? Then we can just haz the tree. This is my naive solution.

@jdm
Copy link
Member Author

@jdm jdm commented May 27, 2013

Yes, code apparently exists to automatically translate Gecko's Java-originating HTML5 parser into native Rust code.

@jjjjw
Copy link
Contributor

@jjjjw jjjjw commented May 28, 2013

Wait just second. This is all a misunderstanding. Upon second glance it seems that there is a confusion between hubbub's document node and the html node. I should be able to straighten that out so that the current parser works in the meantime.

@jdm
Copy link
Member Author

@jdm jdm commented Nov 5, 2013

We should be able to fix this now by passing the Document node to the parser and using that as the root.

@jdm
Copy link
Member Author

@jdm jdm commented Nov 19, 2013

This is fixed now.

@jdm jdm closed this Nov 19, 2013
glennw pushed a commit to glennw/servo that referenced this issue Jan 16, 2017
Implement a number of basic optimizations for WR2.

* Retain frame builder during scrolling.
* Move primitive packing to per-primitive type, and only run on newly visible primitives.
* Add groundwork for tile fast paths (none are implemented yet).
* Reduce hash table lookups for glyphs.
* Cache packed primitives between scrolls.
* Add basic occlusion.
* Handle narrow phase collision test for tiles inside simple borders.

There is a lot of optimization work remaining, but these changes typically improve CPU/GPU time by around 25-50%.

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/343)
<!-- Reviewable:end -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.