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

Transform refactor #1221

Merged
merged 8 commits into from Sep 9, 2019
Merged

Transform refactor #1221

merged 8 commits into from Sep 9, 2019

Conversation

1chandu
Copy link
Contributor

@1chandu 1chandu commented Aug 28, 2019

For #1193

Background

Phase#1 changes as described in RFC
This is still WIP, I will be collecting team's feedback on RFC and update this PR.
Verified using existing Transform unit tests and core/transform example.
Remaining items:

  • Addressing any feedback from RFC
  • Docs
  • Unit tests specific to new modules/classes.

Change List

  • [POC] Transform refactor

Copy link
Collaborator

@ibgreen ibgreen left a comment

Choose a reason for hiding this comment

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

This is a lot to review, I will certainly need more time, but some quick feedback/ideas:

  • perhaps writing/updating markdown docs as you go could help reviewers a lot. Start by reviewing the doc changes could guide the code review.

One question with this design (I need to reread the RFC) is whether the user can combine buffers and textures in one call, or whether it always uses one type.

I count ~800 lines, so this is class is getting pretty big, and I suspect it will keep growing.

Perhaps at some point there is a bigger GPGPU compute system growing out of this and we can carve out a small Transform class to keep inside core?

It raises the question whether this should be kept in core (it probably should stay in core, but I think we want to keep a close eye on module growth).

@1chandu
Copy link
Contributor Author

1chandu commented Aug 29, 2019

perhaps writing/updating markdown docs as you go could help reviewers a lot.

I did write how these classes work and how they interact in RFC, I will write docs after collecting first round of feedback on overall approach.

One question with this design (I need to reread the RFC) is whether the user can combine buffers and textures in one call, or whether it always uses one type.

The code as is, yes you can combine buffer and textures in one call. I discussed few options in RFC for Phase#2, some options support and some options don't, but this PR doesn't cover Phase#2, just lays foundations for it.

I count ~800 lines, so this is class is getting pretty big, and I suspect it will keep growing.
It raises the question whether this should be kept in core (it probably should stay in core, but I think we want to keep a close eye on module growth).

Yep, these are the goals as describe in RFC, to divide this class and move some components out of core module, more details in RFC.

modules/core/src/lib/transform/buffer-transform-binding.js Outdated Show resolved Hide resolved
modules/core/src/lib/transform/buffer-transform.js Outdated Show resolved Hide resolved
modules/core/src/lib/transform/texture-transform.js Outdated Show resolved Hide resolved
delete() {
this.model.delete();
/* eslint-disable no-unused-expressions */
this.bufferTransform && this.bufferTransform.delete();
Copy link
Collaborator

Choose a reason for hiding this comment

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

Nit: use if

if (opts.elementCount) {
this.model.setVertexCount(opts.elementCount);
}
const resourceTransforms = [this.bufferTransform, this.textureTransform].filter(Boolean);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Make a helper function?

modules/core/src/lib/transform/transform.js Outdated Show resolved Hide resolved
@1chandu 1chandu changed the title [POC] Transform refactor Transform refactor Sep 7, 2019
@1chandu
Copy link
Contributor Author

1chandu commented Sep 7, 2019

Addressed RFC Feedback :

  • Merge BufferTransformBinding into BufferTransform and TextureTransformBinding into TextureTransform
  • Add docs for BufferTransform and TextureTransform, didn't link them to website yet, since these are still private internal classes, added for easier review.
  • Address other review comments.


## Methods (Model props)

### getDrawOptions(opts: Object) : Object
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 feel, updateDrawOptions is more suitable, here and for BufferTransform.

Copy link
Collaborator

Choose a reason for hiding this comment

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

It's quite awkward how the props/options are passed from the parent class to the child then back again. Shouldn't BufferTransform and TextureTransform own their models instead of Transform?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

as discussed offline, these are internal methods to Transform, I will address these concerns in Phase-2, where I am planning to make this API public.

* `feedbackBuffers` (`Object`, Optional) - key and value pairs, where key is the name of vertex shader varying and value is the corresponding `Buffer` object or buffer params object. If a buffer params object is specified, it will contain following fields, these can be used to capture data into the buffer at particular offset and size.
* `buffer`=(Buffer) - Buffer object to be bound.
* `byteOffset`=(Number, default: 0) - Byte offset that is used to start recording the data in the buffer.
* `byteSize`=(Number, default: remaining buffer size) - Size in bytes that is used for recording the data.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe not for this PR: Can we follow the same accessor convention that model.setAttributes uses?


## Methods (Model props)

### getDrawOptions(opts: Object) : Object
Copy link
Collaborator

Choose a reason for hiding this comment

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

It's quite awkward how the props/options are passed from the parent class to the child then back again. Shouldn't BufferTransform and TextureTransform own their models instead of Transform?

@coveralls
Copy link

Coverage Status

Coverage increased (+4.6%) to 67.229% when pulling 7b6cbb0 on r/TransformRefactor into 745947d on master.

@1chandu 1chandu merged commit 210151b into master Sep 9, 2019
@1chandu 1chandu deleted the r/TransformRefactor branch September 9, 2019 23:47
tgorkin added a commit that referenced this pull request Sep 11, 2019
* master:
  Transform refactor (#1221)
  dev-tools: Bump to 0.0.29 (#1232)
  v7.3.0-alpha.7
  Transform: Fix update of Buffers and elementCount. (#1224)
  point docs to release branch (#1229)
  update website fonts (#1227)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants