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

Optimization for distorted rects + "similar" objects #549

Open
wants to merge 25 commits into
base: master
Choose a base branch
from

Conversation

ggcrunchy
Copy link
Contributor

Distorted rects use a slight modification of the fragment shell to do their work. Unfortunately, this means that they count as having a different program than other objects, even if everything else is the same (from the renderer's point of view), so for instance this sequence will break batching at each step:

distorted rect, normal rect, distorted rect, normal rect

Those might all have the same image or use a common sheet, in which case our intuition would be that this all should batch.

The shell's distortion mod is actually a superset of the normal behavior, so after the initial switch, we can in fact just leave it in place so long as the only change in render state would be a "downgrade" of the current program.


For most path-based display objects, q (v_TexCoordZ, in the shell) is set to 1, the exception being distorted rects, of course, which add some fractional delta.

Box2D debugging, emitters, and particle systems each zero out their vertices and so will have q of 0, as far as I can tell.

Dividing by zero is not usually good, so we probably don't want to let these make it to the distortion mod.

As it happens, rects use the triangle strip primitive type, whereas Box2D uses line loops and the others are triangle fans, and the renderer must break a batch to switch types. So we can piggyback on this break that has to happen anyway and demote the distortion mod to avoid issues with zeroes.


With a long enough chain of "normal rect"s, the cost of extra shader instructions will overtake what you would have incurred by switching the program. (Quite a long chain, probably.) I have some comments about a possible solution.

A lower-tech way would be to demote—as with primitive types—whenever we break a batch due to !enoughSpace.

ggcrunchy and others added 24 commits February 7, 2019 17:09
…nd buffer and assignment logic

Next up, prepare details from graphics.defineEffect()
…from Program

Slight redesign of TimeTransform with caching (to synchronize multiple invocations with a frame) and slightly less heavyweight call site
Err, was calling Modulo for sine method, heh

That said, time transform seems to work in basic test
Fixed error detection for positive number time transform inputs

Relaxed amplitude positivity requirement
Maintenance Revert Test
My mistake adding back changes made
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.

3 participants