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

[RFC] Introduce a web based debugger and some basic examples. #1607

Merged
merged 3 commits into from Aug 25, 2017

Conversation

@glennw
Copy link
Member

glennw commented Aug 24, 2017

This introduces a simple web based debugger for WR, as an optional feature.

The initial implementation allows toggling the debug flags (e.g. profiler, texture cache debug view) and dumping a list of draw call batches to the browser.

In the future, I'd plan to expand the feature set significantly - for example, a render tree visualization, and more detailed timing. We can also use this as a debugging tool - for example, adding support for stepping through a single frame etc.

The main things to answer are:

  • Should the client live in this repo or elsewhere?
  • Is the current setup of the feature going to work OK with vendoring?
  • Is the current implementation / threading strategy reasonable?

The implementation uses Vue.js, websockets and Bulma.


This change is Reviewable

@glennw
Copy link
Member Author

glennw commented Aug 24, 2017

debugger

@glennw
Copy link
Member Author

glennw commented Aug 24, 2017

Thoughts @kvark @jrmuizel @nical ?

@glennw
Copy link
Member Author

glennw commented Aug 24, 2017

BTW, it's listed as [RFC], but it's actually ready to go from my perspective, if everyone is happy with it as-is.

@nical
Copy link
Collaborator

nical commented Aug 24, 2017

I would like this to be in the repo. Hopefully, having it behind a feature flag like you did should be enough for vendoring.

