Skip to content

Add "query playground" #406

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

Merged
merged 9 commits into from
Feb 14, 2019

Conversation

cwillisf
Copy link
Contributor

@cwillisf cwillisf commented Jan 28, 2019

Resolves

Progress toward diagnosing #390 and other "touching color" issues

Proposed Changes

  1. Add a flag to force the renderer to use the GPU or CPU implementation of touching color?.
  2. Pull playground JS out of the HTML and into its own JS files.
  3. Build the playground JS using Webpack instead of just copying it as-is.
  4. Add a new playground, queryPlayground.html, to interactively test renderer queries like touching color?.

Current state:
image

Reason for Changes

This should help figure out what's going wrong with touching color?, as well as making it easier to add more playgrounds in the future if necessary.

@cwillisf cwillisf changed the title Playground webpack Add "query playground" Jan 28, 2019
Christopher Willis-Ford added 4 commits January 30, 2019 11:00
- Adjust the rotation center of the cursor so that its single pixel is
  gets rendered onto a single stage pixel instead of being split across
  2-4 stage pixels.
- Add canvas CSS to make most browsers scale the canvases without
  interpolation.
Copy link
Contributor

@mzgoddard mzgoddard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some thoughts.

RenderWebGL.sampleColor3b(point, candidates, color);
if (debugCanvasContext) {
debugCanvasContext.fillStyle = `rgb(${color[0]},${color[1]},${color[2]})`;
debugCanvasContext.fillRect(x - bounds.left, bounds.bottom - y, 1, 1);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is a weird idea. What if this wasn't drawing but was calling delegate methods. Methods on debugCanvasContext. Then the different playground pages could change what they use about this data if that would be useful.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of delegates. That could also solve another problem I've been having, where using "the" debug canvas is basically impossible in some projects since you only get a brief glimpse of the thing you're interested in before the canvas gets overwritten by the next thing. This could be solved by including some basic context info when calling the delegate method so the delegate could decide which data to handle, and how.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I explored this idea a bit and it started getting super complicated, mainly due to the differences between the CPU and GPU paths. It might be better (or at least easier) to have canvas-fetching delegates or something like that... I dunno. Anyway, I still like the idea but I think I'm filing it under "future work"...

@cwillisf cwillisf merged commit c9f86ef into scratchfoundation:develop Feb 14, 2019
@cwillisf cwillisf deleted the playground-webpack branch February 14, 2019 18:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants