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
Transform refactor #1221
Conversation
There was a problem hiding this 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).
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.
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.
Yep, these are the goals as describe in RFC, to divide this class and move some components out of |
delete() { | ||
this.model.delete(); | ||
/* eslint-disable no-unused-expressions */ | ||
this.bufferTransform && this.bufferTransform.delete(); |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make a helper function?
3c93b83
to
5b2ec72
Compare
Addressed RFC Feedback :
|
|
||
## Methods (Model props) | ||
|
||
### getDrawOptions(opts: Object) : Object |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
?
5b2ec72
to
7b6cbb0
Compare
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 andcore/transform
example.Remaining items:
Change List