@kvark
kvark approved these changes Aug 24, 2017
DebugMsg::FetchBatches(sender) => {
let mut batch_list = BatchList::new();

if let Some(ref frame) = self.current_frame {

This comment has been minimized.

@kvark

kvark Aug 24, 2017

Member

nit: could combine this pattern match with the next one to avoid nesting

This comment has been minimized.

@glennw

glennw Aug 24, 2017

Author Member

Fixed

if let Some(ref frame) = frame.frame {
for pass in &frame.passes {
for target in &pass.alpha_targets.targets {
batch_list.push("[Clip] Clear", target.clip_batcher.border_clears.len());

This comment has been minimized.

@kvark

kvark Aug 24, 2017

Member

can we add (to JSON) any information about the target itself?

This comment has been minimized.

@glennw

glennw Aug 24, 2017

Author Member

Definitely - the batch list is very much a proof of concept - I'll expand on the information with a more detailed view as a follow up.

#[derive(Serialize)]
pub struct BatchList {
kind: &'static str,
batches: Vec<BatchInfo>,

This comment has been minimized.

@kvark

kvark Aug 24, 2017

Member

we might consider having a bit stronger types here, e.g.

#[derive(Serialize)]
pub struct ClipBatcherInfo {
  clears: usize,
  borders: usize,
  rectangles: usize,
}
#[derive(Serialize)]
pub struct CacheBatcherInfo {
...
}
pub struct BatchList {
    kind: &'static str,
    clip: ClipBatcherInfo,
    cache: CacheBatcherInfo,
    alpha: HashMap<&'static str, usize>,
}

This comment has been minimized.

@glennw

glennw Aug 24, 2017

Author Member

Yep - sounds good. OK to do as a follow up?

@kvark
kvark approved these changes Aug 24, 2017
Copy link
Member

kvark left a comment

Thanks @glennw , amazing stuff!

Should the client live in this repo or elsewhere?

Since we are already settled with multi-project single-repo approach, I think it would be great to have the debugger in the repo as well, for easier maintenance at the very least.

Is the current implementation / threading strategy reasonable?

Currently, it's doesn't appear that RenderBackend contributes much by being in the debug loop. I assume we need it for more debugging logic added in the future.

notifier.unwrap()
.as_mut()
.unwrap()
.new_frame_ready();

This comment has been minimized.

@kvark

kvark Aug 24, 2017

Member

looks like new_frame_ready gets abused more. Maybe we should just add a ping method to be used both here and for MemoryPressure?

This comment has been minimized.

@glennw

glennw Aug 24, 2017

Author Member

Sounds like a good idea.


fn handle_debug_command(&mut self, command: DebugCommand) {
match command {
DebugCommand::EnableProfiler(enable) => {

This comment has been minimized.

@kvark

kvark Aug 24, 2017

Member

since we are at it, maybe we can remove the duplicated logic from wrench and examples boilerplate

This comment has been minimized.

@glennw

glennw Aug 24, 2017

Author Member

Do you mean remove the keyboard shortcuts? I think it makes sense to keep those for quick debugging - or did you mean something else?


#[cfg(not(feature = "debugger"))]
fn update_debug_server(&self) {
}

This comment has been minimized.

@kvark

kvark Aug 24, 2017

Member

perhaps, would be cleaner to do let _ = &self.debug_server than having underscore in _debug_server

This comment has been minimized.

@glennw

glennw Aug 24, 2017

Author Member

Fixed

@glennw glennw force-pushed the glennw:ws4 branch 2 times, most recently from e4421a7 to 4fe0d28 Aug 24, 2017
@glennw
Copy link
Member Author

glennw commented Aug 24, 2017

@kvark Thanks for the review! Fixed up some of those nits. I think it's OK to do the rest as follow ups - does that sound OK? Also added the debugger feature to wrench, which I had missed previously.

@kvark
Copy link
Member

kvark commented Aug 25, 2017

@glennw

Do you mean remove the keyboard shortcuts?

yeah, I don't see much point in keeping the shortcuts if you can do the same thing by just enabling debugger feature. I won't lose my sleep if the shortcuts are still there though ;)

Fixed up some of those nits. I think it's OK to do the rest as follow ups - does that sound OK?

Absolutely!

One last concern before r=me is CI-testing the debugger feature. I don't see you modifying the travis/appveyor scripts.

@bors-servo
Copy link
Contributor

bors-servo commented Aug 25, 2017

The latest upstream changes (presumably #1594) made this pull request unmergeable. Please resolve the merge conflicts.

@glennw glennw force-pushed the glennw:ws4 branch from 4fe0d28 to 3fd351f Aug 25, 2017
@glennw
Copy link
Member Author

glennw commented Aug 25, 2017

@kvark Ah, good point - I've rebased and updated the travis file to build wrench in release + debugger mode.

@kvark
Copy link
Member

kvark commented Aug 25, 2017

Wonderful, it's shipping time!
@bors-servo r+

@bors-servo
Copy link
Contributor

bors-servo commented Aug 25, 2017

📌 Commit 3fd351f has been approved by kvark

@bors-servo
Copy link
Contributor

bors-servo commented Aug 25, 2017

Testing commit 3fd351f with merge e3b2e00...

bors-servo added a commit that referenced this pull request Aug 25, 2017
[RFC] Introduce a web based debugger and some basic examples.

This introduces a simple web based debugger for WR, as an optional feature.

The initial implementation allows toggling the debug flags (e.g. profiler, texture cache debug view) and dumping a list of draw call batches to the browser.

In the future, I'd plan to expand the feature set significantly - for example, a render tree visualization, and more detailed timing. We can also use this as a debugging tool - for example, adding support for stepping through a single frame etc.

The main things to answer are:
 * Should the client live in this repo or elsewhere?
 * Is the current setup of the feature going to work OK with vendoring?
 * Is the current implementation / threading strategy reasonable?

The implementation uses Vue.js, websockets and Bulma.

<!-- 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/1607)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Aug 25, 2017

💔 Test failed - status-travis

@kvark
Copy link
Member

kvark commented Aug 25, 2017

CI has legitimate errors:

error: no field opaque_batches on type tiling::BatchList
--> /home/travis/build/servo/webrender/webrender/src/renderer.rs:1564:53
|
1564 | .opaque_batches
| ^^^^^^^^^^^^^^ did you mean opaque_batch_list?

@glennw glennw force-pushed the glennw:ws4 branch from 3fd351f to dcbe7c9 Aug 25, 2017
@glennw
Copy link
Member Author

glennw commented Aug 25, 2017

Ah, it needed a rebase after the batching PR landed - done.

@kvark
Copy link
Member

kvark commented Aug 25, 2017

thanks!
@bors-servo r+

@bors-servo
Copy link
Contributor

bors-servo commented Aug 25, 2017

📌 Commit dcbe7c9 has been approved by kvark

@bors-servo
Copy link
Contributor

bors-servo commented Aug 25, 2017

Testing commit dcbe7c9 with merge 56f75e7...

bors-servo added a commit that referenced this pull request Aug 25, 2017
[RFC] Introduce a web based debugger and some basic examples.

This introduces a simple web based debugger for WR, as an optional feature.

The initial implementation allows toggling the debug flags (e.g. profiler, texture cache debug view) and dumping a list of draw call batches to the browser.

In the future, I'd plan to expand the feature set significantly - for example, a render tree visualization, and more detailed timing. We can also use this as a debugging tool - for example, adding support for stepping through a single frame etc.

The main things to answer are:
 * Should the client live in this repo or elsewhere?
 * Is the current setup of the feature going to work OK with vendoring?
 * Is the current implementation / threading strategy reasonable?

The implementation uses Vue.js, websockets and Bulma.

<!-- 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/1607)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Aug 25, 2017

☀️ Test successful - status-travis
Approved by: kvark
Pushing 56f75e7 to master...

@bors-servo bors-servo merged commit dcbe7c9 into servo:master Aug 25, 2017
3 checks passed
3 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

5 participants
You can’t perform that action at this time.